12 System Development Lemming Cycle

Driven by CMMI, SPICE, ISO9000, or other process improvement programs, many companies set up in-house standards for their development processes. Naturally, these process models come with prescribed roles that members of the development team must fill, the activities they must perform, and the artifacts they must create. Most of the process models acknowledge that not all projects are created equal. Therefore, some of them (such as the German V-Model and the Rational Unified Process) come with extensive tailoring guidelines to adjust roles, activities, and results to project constraints.

Tailoring the process and (especially) pruning the results requires courage. If you leave out certain steps or decline to create some of the required deliverables, you leave yourself open to criticism if the project fails. Critics will be quick to point out that the project would have succeeded had you been more faithful to the process and created all the suggested documents. The fear of criticism–or perhaps the fear of punishment–can bring about a reluctance to tailor. The result is that the team plays safe, produces a full-blown requirements specification with all the suggested chapters and paragraphs, creates the quality management plan (including sections for each milestone), creates work assignments for each package in the work breakdown structure, and so on, for the full extent of the process.

    When I asked Philippe Kruchten what he would change, he replied to the effect that if he could develop the Rational Unified Process one more time, he would make tailoring and adapting the process to a specific project much easier and tool-supported to encourage projects to really do it. –PH

Lack of courage is not the only reason for not tailoring. Often, the reason is much simpler. Tailoring a process to fit the project’s constraints requires work. And the project manager is simply too busy with other, more-urgent project matters to brainstorm and establish the rules for the game. The argument goes something like this: The company has hired clever people (outside the project team) to define the processes and the deliverables. Why should we question their wisdom? Let’s simply go for it. They can’t be that wrong. And–by the way–nobody pays me for changing the process to fit my constraints. So let us not waste time on process adaptation; we’ll simply do it the way everybody does it. That way, we can start with project stuff immediately.

Sticking to a process that is poorly matched to the project’s real needs can get the work started earlier, but not finished earlier.

A project manager not tailoring the process is like a cook working strictly from established recipes. He will never become a great chef. Of course, even great chefs start out as apprentices, learning the basic mechanics of food preparation from their masters and copying their masters’ recipes. But they will only stand out if they learn more than the basics of the trade and stop cooking from standard recipes.