Once again, Mr. Big, the general manager of the Bison Valley Ax Works, was upset with his disorganized engineers. Remembering how process maps had improved the operation of his factory, he decided to take action. He called Grnk, the vice president of engineering, into his office and said, "You need a process map in engineering. Assign a team of your best engineers to this task." Grnk, who was wise beyond his brain size, knew that it would be foolish to oppose Mr. Big. Instead, he assigned several of his best engineers to create the ultimate process map.
Several months later, they returned. The ultimate process map had been carved into the north wall of the prototype cave, and the entire engineering department gathered to see the map. Unfortunately, even then engineers were intolerant of foolishness. Instead of applause, the team was bombarded with dung. Apparently, the process map was only suitable for the single project upon which it had been based. Even worse, that project would have been done a different way if it had been repeated.
Why don't detailed process maps work for product development? They were developed for inherently repetitive processes like manufacturing, whereas engineering is a nonrepetitive process. Producing an identical design twice adds no value. When undertaking a new project, engineers must take new risks. Because the biggest risks should be addressed earliest, the correct task sequence for different projects is likely to differ. This means we can't mandate a strict and universal sequence of project events, as a process map does. Instead, we need the ability to adapt the task sequence to the actual needs of a project.
If process maps don't work, is chaos the only alternative? No. I believe there's a fundamentally different approach to the development process architecture. Let me use the architecture of the English language as a model. At the letter level, there are the rigidly standardized 26 letters. You cannot add another letter to the English language. At the word level, a college graduate will recognize around 100,000 words. We have almost complete standardization at this level. If I say, "I want a glass of water," we generally agree on what is meant by each of the words in this sentence.
The sentence level of the language is where things get interesting. We have some rules of syntax like subject-verb-object word order, ("The engineer ate the fish" is not the same as "The fish ate the engineer."), but we have no true standardization at this level. One can produce an infinite number of comprehensible, well-formed English sentences. Even sentences never seen before in the history of the world can be comprehended by the listener.
Natural languages achieve infinite levels of variety without degenerating into chaos by standardizing the lower levels of the language's architecture. How does this apply to product development? A good development process must also combine structure and variety. This cannot be achieved by focusing on the top level of the process architecture. Instead, we must focus on the underlying building blocks of the development process. A finite set of process modules, wired together differently for different development projects, gives us both flexibility and structure. In contrast, the only thing you get from the universal process map is a guarantee that it will be universally suboptimum.