Categories: Estimating
When it sometimes feels that estimating is nothing more than a guess, how can you improve your results? Better project estimates means you are more likely to hit your deadlines and budget. It’s easier to manage stakeholder expectations because you aren’t constantly telling them you’re running late. It’s easier to motivat eyour team because they know what’s coming up instead of living through shifting milestones every week.
Here are 5 tips for better project estimating.
1. Work to an accuracy level
Make it clear how accurate your estimates are. The more accurate they are, the more likely they are going to reflect reality as you progress through the project. But early on in the project you may not have enough information to estimate with any degree of accuracy. That’s fine, as long as everyone knows.
There are three broad ways of talking about the accuracy of your estimates.
a) Rough Order of Magnitude (you’ll see this shortened to ROM). It’s huge. It’s a range between -25% and +75% accurate. It’s really rough.
b) Budget estimate. This is between -10% and +25% so a range of 35%. That gives you plenty to narrow down your estimation. Note that you’ve got less to go under than over (as with the ROM).
c) Definitive estimate. Don’t let the terminology faze you: definitive still means you have a range of -5% for +10%. That’s still gives you a bit of wiggle room, but it’s about as definitive as estimates get.
Whichever range you use (or if you invent your own and use a range particular to your project as I have occasionally done) you must make sure that your stakeholders understand how you’re using the numbers. An estimate of $50k doesn’t mean you’ll hit $50k when it’s an estimate within a range. I’d advise that you always include the from and to figures of your range when presenting any numbers, to make sure that everyone is clear about what you mean.
2. Document your assumptions
Estimates are created from your assessment of the situation or task at hand. Your assessment is based on certain assumptions: it has to be because it hasn’t happened yet.
When you say a task will take 12 hours include the assumption that you’re expecting Claire to be allocated to this work: an experienced resource who has done this kind of work many times before. When you then get Joan allocated to the task – and she’s never done it before – you’ll be able to explain why the estimate has to be revised. An inexperienced resource is likely to work more slowly and need more time to check the work than someone who knows what they are doing.
3. Avoid optimism bias
Sometimes estimators are overly optimistic because they feel positive about the work that is coming up and they feel they can work around any risks. Sometimes there is pressure to hit a certain budget so estimates are forced optimistically low to make the numbers look good. Both those scenarios are dangerous because you end up with an unrealistic estimate before you’ve really started.
Be realistic. If you feel that the team has been too optimistic about what they can achieve, then review the figures or use another estimating technicque to bring some balance to the calculations. If that makes the numbers fit badly with the intended budget, consider reducing the scope instead.
4. Go low
High-level task breakdowns aren’t a good fit for estimating. You want detail. You want the smallest level of detail possible, actually. If there is no work breakdown structure for the project yet then think about waiting until one exists before trying to pull together the cost and time estimates.
Using a task list that is too high level results in missing out activities that may be costly. You can’t assume that your contingency fund will cover this when it’s your own estimating practice that caused any overspend: you’d be better off keeping contingency for true oversights.
So on the subject of contingency…
5. Include contingency
It’s tempting to strip contingency from the estimates at task level and then add it back in at a phase or project level. In fact this is a valid way to handle contingency, and may well be your preferred approach. However, when you add it in like this it’s still there. The problems come when you report or try to work to the estimates without contingency.
This makes your project look cheaper for your stakeholders. It might seem like a good thing, but how pleased are they going to be when you come in over budget having spent contingency that they didn’t understand was there?
Make sure your project estimates do include contingency and be explicit about how this is managed within your estimates: within each individual task, at a phase level, at the project level overall or some other way.
Want more on estimating? Here’s a video on the 4 pitfalls of project estimating.
