How many of your project meetings are actually content free talking head sessions? How do you move from content free gatherings to purposeful meetings which facilitate rich dialog. One way to do so is to focus on data rich visualizations.
I was only a few days into my role as Requirements Program Manager for a consumer electronics company. I had flown to another division site to join with several people, many coming from our six development sites in four countries on two continents, for a requirements commit meeting the upcoming product release cycle. In addition to the staff who flew in for this meeting, we were joined by several people through shared desktop software. The meeting ran for 6 hours plus an hour lunch break, no easy task to keep focused when you are attending through web meeting tools.
At the end of the meeting there were 4 todo’s on a flip chart, and everyone patted themselves on the back for a job well done. All but me that is.
After the meeting, after the remote staff had hung up their phones, I pulled aside the meeting facilitator and asked, “so what did we just accomplish?”
He gave me an odd sort of look and said “we just committed to what firmware features we will deliver in the next product release cycle.”
“OK, but what decisions about that commit were made here?,” I asked. The response, a blank stare.
As later analysis would show, not only did we not engage in meaningful dialog, those commitments which were made, turned out to be not so committed, resulting in substantial late point development thrash, including several feature misses for shipping products.
This is the story of how, with the use of visual management, I was able to facilitate early dialog in a large, distributed development team, resulting is substantially lower code thrash near product release, while substantially improving final feature quality.
The firmware development framework for this organization was structured as a matrixed collaborative development process. There were approximately 120 reusable components which were in active development by component team members distributed across six sites in four countries on two continents. Product features were created by an feature integrators who would pull functionality from multiple components into a marketable feature, which was then built into a product firmware image by a product integrator.
This matrix is depicted in the diagram to the right. This model represents the three dimensions of the development matrix.
The colored bars on the bottom of the diagram represent components, with those component teams who have expertise in specific areas clustered at specific sites. User interface components were developed in India for example, while network protocols were developed in Washington State.
Features in the diagram are indicated by the horizontal silver bars laying across the asset bars. The red rivets indicate where asset teams need to deliver component code to deliver the feature.
Features are integrated into products, as indicated by the doughnuts at the end of the feature bars. Each product is represented by one layer of doughnuts. Solid doughnuts represent features integrated in the product, transparent doughnuts represent features not integrated in the product.
This diagram is a grossly simplified model of the actual problem space. There were about 120 components, integrated into something like 300 features, combined into up to 30 permutations each representing the feature set of a new product. The firmware requirements commit process involved winnowed down from an original request pool of typically 500 to 600 requests, to arrive at those 300 features which would actually be delivered.
This model, while highly complex, was used because by concentrating knowledge in component teams, there is minimizing duplication of effort. It had shown a 10x improvement in development efficiency as compared to having each product staffing a complete team of component experts into a product development team of their own.
The downside of this organizational model is the significant complexity of coordinating development.
The winnowing down process utilized a two phase commit. Component teams are presented a list of wants collected from product teams. The component teams then perform an initial guesstimate of the feasibility of each feature request and time it will take to investigate, to determine a high confidence level of effort and risk to actually implement.
Based on the time estimates and risk factors, each component team then makes go/no-go decisions on the feature request. Any component owner can kill a feature based on effort and risk factors.
The problem was, the complexity of this process led to late thrash, which created unexpected resource impacts and frequent quality assurance issues, particularly when one component team was relying on the deliver of a component from another component team.
The diagram above shows the number of commit/not commit state transition rates per day for component teams evaluating their ability to investigate, and later, to commit to requirements for one product cycle when I joined the organization.
Note that the majority of “commit to investigate” decisions were actually made after the checkpoint which was intended to synchronize investigation commitments.
Also notable is the thrash just prior to the commit checkpoint. Because not all component teams could commit to all features, this lat minute thrash often led to confusion over what features will actually be delivered, an issue that often led to defects late in the development phase.
To better control the process, I created the dashboard show above. This is a rather complex matrix, and I won’t go into all the details, focusing only on the matrix on the left of the diagram. Each column represents a component team, and each row represents a feature request. If there is a character at the intersecting cell, it indicates that, that component is needed to deliver that feature request.
So the first aspect of the investigation is determining what components need to be included to deliver each feature. An “X” in the intersecting cell indicated that someone believes this component is needed for this feature. Anyone could mark a component as being needed. The component owner could then mark as NA by placing an “N” in the intersecting cell.
Assuming component is required for that feature, the component owner then either commits to investigate by marking the cell with an “I” or reject the investigation with an “R”.
After in the investigation, the component owner then either committed, with a “C” or rejected the delivery with an “R”.
Features which were rejected were highlighted in by one or more component owners are highlighted in red. Features which had been fully committed by all component owners were highlighted in green.
Component owners could filter on the features they was being asked to investigate and/or deliver. Product managers could filter on the feature requests for their product to see which had been committed to, rejected, and which were still being investigated. The program manager could track investigations which were incomplete, and gently nag those component owners on outstanding status updates.
The primary value of this spreadsheet, which was actually just a visual representation of data maintained in the requirements module of Quality Center, was that by showing the investigation and commit status for component team work and their interdependencies, it insured necessary conversations occurred when they needed to occur.
As shown in the chart above from after this dashboard had been implemented, the vast majority of requirements were evaluated for investigation prior to the review checkpoint. Note also that the thrash declines significantly heading into the commit checkpoint.
While managing this three-dimensional matrix was a complex task, the use of visual management tools significantly improved communication across the matrix, resulting in lower levels of late point feature development thrash.
When I left the organization, those six hour commit show and tell meetings had been replace with a one hour meeting in which actual dialog took place, often haggling over the relative priority of, and ability to deliver on a few contentious features. Post deliver code thrash was substantially reduced because there was no ambiguity of code dependencies.
I don’t recommend that anyone try to replicate this visual representation, that is not the point. The point is that visualizing a complex problem like this can facilitate meaningful dialog, and that can have substantial business value.