The following content is based on the whitepaper, “Bigger Than a Breadbox: 10 Tips for Better Project Estimates, Part 1,” written by Jerry Manas.
Are you good at directions? You know, simple things like knowing where you’re going when driving, which way you should move to avoid colliding with someone on the sidewalk, that sort of thing. Sure, those may be silly examples, but I have a point, promise. When it comes to improving project estimates, you must know your directions—you must know which direction you should use to develop an appropriate estimate.
What exactly do I mean by that? You’ll see, but first, check out part one of this series, “Improve Project Estimates and Escape Crisis Mode,” if you missed it. There, you’ll find tips 1-3 of the 10 tips for better project estimates. Tip four is rather important and lengthy, thus it is getting its own blog. If you didn’t guess already, it’s all about direction in estimation methods.
Tip 4: Sizing it up (Estimation methods)
Depending on the level of estimate being given (i.e., order-of-magnitude, budget, or baseline), there are several techniques that can be employed for providing effective estimates. The various methods available primarily fall under two main categories: top-down, and bottom-up. Here’s where you need to know your directions, *wink wink.
- Top-down methods are generally used for order-of-magnitude and budget-level estimates. Some examples, which can be done in combination or separately, are:
- Analogous – Comparing the project to a prior, similar project. There can be many differences, such as the people involved, technical variables, the cultural or external environment, the process undertaken, and other elements.
- Expert Opinion – Having a SME provide an estimate based on initial analysis. This is often the most accurate type of top-down estimate.
- Parametric – Using a calculated parameter, such as $2 per line of code, x hours per program, etc. When there’s a lack of subject matter expertise, this is an alternative approach.
- Function Point Analysis – A more intensive type of parametric estimate for software that involves adding up the occurrences of different types of components (e.g., external inputs, external outputs, interfaces, etc.) multiplied by the complexity of each occurrence.
- PERT (Program Evaluation and Review Technique) – The PERT calculation is P+O+(4*ML)/6, where P is the Pessimistic estimate, O is the Optimistic Estimate, and ML is the Most Likely Estimate. This gives a weighted average toward the most Likely estimate. The pessimistic estimate assumes most or all of the suspected risks will come true, the optimistic assumes most risks will not some true, and the most likely assumes only the ones with high probability will come true. PERT is rarely used these days but can be useful for specific tasks with great uncertainty or those with many risks, if only for providing a certain level of credibility to your estimate.
- A bottom-up estimate is one in which the individual project tasks have been estimated by the resources and/or SMEs (and sometimes, though not recommended, “guesstimated” by the product manager), and then those estimates are rolled up to the project level. Once a bottom-up estimate is established, it is typically saved as the project’s Baseline Estimate, which may then be revised if approved changes have rendered the original baseline irrelevant for tracking progress. In either case, the original baseline should be preserved for later analysis.
- Another consideration for bottom-up estimates is duration vs. effort. Duration is the length of time it takes until the task is completed, whereas effort represents the resource hours that are required to complete the task. The best practice is to estimate both, but to manage the schedule based on duration estimates. Duration drives the schedule. Effort drives the cost—and contributes to the duration.
- Lastly, bottom-up estimates should reflect current reality. Actuals deal with the past, but duration and effort deal with the future, i.e., the remaining portion of the schedule. Thus, it’s important to realize that a schedule is not something to be set in stone or put on a wall to be admired. The schedule aims to predict reality, but ultimately it is a living, breathing entity that must also reflect reality. Otherwise, it represents nothing but wishful thinking. This is where the contributor estimates come in…which we will cover in the next part of this series.
…To be continued.
It’s important to determine whether your project requires a top-down or bottom-up estimate before you get to deep in the trenches. You want to get it correct right at the beginning, saving yourself a lot of headaches later. Put those directional skills to work. Stay tuned for part three of this series, where I will cover the next three tips: the GPS of estimating (contributor estimates, earned value, and earned schedule); where PPM technology fits in; and estimates and resource availability.