Secrets to creating the elusive 'accurate estimate'


Estimates done by several people have a much better chance of being more reasonable and realistic.

by Neal S. Gray, PMP

the first step toward realizing an accurate estimate is to understand there is no such thing.

Accurate means “flawless, correct, actual, exact,” and an estimate is “an opinion, a statement of the approximate, a guess, an impression.”

Combining the two, an “accurate estimate” is an oxymoron, but this does not change the fact that project managers are asked to provide them.

In project estimating, hope for the best but plan for what is most likely to occur.

By understanding the limitations of the estimating process, project managers can use the following “secrets” to more clearly define expectations and provide a better idea of the possibilities.

Secret 1: Better estimates require better information. At the outset, it's difficult to really know enough to estimate effectively without further elaboration. For example, until a homebuilder is fully aware of what is expected in a home, there is no way to know what the costs and timeline will be. This is no different than projects in any other industry.

Further, talking with the customer to determine requirements and exactly what is desired can take some time (often in short supply), and various alterations may be required before final approval. Once this is accomplished, a fairly reasonable estimate is possible, and completion dates can be established. All projects must go through this common process of understanding before estimating, and yet in the heat of having to “get on with it,” project managers are pressured to estimate with little or no knowledge.

A big step toward gaining better information is the creation of a Statement of Work (SOW) agreed upon by the business customer and project manager. Without an agreement on what the work will encompass, it's impossible to successfully execute a project. In addition, the Project Life Cycle Methodology is a basic recipe for a consistent process. By taking one phase, iteration or release at a time, it's possible to redefine and re-estimate work at various points along the project course.

Secret 2: Never estimate alone. Project managers often feel they must fend for themselves when creating estimates. It is important to have several people involved because each person approaches the process with personal blinders, filters and biases based on past experience.

Wideband Delphi estimating is an excellent inclusive technique. This involves three appropriate subject matter experts— people who have relevant experience in the product, application, tools and technology being considered. They are given the same information about the project and then create their own estimate without consulting each other. After the first round of estimates, the three experts along with the project manager have a consensus discussion to finalize the estimate.

Estimates done by several people have a much better chance of being more reasonable and realistic than what can be achieved by a single person in a vacuum.

Secret 3: It is better to be approximately right than absolutely wrong. Specific single number responses tend to be wrong, while range estimates tend to cover a more realistic set of possible outcomes. This is especially true in the early stages of a project, when there are many unanswered questions and uncertainties.

While management usually expects a fairly specific estimate covering everything from concept to final construction, in the early stages of the project (usually through project design) it is appropriate to talk in terms of ranges instead of specifics.

Using a Normal Distribution and a single standard deviation range, an estimate may range from a low, which the project may improve on about 16 percent of the time, to a high, which the project may overrun about 16 percent of the time. Using this range, the estimator would be 68 percent confident that the project answer is between the high and the low. As better information is obtained (through the early phases of the project), the range numbers can and should be tightened.

Secret 4: A consistent process yields improved estimates. There are hundreds of formulas, tools, techniques and software packages to help in estimating, each with its own quirks. Choose two to four techniques that will consistently be used depending on different estimating situations, like a top-down technique (Function Points) for sizing or a bottom-up approach (Estimating Matrix) for detailing.

The chosen estimating methods must be:

image Workable, something that can be used with reasonable confidence and comfort

image Logical, something that can be explained to and understood by others

image Consistently applied, so that the estimator can become adept at its application

image Self-improving, a technique that can be revised as actual results are tracked and compared with estimates.

Secret 5: Overly optimistic estimating always will cause trouble. Whether time, money or job resources, the actual project seldom ends up as hoped. Project managers know (based on past experience) that they should not be overly optimistic. However, because management or business customers want or need optimistic forecasts, there is strong pressure to be a positive team player.

Based on this expectation, the manager hopes and plans for the best-skilled people with the most business knowledge and greatest availability to work on the project. This tends to make the schedule look significantly better than reality.

A better philosophy is to hope for the best but plan for what is most likely to occur. By looking at past history and current project load, project managers can make realistic and reasonable expectations for the next project.

Secret 6: Estimates without associated risk assessments are worthless. Without qualification and communication of risks, an estimate is meaningless. By assessing risks associated with accomplishing the project for an estimated range, the project manager can show decision-makers the potential results and consequences of their actions. For example, the associated risk assessment may show that a project has only a 16 percent chance of finishing on time and on budget with a $300,000 expenditure and an 84 percent chance of finishing as expected with $800,000.

Secret 7: Gather the right people. It's important both to identify the right people to estimate the project and to know who will be involved with project execution. Project managers must know actual resources to produce better results.

If team resources are different than first thought (which is usually the case), it's best to have the real team help re-estimate the project based on what they believe it will take. With this new estimate in hand, the project manager must discuss discrepancies from the original plan with management and come up with alternatives (or discuss resetting delivery expectations based on what is possible).

Secret 8: Realize that project change will happen. Tomorrow will bring unexpected weather, human resource issues, new laws, business changes, management changes, new technology, new creative ideas and a host of other things. Anything that changes the understanding of what the project is will change the estimate. Change must be tracked and managed, and expectations must be set upfront. When changes occur, the estimate should be revised. One of the best ways to track change is a procedure that has all changes identified in writing and communicated between the project manager and the business customer. There should be a change budget held by the business customer to pay for any and all agreed changes. (See, in PMI's 1998 Symposium Proceedings, “Change Budget: One Key to Never Padding Estimates Again,” © PMI®.)

There are many other secrets, but understanding these basics is the first step to achieving more reasonable and realistic estimates.

Neal S. Gray, PMP, is a senior principal consultant with Keane Inc., a Boston, Mass., USA-based software development and consulting firm. He has conducted more than 200 U.S. and international seminars in the areas of project management, estimation, risk management and project manager competencies.

Reader Service Number 048

Don't forget to register for the world's premier project management event of the year, PMI's 2001 Seminars & Symposium, from 1-10 November 2001 in Nashville, Tenn., USA. For more information, visit pmi2001.

Reader Service Number 074

PM Network August 2001



Related Content

  • Project Management Journal

    The Dark Side of Projects member content locked

    By Locatelli, Giorgio | Kondstantinou, Efrosyni | Geraldi, Joana | Sainati, Tristano With this Special Issue and online collection, we aim to open the space for discussion (and more research!) on the dark side of projects and invite you to join our efforts.

  • Project Management Journal

    The Relationship Between Uncertainty and Task Execution Strategies in Project Management member content locked

    By Maes, Tom | Gebhardt, Karolin | Riel, Andreas Common project management methodologies do not consider project task uncertainty for determining appropriate task execution strategies.

  • Project Management Journal

    A Qualitative Analysis of Unethical Behaviors in Projects member content locked

    By Sarhadi, Mehrdad | Hasanzadeh, Sogand This research critically reviewed project ethics under the philosophical paradigm change from modernism to late modernism.

  • Project Management Journal

    The Dark Side of Projects member content locked

    By Locatelli, Giorgio | Kondstantinou, Efrosyni | Geraldi, Joana | Sainati, Tristano This article presents the dark side of projects, engaging project scholars and practitioners in discussions about sensitive, confusing, uncomfortable, challenging, and questionable phenomena.

  • Project Management Journal

    In Praise of Paradox Persistence member content locked

    By Gaim, Medhanie | Clegg, Stewart | Pina e Cunha, Miguel By analyzing paradoxes encountered in the construction of the Sydney Opera House project, we discuss how dialogical interactions enable options to emerge in the form of responses that were not…