Volume 5, Issue 2 March 21, 2003

article-one:
Exceptional Management

Not all products are the same. Not all development teams are the same. Why then do companies try to create standardized development processes? Logically, any company attempting this does so to alleviate perceived problems with recurring errors, things like rework, slow cycle times and information defects. The theory is that a formulaic approach will drive down process variability with benefits similar to how a standard tooling process will drive down defects and scrap in manufacturing. Unfortunately, this is not without its costs.

One example of the problem with standard processes was pointed out at MRT's recent "Fast & Flexible Product Development Conference" by one of our keynotes, respected consultant and author, Don Reinertsen. Don asked the audience how many people follow a phased or gated process and approximately 75% of the audience raised their hands. He then asked how many people have experienced project teams that have begun new phases of the project prior to the formal passing of the previous gate. Almost the same number of hands were raised again. I've seen him ask this of groups before with the same results. It's clear that teams consistently break the rules of gated processes.

Most would say that while a company may have a documented formal process, in many places it's understood that the rules may be broken as needs warrant. But that's exactly what the problem is - this rule is unwritten and therefore dangerously ambiguous. It's been said that the beauty of the US constitution is that it can be amended, that the founding fathers allowed for adjustments as time and society evolves, although our effectiveness with this feature is debatable. Most standardized development processes do not explicitly allow such flexibility. Also, within many organizations, especially engineering, some folks are strict rule followers, and they will defend the rules of the process much like some folks defend freedom of speech, which can create a lot of tension.

I call this type of rule breaking "exceptional management." There is also an established term for the type of damage this can cause among your staff. That term is "cognitive dissonance." Cognitive dissonance occurs when you are put in a situation where you must contradict an idea that you have already accepted. Let's say you are an engineer on a team who has been trained on the formal phase gate process. When your project is up for gate review, the team leader already has the team working on the tasks of the next phase, before you have been approved. When you protest to your manager, he tells you it will be ok, the project is eventually approved, and there are no negative consequences for not following the process that you've been told is so important. You are now put in a situation of cognitive dissonance, where you not only no longer respect the process, you also develop a healthy disrepect for any new formal procedure that management dictates. This is a very damaging and real scenario at many companies.

What probably needs to happen is that "exceptional management" needs to become a formal process. By that I mean that while it's a good idea to have a template that gives you a place to start and acts as a 'wizard' for truly standard aspects of development (like checklists), it may be worthwhile to allow all projects to list the parts of the process where they need exceptions. For example, one project may need a looser front end review because it contains little new technology from the previous model, while a brand new project may need a stricter early gate approval because it contains more new technology that requires testing. As customers become more and more accustomed to having products customized to their individual needs, the same needs to happen to the process that produces those products.

Should your company be making their process more flexible and project-specific? Should the exceptions become the rule? Chances are your teams are already doing it anyway.

We share reader reactions to TCP articles on our website.
Please send any feedback to gregg@roundtable.com

---

---