The Art of Project Management

10.2. The effects of good process

I define a process as any repeatable set of actions a team decides to perform on a regular basis to make sure something is done in a certain way. Processes go by many names: rules, guidelines, forms, procedures, or restrictions. (For example, how code gets checked in, tested, and built is a common example of an engineering process. Others include spec writing and reviews, tracking bugs, managing calendars and schedules, etc.) A good process improves the odds of the project being completed and has benefits that outweigh its costs. However, because time is rarely spent considering why certain processes exist, or what problems they (should) solve, many teams live with lots of processes, without the benefits they can provide.

Sometimes, the problem is who's in power. Any idiot with enough authority can come up with the most mind-numbingly idiotic system for doing something and try to force the team to follow it. Then, when the team manages not only to survive that process but actually ship something, the person in power may even point to the process as a contributor to the success (blind to the fact that the team was successful in spite of the stupid process). If they have enough power, they can quell any mutinies or pleas for sanity and continue torturing the team by adding even more procedures.

Other times, the problem is the philosophy: "X worked before, so let's do X." In this situation, a team leader who has done something a certain way in the ...