Project Management

5 Tips for Better Project Estimates

From the The Money Files Blog
by
A blog that looks at all aspects of project and program finances from budgets, estimating and accounting to getting a pay rise and managing contracts. Written by Elizabeth Harrin from GirlsGuideToPM.com.

About this Blog

RSS

Recent Posts

5 Tips for Exam Success

3 Options for Dealing with Team Conflict

What is Payback Period?

What is project cost control? [Video]

5 Things to Consider When Choosing Training Firms [Infographic]


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.

Posted on: April 08, 2015 09:23 AM | Permalink

Comments (19)

Please login or join to subscribe to this item
Thank you for this Elizabeth. On a recent project I tried to implement the range (although I called it confidence level). The response was amusing.

The range I was using was +/- 25% for a rough estimate. When I told the executive sponsor, I was told that I should be more honest and if I think it's going to cost 25% more I should up the estimate.

When I did, this caused other members of the management team to baulk at the costs.

To my never ending shame I bowed to the pressure and more so the final project budget was actually the original estimate - 25%. Needless to say the project was over budget.

Thanks, David, for sharing your experiences. At least you started out with the best practice. Sometimes that's all we can do!

Cautions or checklist for estimators, the contingency shall always be kept to avoid any shock in future.

Throughout my time working on projects I never met a senior manager or an executive who could cope with the fact that there is always an amount of uncertainty to any estimate or who cared about assumptions...
Sad, but true :-(

Thilo, taking a positive from your experience - at least you know what you're dealing with.

Thanks Elizabeth for posting - I always like tips that remind me to share information with Project Teams.

An uphill task indeed.... and then as Mr. Wack says people will not allow margin of error due to uncertainity

How many have seen their contingency moved to another ailing project? I saw this a lot, particularly when your project is progressing on time and budget, and your sponsor sees your contingency as available.

Thomas, luckily that's never happened to me or my teams, but I can see that a sponsor who doesn't truly understand project management processes would think of that contingency as 'available' and help themselves to it for another project!

One method that worked from me with some companies is to come up with best case, worst case, and most likely estimates based on the risk levels however, executive management are always attracted to best case estimate, not surprised off course.

Salam - yep, that's normal for senior managers! I understand their optimism, but a healthy dose of reality never hurt.

Is there a rule of thumb for ROM range for specific projects e.g. software?

I work on projects but am not required to participate in the budget, so I have no experience here. I provide the estimated cost of the software to be purchased, but I dont know how to convert this to a ROM. When I provide my analysis on requirements and software for purchasing, I often remind the stakeholders to consider adding a ROM, and a contingency reserve when proposing a budget. Can I suggest a rule of thumb ROM e.g. -/+50% or -25% and +50% and contingency e.g. -5% and +10% and advise that they consider similar or more tailored to the organisation? Can anyone guide?

Thanks

Thanks Elizabeth.

I hope I am not off-topic. But I think the accuracy level of the estimate and contingency/risk allocation is defined by the Estimator and not the requestor of the estimate. Each industry has different experiences and knowledge management records that so the ranges referenced may vary greatly from the ranges identified for ROM, Budget and Definitive estimates.

The Estimator will determine these metrics based on the completeness and level of detail for the input provided/available for the project/project, such as a comprehensive description, drawings, historical cost data, risk register, schedule, procurement plan.

• If the estimate input is for a new – never produced project/project, the contingency and risk allocation may be high (100+%).
• If the estimate input is for construction with 100% requirements defined and reflected on contract drawings with detailed Bill-Of Materials, and material take-off, the contingency and risk allocations may be low (10%).
• If the product/project was delivered by the organization within the last 2 years, actual expenses may be available that enable the contingency and risk allocation may be low (15%).

Henry


Henry, I completely agree that best practice is that the estimator sets the accuracy level. Unfortunately some executives seem to feel that they know better than someone with lots of experience in this field and set parameters themselves. Unless your estimator is a very strong character they may feel as if they have to give in to contingency limits etc set by someone else.

Nalini, thanks for your comment and I think your ranges are fine. Everyone will need to tailor for the risk involved, the maturity of the comany and their own personal situations but I would start with something like you have put forward.

very informative and very helpful.

Thanks for sharing this tips , This article is very helpful.

Thanks for this article. I agree with all 5 points, but there's a 6th point that's equally important, yet almost never applied... Base your estimate on your history. It's difficult to gather historical data and usually takes a long time, but if you have people entering their time, that's gold waiting to be mined. I've only had the opportunity to accumulate enough data at a detailed enough level once in 30 years, in a development shop of only 25 people. It took 4 years to amass a sufficient amount, making sure we knew which application was being worked on, what kind of task was being done (analyze, design, code, test, train, etc) and who did it. I built a spreadsheet from the data that could provide estimates that were accurate within 5%, even on projects of 5 work-years.

There's no substitute for reality. Your 5 tips light the way to collecting that reality.

Mark, yes, using history is a great technique. I have a video on that here: https://www.projectmanagement.com/blog-post/6231/What-is-analogous-estimating-

Please Login/Register to leave a comment.

ADVERTISEMENTS

"Nothing is particularly hard if you divide it into small jobs."

- Henry Ford

ADVERTISEMENT

Sponsors