Yesterday I wrote about the potential for making big estimation errors by poorly choosing the three points of a three-point estimate (minimum, most likely, maximum). Today, I’d like to write about the problem of not updating estimates as new information becomes available.
Not updating estimates is a HUGE problem with traditional, waterfall-based project management. In a traditional project, the project is initiated with a very high-level set of constraints (a high-cost estimate of the project cost and schedule is usually in the project charter), and then the work of project planning commences. In the project planning phase, the business requirements are written out in detail, a detail design explains how the customer’s desired business requirements will be satisfied, and a project phase-gate occurs before development work begins.
At the project phase-gate, project approvers examine the detail design and the project plan that lists all the tasks for the remaining phases of the project, who will perform those tasks, how much those tasks will cost, and how long they will take to complete. If you use project software correctly — like Microsoft Project — you should be inputting the resources, their respective hourly costs, and the work effort they’ll expend to complete the task, and then the scheduling engine will create the project schedule for you. At this phase-gate, the project plan is baselined and the whole project team is on the hook to complete the project at the cost and schedule listed on the project plan file.
And then, those estimates are locked-in, written in stone, and everyone is held accountable to them.
Yes, traditional project plans have change control systems that allow changes to the project plan, but the whole change control system is designed to minimize or eliminate change, and often there are unpleasant political consequences for any team who uses this system to revise the project plan.
That’s a mistake. That’s a HUGE mistake.
It is well known and well researched that no product owner can write business requirements so well that they never need to be revised or refined. And no project team can create a detail design and fully identify every aspect of the solution. In real life, new information arises, and in a traditional project approach, that new information is never utilized to refine/revise the project estimates that were made at the last phase-gate.
This is a worse problem than poorly choosing the three points of a three-point estimate, because if you don’t create a way of leveraging new information — without penalties, without political fall-out — you create a terrible organizational culture that hides its mistakes, makes bloated estimates to cover for possible mistakes (and when that happens, Parkinson’s Law ensure that the bloated estimates always appear right-on-the-money), and you don’t learn anything about how to make better estimates in the future.
Poorly choosing minimum, most likely, and maximum point-estimates is bad, and much worse than a 2% or 3% mathematical error in using a technique like Statistical PERT. Willfully ignoring new information and failing to revise earlier estimates, however, is an order-of-magnitude worse problem.