Better project estimates come from being specific about what we mean. There are so many opportunities to make assumptions on projects. When you are estimating is not the time to take shortcuts with understanding! Take this example:
- The project task is estimated at 20 days.
- Claire believes this is 20 calendar days.
- Julien believes this is 20 working days.
- Yan believes that this is 20 working days AND knows that in his country there are two bank holidays, so is mentally taking those into account.
The difference in the actual date of completion between Claire’s view and Yan’s view is significant, and has come about because of a lack of clarity around terminology.
Accuracy in all things is important, but never more so when you are trying to put together clear and precise estimates to help you plan your project adequately.
There are three main ways of discussing accuracy when it comes to estimates. Let’s take a look at those here.
Rough Order of Magnitude
You’ll see Rough Order of Magnitude shortened to ROM. As ranges go, it gives you a lot of space to play with. It’s a range between -25% and +75% accurate. I’ve also seen ROM as ±50%. Either way, you have a span of 100%.
If it makes sense to change the range to better reflect the message you are getting across, then do. The important thing is that you don’t simply report a figure and say, “within a rough order of magnitude this project will cost £150k.” Make it specific and call out the range:
- “This project will cost between £50k and £200k based on rough order of magnitude estimate.”
- “This project will cost £100k but we need to consider that’s a ROM estimate with ±40% accuracy.”
When to use it: ROM is useful when starting the project, or even before the project has really begun. Use it to show the broad target range of cost or effort when you are putting together the business case. It can help determine if it is worth continuing the project at all, and whether there is value in moving the project forward to more detailed scoping.
A budget estimate is between -10% and +25%, which gives you a range of 35%. That’s still quite a large margin of error, and in the eyes of many execs would not be seen as very accurate.
You’ll notice that the amount you can go under here is less than the range above your predicted figure (as is also the case with ROM). I think that’s because experience tells us that you are more likely to have underestimated than overestimated, taking into account optimism bias and the like, so you need to give yourself more headroom. Also, project sponsors are normally far more concerned about overspend than with coming in under budget.
When to use it: This is still quite a wide range and is not particularly accurate. However, it should be enough for you to use to put together your initial pass at a project budget.
The PMBOK® Guide (Fifth Edition) says that a definitive estimate is between -5% and +10%. Even though the phrase ‘definitive’ is in the title that still gives you a range to work within – again with more headroom in your estimate above the target figure than below.
When to use it: As your project moves forward, you should be in a better position to clarify your estimates and work within smaller and smaller ranges. At this point you can refine your budget estimates and any remaining ROM estimates to increase the accuracy levels as you get greater clarity and more and more information about the project tasks.
Accuracy in all these formats is really an expression of degrees of confidence. Your project management methodology may specify at which point you are expected to refine your estimates to the next level of confidence, or when accuracy should be reviewed. It makes sense to me to do this at stage gates or the end of phases as you transition from one project mode to another.
Whichever estimate range you use, the accuracy in understanding only comes if people know what you are talking about. In my experience, that generally means using the ranges in normal speech and reporting, instead of saying “£150k” and then adding a tiny footnote with your confidence level at the bottom of the report. Stakeholders take shortcuts: don’t make it easy for them to wilfully or otherwise misinterpret your estimates.
The more accurate your estimates, the more likely it is that they are going to serve you well throughout your project and reflect what actually happens during the project life cycle. You can only gain that accuracy by refining as you go as more information makes itself known. Sharing that with the team and with stakeholders means everyone has the same picture of the project and can make better decisions about how to take it forward.
What are your experiences of these types of estimates? Let us know your thoughts in the comments.