Organizations are often unable or unwilling to estimate project effort or cost. I get it. Detailed estimating is hard and requires work. A lot of times, our project has already been approved to enter execution – and we had to do estimates to get through the approval process. What would be the point of preparing any further estimates? After all, isn’t the budget sufficient for executing the project?
Taking that one step further, I find myself having to explain the difference between a budget and an estimate – or the functional difference between a high level estimate and a low level estimate. It puts me in mind of this great quote I saw the other day in Mintzberg, Ahlstrand, and Lampel’s rockskip over the surface of strategy, Strategy Safari:
“Somewhere…between the specific that has no meaning and the general that has no content, there must be…for each purpose and each level of abstraction, an optimal degree of generality.”
-Kenneth Boulding, “General Systems Theory: The Skeleton of Science,” Management Science (1956:197-198) – reprinted in Strategy Safari.
From an academic standpoint, budgets are developed from the top down and define the limits within which you can spend. As I discussed in The Importance of Cost Abstraction, estimating is required for project control. But how do you know when you’ve estimated enough? How do you know when the estimate is thorough enough for project control purposes? Sometimes we go through several iterations of budgeting – until the final product is actually quite developed. How do I know when I’m done?
The answer is that you know the estimate is thorough enough when it is detailed enough to support your control purposes. Huh? To paraphrase the PMBOK, “The process is detailed enough when it generates an output sufficient to support the next process.” This means that the estimate is sufficient when it supports the next process downstream, or the project control process.
Now, here’s the trick. One process’ estimate is the next process’ budget. Meaning that the estimate I developed in pre-approval, which might allocate work by role and by month is insufficient in detail for project execution, where I am focused on elements of near term resource contention. Hence, I need to take my estimates by role and by month, feed them into my scheduling process, and develop a detailed estimate of resources by name and by day. Repeat as required.
With each successive process, I take the estimate from the last process and refine it even further. When it gets to the schedule, specifically a schedule created to drive resource management, the estimate is key. And at this point, the estimate should not be driven by resource allocation requirements. At this point, the estimate needs to be driven by the work. That work may then be mapped back to the allocation to define project feasibility.
The estimate needs to be driven by the thing. The specific deliverables of the project must be decomposed into a WBS, and then the tasks required to generate that defined (using an SDLC) and mapped to each of those deliverables. Work estimates may then be placed on each of those tasks. If you took another approach, you are wrong. You’ve created a reporting schedule, i.e. a simple construct that shoehorns the expected data into the expected shape – not something that accurately models the future.
Where is a problem identified in this estimating chain? A problem will exist when we can map the detailed process output back to the less-detailed process input and determine that there’s an issue. Either the detailed estimate exceeds the amount allocated at the beginning of the process or the detailed estimate comes in significantly below the amount allocated at the beginning. Either of those results indicate that the process is working – and that we’re developing our estimates properly. If any of the steps in the project approval process cannot either validate or invalidate the original allocation, then they should be revisited.
How do I know when I’m done? When the estimate is driven by the work. When I’ve decomposed the deliverables of the project into specific tangible things. And when I can tie each task back to one of those things, and then to a specific work estimate. That’s when I know I’ve reached the end of the estimating road: when the schedule is the thing.