In Search of the Killer Development Process

The scene is a typical one. An arcane diagram showing the twists and turns of the new, killer development process covers an entire wall of the large conference room. The process improvement team has been slaving away for the last year to create this map and it’s finally ready to be unveiled. It is now time to show this masterpiece to the rest of the development community.

Engineers of all shapes and sizes gather in the conference room to witness the dawn of a new age in product development.

The chairperson of the process improvement team begins to speak, “We have listened to all of you and distilled the essence of your wisdom and vast experience into this universal process map. If we simply follow this new process with unwavering discipline, we will avoid repeating the embarrassing mistakes of the past.” The engineers glance furtively at each other, each one believing the chairperson is slyly referring to their own last project.

“Surely you jest,” says a rogue engineer. “This new process could never work for my project. I would rather run naked through the parking lot than give in to this madness.”

Soon all the engineers in the room are pointing out grave flaws in the new process model which, if implemented, would genuinely threaten the success of their projects. At this point, the process-improvement team is beginning to get a bit defensive.

The General Manager silences the crowd and asks, “Isn’t there any project leader who thinks this new process would be an improvement?”

The room is filled with silence.

Irritated, the General Manager asks, “If this process won’t improve any of our projects, why should we use it?”

Courageously, the Quality Manager raises her hand and volunteers, “Well, we do need a process to get our ISO 9000 certification.”

The General Manager scowls and says, “That’s right, but we don’t need a process that hurts the performance of every project in the company. I appreciate the hard work, but let’s stop wasting effort on this process map.”

It is not entirely surprising that the team failed to find the killer process, for they chose an approach that was doomed to failure. It is impossible to draw a universal process map that will exceed the performance of a well-crafted project plan. This may come as a surprise to managers experienced with process improvement in the factory because process-mapping has worked wonders on the factory floor.

The world of one-time processes
One key difference between engineering and manufacturing is that engineering is always doing something new. Manufacturing engineers are usually delighted that they can build a product the same every time. However, if engineering designs a product exactly the same way twice, it will get the identical design, which means it was a wasted effort. Engineering has to do something new to add value in product design. This means every project will differ in important respects from every other project: using different components, different materials, different tests, and facing different lead times and cost constraints.

A process map sets the sequence in which design activities take place. If the correct sequence of design activities varies, the process map should also vary. For example, consider a design team developing a new test instrument. On one project, the team may be introducing a new user interface. In such a case, the team should schedule an early test of the simulated interface to validate its requirements. Proceeding too far into the design process without such a test is suicidal.

In contrast, another project revolves around minor modifications to a well-accepted existing interface. In that case, user interface testing should wait until much later in the design process. There are similar issues in procuring and testing long-lead-time components, verifying technology feasibility, and validating new design approaches. The natural order of tasks on any specific design is uniquely determined by the needs of that individual design. When engineers violate this best natural order, they degrade the design process.

Nonetheless, the goal of providing structure to the product development process is sound. Engineers should not have to treat each project as if it was the first time they had ever done product development. Isn’t there some way to embed a company’s learning and experience in the process without making it rigid?

The answer
Every written language is an example of a structure with flexibility. Consider the English language. It has three levels: letters, words, and sentences. At the lowest level, letters, it is rigidly standardized. Those using the English language cannot invent new letters. Consider the next level, words. There are about 450,000 words in the Oxford English Dictionary, of which high-school graduates might commonly recognize 40,000. There is almost complete standardization at this level. It is possible to introduce new words into English, but they are likely to confuse other people. At the highest level, sentences, there is a small set of syntactic rules, such as the subject-verb-object word order. Otherwise, English users have enormous freedom. This freedom lets us produce an infinite number of well-formed, understandable English sentences. English owes the infinite flexibility of its highest architectural level to the standardization of its lower two levels.

This contains an important clue for combining structure and flexibility. It is impossible to standardize the top level of development processes. No one can create enough process maps to anticipate the needs of every project. Yet if we fail to offer variety at this level, some individual projects will suffer.

At the same time, it would be foolish to let all levels of process development be flexible. After all, the English language would be incomprehensible if everyone created their own letters and words. And if the lower levels of the development process aren’t standardized, the overall development process won’t be flexible, it will be chaotic. True flexibility comes from standardizing the lower levels, because this permits reconfiguration at higher levels. Paradoxically, structure is the key to freedom, and standardization the key to flexibility.

The example of language illustrates a means to combine flexibility and structure in the development process. Companies should standardize the lower levels, not the top level. This is called a modular-development process. In such a process, 20 or 30 standard modules can be combined to produce millions of possible process configurations. Teams simply alter the sequence and use of these modules to adapt the process map to fit individual projects.

Creating development-process modules
Companies should begin by defining these reusable modules, the heart of the process design. They capture what is learned in individual projects and make it accessible to later projects.

There are many ways to create such modules, but the easiest is to extract them from existing project plans. Such plans already depict natural groupings of activities such as user interface testing, regulatory approval, and tooling procurement. Each of these activities is a candidate for a process module. Because past programs had different requirements, existing modules must usually be modified to make them truly reusable.

