|
Over the years of my career, I have often observed tension between business leaders and technical development leaders. The tension is born of technical teams wanting to develop their complex product "right the first time", and management teams wanting the product be launched by a pre-determined date, as quickly as possible. In this issue, we'll discuss possible causes of this tension and attributes of the development model that contribute to it. Future newsletters will continue this exploration, including the best way to avoid problems; using Critical Parameter Development & Management for product development.
The Reaction-Based, Rapid Build-Test-Fix Model of Product Development
In many organizations, the PDP begins by planning the project at a high level, going fast, and reacting to problems that come up along the way, regardless of the complexity or difficulty of the product being developed. This process is called Build-Test-Fix and it typically runs something like this:
Marketing provides requirements for a new product which are translated into technical product requirements. A business case is developed for the project. A cross-functional team is assembled; a Project Manager is appointed to lead them. A Lead or System Engineer is chosen to oversee the technical teams and the integration of the system. The sub-level development teams begin to design and assemble the respective prototypes for integration into a functional system prototype.
A test plan is built in parallel with the design and integration of the new system. Functional and reliability tests are objectively conducted to assess the system's ability to meet customer requirements. Performance data from these tests is reviewed, short-falls are identified and corrective action cycles initiated. Build-Test-Fix iterations are done until the performance short-falls are corrected.
It is assumed that the technical team members have engineering or technical degrees from accredited universities, have appropriate levels of development experience, and will provide adequate attention to this project even though they (probably) are matrixed to other development projects and possibly production and product life-cycle support actions - simultaneously!
This model provides a very aggressive business and marketing launch stance based upon the rapid execution of tasks to produce a very visible system prototype. Management starts to count on relatively frequent updates to reinforce a sense of progress and considers iterative Build-Test-Fix cycles as normal.
The Project is in Danger of Being "Overcome by Events"
Unknown problems exist, either in the lagging data that is yet to be understood and communicated, or inside the functional parameter relationships that the testing is not designed to uncover. This latency results in rapid execution of increasing numbers of corrective actions. As subsequent Build-Test cycles outpace knowledge and understanding, additional problems intertwine and increase the complexity of the problem-solving "Fix" cycles.
The Project Manager assesses schedule, cost and performance (CSP) and adjusts the project to assure the launch date is met. This balancing can be a source of tension across development team and with the management team. If there is significant conflict, upper management may intervene by altering the launch criteria (changing requirements and constraints); granting permission to slip the schedule; or canceling the project.
Forecasting the duration of this type of project is difficult because planning has been kept to a minimum and "Fix" action placed at a premium. The project schedule is often a simple document with focus on the major Build-Test milestones. This development paradigm tends to "work" at first, until the problems become more interrelated, subtle and complex. Note that a system with new technology development integrating with existing sub-level designs and interfaces requires methodical characterization that won't happen if there is pressure to get the next Build-Test cycle done "on time".
Management contributes to this downward spiral when, at milestone reviews, they assume their role is to ask backward-looking questions after the engineering team has reached the milestone. The questions often focus on "was this or that done in such-and-such a manner and if not, why not?" Then corrective actions are assigned and the cycle repeats, with a backlog of tasks that includes old work that is laced with short-falls intermixed with the new phase of work that is needed to meet the next milestone. Task analysis, if conducted, reveals that the work load per team member increases rapidly well beyond 110 - 120%. A term has emerged that characterizes the project team as "overcome by events".
Attributes of Rapid Build-Test-Fix Model
Here is a list of just several attributes that contribute to the less-than-desirable outcome for projects run this way:
- Go fast; take risks.
- Assume the competence of the team.
- Rely on shared resources (team members).
- Measure progress based on the visibility of tangible proto-types.
- Make decisions based upon latest test results vs. requirements.
- Test and measure reliability only under nominal and general customer use conditions.
- Limit planning; rely on reacting to detected short-falls.
- Prescribed tasks are not required; nor are the use of any particular tools, methods or best practices.
- Use the lowest cost suppliers that can "meet the specs".
- Teams are free to do their work their own way; project schedules are high-level, with a minimum of detail.
- Build the next iteration of proto-type on schedule and drive the data assessment to keep up.
- Launch on schedule. If necessary change the launch criteria, slip the schedule or cancel the project.
Next month, we will discuss several more attributes of the rapid Build-Test-Fix methodology for product development and the antidote to its shortcoming: Critical Parameter Development & Management!
| 
