Practical Project Cost Management

Blimey, I don't trust anyone to effectively estimate their time over any period greater than 5 days. And I tell them to add 20%...

My main problems are that the author has failed to distinguish between estimates and plans. They are not the same, or rather, they should be treated differently.

When you consider plans and estimates as identical, two things happen.

First, your estimates start becoming subject to political pressure. After all, the only reason anyone starts a project is to meet some goal or goals. And those goals tend to come with certain constraints. If you work backwards from the goal, you get a plan and then suddenly, if the plan disagrees with the estimate, guess where the pressure goes?

Likewise, if you simply take your estimate and transform it into the plan, you've failed to plan adequately. An estimate is a probablistic statement about some future outcome. By itself it fulfills one and only one of the required features of a plan:

* Job sizing: How big is this job, and how long do you expect it to take?

* Job structure: How are you going to do the work? What will you do first, second and so on?

* Job status: How do you know where you are? Are you going to finish on time and are the costs under control?

* Assessment: How good was your plan? Did you make any obvious errors, what mistakes should you avoid in future, and how can you do a better job next time?

If the estimates were actual estimates, expressed in terms of uncertainty, then the "overflow" statement is a nonsense. In fact all such approaches are a nonsense, as they require hundreds of people to miraculously become expert forecasters in what are often novel tasks. Given how many ways people can fall into the "planning fallacy", that's unfair. Estimation deserves at least a structured process of its own -- whether by parametric model, points poker or PERT 3-point estimation.

Disclaimer: I'm a bit of a wingnut about estimation and I've been working on a tool to make it easier and better.