The trick in module definition is to focus on interfaces rather than the module content. By hiding the details of internal module implementation from the user, companies create much more robust modules. Companies can concentrate their efforts on defining well-structured external interfaces while preserving design freedom in the modules’ internal structures. These well-planned external interfaces can provide a great deal of flexibility, the key to making the modules reusable.

For example, consider the activity of Reliability Assurance. There are a variety of ways to assure reliability in product development, including design rules, component and prototype testing, life-testing of final production versions, and field testing. The owner and designer of this module would be Reliability Engineering. Inputs to the module are specific objectives, constraints, and data. For example, an objective might be attaining a 100,000-hr mean-time-between-failures (MTBF) with a 99% confidence level. A constraint might be the time and budget allotted for testing. Inputs may consist of design specifications or physical implementations of the design, such as prototypes. This module’s output would be specific reliability data at specific times in the project. It would be common to sequence this data so it’s available as an input to major investment decisions. Once the inputs and outputs are defined, the module owner can worry about internal methods of assuring reliability.

The power behind this approach is that the choice of method to assure reliability is now hidden within the process module. This means the method may be flexibly tailored to fit the needs of an individual program. For example, if a company was designing a toaster which would be used only a few minutes per day, it could dramatically accelerate testing. Running the toaster continuously may put as much wear on the toaster in one day as normal consumers would in six months. In two months, continuous testing could simulate many qualities of a 20-year operational life. Thus, accelerated life testing would be an appropriate method for such a program.

In contrast, consider what would happen with a company designing a disk drive that will operate 24 hours a day with a requirement to achieve a 1,000,000-hr MTBF. It would be impractical to test the drive for 100 years before releasing it. Instead, another method must be found to assure reliability. In this case, developers could use subsystems with proven and tested reliability, and calculate an overall system-level reliability. This is a case in which calculating reliability is more practical than testing.

In both these instances, inputs to the Reliability Assurance module are objectives, constraints, and data, and the module has to output certain information. What is radically different between these two projects is the timing of Reliability Assurance activities and the specific methods used by reliability engineering. Because the external interface instead of the internal activities are standardized, the module can be reused by other projects.

This process architecture is tolerant of change because most changes will only affect the module’s internal structure. It could easily accommodate new testing equipment and methods without having the development procedures rewritten. Thus, modular development processes are both well-structured and flexible.

When designing these modules it is important to assign each process module an owner. Owners are responsible for designing their particular module, defining its interfaces, and determining its inputs and outputs. The owner of the Market Research module, for example, may request inputs that identify the questions to be answered, the customers to be questioned, and the degree of confidence wanted in the answers. In some cases the module’s owner and designer can be different than the user. For example, a documentation activity for a piece of medical equipment may be defined by Regulatory Affairs, but prepared by engineers on the team.

Process templates
Once the modules are in place, there has to be an overall structure for using them. In practice, individual modules don’t appear at random in development processes, but rather they follow certain natural sequences. For example, a prototype has to be built before it can be tested.

These natural sequences are indicated by process templates. Such templates show different ways teams can wire together modules into a process. It’s normally best to have at least two examples, because a single template is too often interpreted as the best way to connect the modules. These templates should be incorporated in an organization’s development procedure.

With the modules defined and the process templates completed, the modular process is ready to use. Each new development team should begin projects by proposing a plan. This plan is created by modifying existing templates to meet the unique needs of each particular project. Teams will tell management which process modules are necessary on their program and when these activities should be sequenced. For example, on a project trying to cut costs on an existing product, it may not be necessary to use the Market Research module. On a project that heavily reuses existing components, Vendor Qualification activities may be superfluous.

The team’s proposal is reviewed by management, giving the team access to the full experience embodied in the organization. Management may add or delete process modules or alter their timing. The final configuration is authorized as that specific project’s plan. Authorizing unique process maps for particular projects is a key management control point. It is particularly important for ISO-certified companies to maintain this control. If they don’t, the fact that they use different processes for different projects may be interpreted as a lack of process. Instead, companies must demonstrate that unique process plans are a calculated choice, not sloppiness.

Once programs are underway, process plans can be revised at prearranged points. Key management reviews are a good time to do this. This allows companies to modify plans based on information that emerges during the process. Again, it is useful to demonstrate that these modifications are a formal decision by management, not accidental changes due to lack of process control.

The key to creating a killer development process is to concentrate efforts at the right level. By creating a library of process modules designed to be reusable from project to project, companies will have the building blocks to create a wide variety of appropriate project plans. These plans can be tailored to the needs of particular projects and still reuse existing processes. Structure and flexibility are not natural enemies.

Don Reinertsen is coauthor of the book “Developing Products in Half the Time” and author of the new book “Managing the Design Factory: a Product Developer’s Toolkit”. He can be reached at (310) 373-5332 or by e-mail at Don [email protected].

© 2010 Penton Media, Inc.