One of the books in my queue of to-read items is Making Things Happen: Mastering Project Management by Scott Berkun. I skimmed over some parts of it this afternoon and found some interesting bits. Here’s some stuff on processes. Would be nice if the scenarios described below aren’t too familiar in your own organizations.
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. 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 power can come up with the most mind-numbingly idiotic system for doing something and 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 he has enough power, he can quell any mutinies 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 past insists on inflicting that method or process on every new team he leads. This is bad because prior success with X is relevant only if the current situation is similar to past situations. The real acceptance test for a process should emphasize the needs of the present over observations about the past.