In my previous entry I discussed the underlying theories of plan-driven PM methods (based upon an article from Lauri Koskela and Greg Howell). I ended with the cliffhanger that I would inform you about the problems these theories generate… Tada… on with the show!

We have the theory of project, management-as-planning, the dispatch model and the thermostat model. So why does this combination suck?

What is wrong here? Well, actually all assumptions underlying this way of planning are causing problems.

Problem 1

Management is thinking all by themselves, all alone about how the job has to be done (central planning).

In a complex environment as software projects it is impossible for non-experts to know what the exact planning should be. Of course the project manager will be the negotiator that integrates all different aspects, but it is a team effort.

Problem 2

Management is thinking that the paper plan will automatically be executed in the way it is described.

People are not machines. You cannot throw an instruction to the bottom of the corporate food chain, expecting that the employees will pick it up and without questions will execute the instructions. No way. People need motivation, people need to be involved in the creation of the tasks they will have to perform.

I once wrote: "how to ruin a perfectly good process? Give an order." With the highly educated people we have in the software business they have a strong wish of participation when it comes to determine what and how they should do things. Also for the time frame in which they should do things they have a strong opinion. Not letting them participate in the "planning" stage reduces the commitment they have for the work to be done. Things like "not-invented-here syndrome" and "if you think you know better…" will ruin the project (In this way it is linked to problem number one).

Problem 3

Management is thinking the plan is correct (there is no room for deviations).

With all the uncertainties that are in a real project there is no way you can predict the future in advance. The plan will not reflect the reality just because the simple fact that the plan is wrong. This is no biggie, this is just as it is. If you try to keep on changing the process to steer reality towards the preset expectations, you are doomed.

A side effect of this is that people are most of the time judged by how well they comply to the preset goals in the plan. If you do not comply to the goals this is seen as a failure. The creative solution to counter this is just to rapport that you met the goals, even if you didnt. A few years ago I worked under chief of a project management office that always changed the progress reports in such a way that the overall performance of the PM office looked good. The report used smilies (yuk) to indicate any risks. Red smilies signaled something potential not under control, and you can have none of that!

Even if you dont manipulate the indicators, you would still use a large amount of your time explaining why you didnt comply to the preset plan. Where as the real reason (the plan sucked) is not considered an sufficient answer.