I initiated and managed a lot of projects over my career of 30 years or so. Along the way, I observed some common mistakes, both my own and others, that impact the quality of estimates for cost and schedule. Much of this comes down to the way these estimates are prepared. I’ve got a few thoughts to share on managing the preparation of preliminary estimates, so that proposed projects can be approved based on information that the decision makers can believe reflect an understanding of both the problems and the solutions, and how to achieve them.
An Estimate is Based on a Model
Any estimate of the labor and non-labor costs of planned work must be based on an understanding of what work needs to be done, how it will be accomplished, and who will perform the work. In other words, a project plan. A good estimate should reflect a range of possible values, with a confidence level, and should document identified risks and related assumptions, including an assumed start date.
A project plan is not merely a schedule, depicted in a Gantt chart. It reflects a number of decisions, from scope and high-level requirements to how the transition from the current state to the end state will occur. It takes constraints, non-functional requirements, and relevant organizational processes into consideration. In addition to direct work on deliverables and supporting activities in the Work Breakdown Structure (WBS), it includes plans for activities such as acquisition, staffing, cost reporting and budget management, risk management, security, and likely others. All of these plans are combined in what is known as integration management. Taken together, they constitute a model of how the project will be executed, which can be used as a basis for meaningful estimates.
What, How, and Who
The matter of what work is to be done is reflected in the WBS. The most meaningful estimate of project costs is rolled up from estimates for each work package. Note that initial work package estimates should assume that all inputs and other resources will be available. Dependencies must be planned for, but work on that when scheduling, rather than when when estimating. There are usually few completely new tasks in most projects, and past experience should drive estimates, even if different people will perform the work. Three-point estimates should be prepared for each work package—most optimistic, most likely, and most pessimistic. These parametric estimates can then be used in Monte Carlo simulations of the project.
How the work will be accomplished is a technical matter. An architecture or technical approach document, based on the high-level capabilities required for the delivered product, is a practical minimum. A more detailed design document is better, if available for an initial estimate. Either way, know how you’re going to skin this cat! Make any necessary assumptions and document them to be delivered as part of the overall estimate model.
Note that the who doesn’t usually need to be a specific, named person. It’s helpful to have an assigned team before any estimates are required, but that isn’t usually the case, unless it’s a purely internal project to be performed by an established team. It is conventional wisdom that those who will perform the work provide the most accurate estimates, but that isn’t always the case. For projects where some of the work will be performed under contracts or by contingent workers, you may have to make estimates with a lower confidence level, but that doesn’t mean that they can’t be useful.
The goal of estimating should be to reduce uncertainty to a level where decisions and commitments can be made. Not commitments to a precise cost or schedule, but simply to proceed, in pursuit of specific benefits. And that decision to proceed must always be contingent on evidence of progress commensurate with expectations. As the project progresses, actual cost and labor figures can be used to update the estimate, further reducing uncertainty, so that decision makers can re-commit to continuing the project. As the project plan and schedule evolve, the estimate model should track that evolution. A baseline estimate is necessary, but so is a current estimate.
The best estimates open a dialog. You wouldn’t seriously support the Hashtag, “#NoCommunicating,” would you?
We should not manage on a ballistic trajectory, where nothing can change between pulling the trigger and impact on the target. Like modern guided missiles, continuous corrections must be made, in order to optimize the effects of scarce resources—human, financial, and calendar. Agile methods are commonly used these days, but there are others, such as stage gates. Whatever governance model is used, a detailed estimate model, updated throughout project execution, will provide much better decision support than a round number.