What is a ROM estimate?
A rough order of magnitude estimate is used to give you a very high level view of potential project costs.
Ideally, you’d be able to provide a definitive estimate, carefully created from loads of input from subject matter experts and plenty of research on past projects and their budgets.
But in reality, we rarely have the time or luxury of being able to provide that level of estimate at the earliest stage of project.
What is ROM used for?
Think of the ROM estimate as used for informational purposes at the beginning of the project. It’s not really something you should use for too long – it’s important to get to a more accurate view of project costs as soon as you can.
Often, execs simply want an overview of how much the work might cost. And we haven’t yet received the mandate to do a deep dive into requirements and scope that would enable more accurate results from the budget forecasting.
The PMI Practice Standard for Project Estimating mentions ROM as an option for adaptive project life cycles. It says:
During initial planning, the project team determines the number of initial iterations and their durations by approximating the effort needed.
The ROM variances are replaced reasonably quickly with more detailed estimates, after the initial planning gives you more information.
How do you represent a ROM estimate?
I always encourage managers to present budgets as a range, because single-point estimates often trap you into a certain mindset where there is no scope for change, whatever the reason.
ROM estimates are no different, except the range is big. The budget figures are represented in line with the level of accuracy you have at the time. So they are shared as a + / – % figure.
The range is a way of representing the degree of confidence or accuracy level in the number.
When do you use a ROM estimate?
Use the rough order of magnitude as an estimation technique for when you don’t have a lot of clarity about the project budget.
It’s used in the early stages of work, to establish the estimate cost with the information you have. It builds in a lot of variance, so if you can’t create an accurate estimate because you don’t have all the detail (which is… always before you’ve done the planning), the ROM figure will give you a ballpark estimate based on best guesses and with plenty of hedging built in.
Not sure if ROM is right for your project? You can learn everything you need about estimating in our Project Estimating Guide.
Why would you use an estimate that’s so vague?
Because some information is better than none! Whether you use T-shirt sizing (XS, S, M, L, XL, XXL) or a rough guess, the human brain is used to dealing with vague values.
A rough estimate provides a relative view of how large a project is (or how small) in relation to others in the portfolio. A cost of £1m might be small for some firms, but substantive for others, so an early overview of what costs could help people make a decision about next steps.
It can also inform your work breakdown structure. You can identify which chunks of work will fall into which cost ranges.
What types of projects can use a ROM estimate?
Any type of project can use a ROM estimate. They are useful for:
- Larger projects, where you need to provide management information and an initial estimate before you have all the detail for a more definitive estimate.
- International projects, where you may have to include costs from various countries and take currency conversion into account.
- Innovative projects, where cost drivers for the deliverable or new product are unique and pioneering, and the exact project scope is being progressively elaborated or managed through
agile techniques. - Projects with larger value budgets, as generally you can estimate small figures more easily than you can large amounts.
- Projects where you’ve got historical information; NASA’s cost estimating handbook version 4.0 talks about analogy cost estimating being an application for a ROM estimate.
They are less helpful for project managers where you’re doing the same implementation time after time and have a pretty good idea of exactly how much each part of the work costs.
For example, simple software implementations or an installation for clients where it’s basically the same effort and resources required every time.
If you’ve got the historical data, you may as well go straight to a detailed, more accurate project cost figure (especially if you are presenting those numbers to a client).
How do you come up with a ROM estimate?
Erm… to come up with a ballpark figure, basically, you guess.
This estimating technique is top-down, meaning you don’t need to know the exact details of what’s going to be done on the project. Just take the parts you do know and apply some professional judgment.
Break the project work into chunks. Apply some sensible categorization to each chunk. Is it a high, medium or low effort piece of work?
Your PMO might have definitions for each of those to help you define and refine your estimates at the early stages of the project. For example:
High effort:
- More than 6 weeks of work
- More than 10 people required to do the task
- More than £x required
Medium effort:
- Between 2 weeks and 6 weeks of work
- Between 3 and 10 people required to do the task
- Between £x and £y required
Low effort:
- Less than 2 weeks of work
- Only 1 or 2 people required to do the task
- Less than £x required.
If your PMO does not have standard categories like this, you can make them up. This gives you some assumptions to work to and a way of explaining how you came up with the estimate.
Estimate each chunk based on your effort estimation and then add the chunks up and apply the ROM variance range to the final figure.
Tip: Don’t forget to include your time! Apply a percentage of the overall time estimate as representative of the project management effort involved. I tend to use 20% for this, so if a project task is going to take a week, I’ll assume I need a day of PM effort for my part in keeping everything going.
What’s a typical Rough Order of Magnitude for project estimating?
‘Orders of magnitude’ has a specific meaning in scientific notation and mathematics, but in project management, it typically refers to broad-brush categorization for sizes. A ROM is often considered the broadest, least accurate way of representing the budget.
There is no perfect ‘bucket’ for what boundaries you should put on your ROM. The Project Management Institute used to provide guidance in the
Talk to your Finance department to see if there are internal cost management and forecasting standards to apply to, or just get the range as accurate as you can based on your professional judgment.
Let’s look at an example to see how it would work in a project budget.
ROM example
Let’s say that we’re in the Project Initiation phase. We don’t know the total cost of the project – at least, not an accurate cost. The business case has been approved already with a budget that’s very high level, and now the exec sponsor is asking for more information about what the work might realistically cost.
We just need a first estimate.
We review the different estimation techniques available to us and decide that we don’t have enough information about the work packages and tasks to give anything more than a budget estimate in a range that puts it in a very rough ballpark.
We take a quick look at previous projects — lessons learned are a good starting point. We consult subject matter experts (who are unwilling to commit themselves to a ‘real’ number because they haven’t seen the detailed requirements yet) and talk to them about what their effort cost last time. After much cajoling and negotiation, we get an idea of how much this project is going to cost.
However, it’s based on so many ‘what ifs?’ and assumptions that we can’t possibly have confidence putting that number in front of the steering group.
So, we present it as what it is: our best estimate based on all the knowledge, information, and professional judgment available to us. We share it as a range so everyone can see straight away that it’s not a single figure.
The accuracy of the ROM estimate is represented in the range. We share the budget, based on our research and understanding of what the project will deliver, as £1.2m with an accuracy range of -25% to +75%.
This means that our total project budget, based on today’s estimates, could be as low as £0.9m or as high as £2.1m (gasp!). That’s quite a variance.
With that information, the steering group can start to prepare themselves mentally for the outcome of the detailed project planning and what that might mean for a more accurate version of the project budget.
When to revise the ROM estimate
The rough cost estimate is not designed to last for the whole project life cycle. In fact, you should be refining and improving your budget estimates all the time, especially through the planning stage.
Make sure your keep your RAID log updated with any changes to your budgeting assumptions.
Project cost management is something you do throughout the whole project, and your budget is under constant review.
ROM estimate vs Definitive estimate
A definitive estimate is what you should end up with once your budgeting analysis is fully complete. It’s a very realistic view of what the overall project expense will be – and you create it by refining your higher-level figures and moving from general information to detailed information.
As you move through the project, you should be able to produce more accurate estimates with smaller ranges relating to accuracy. As the level of detail increases, the range that represents the accuracy of the ROM estimate decreases until it’s not really a ROM any longer – it’s a definitive estimate.
I’d still recommend that you present definitive estimates as a range because there could still be extra cost – or you could come in under budget. This could also be included as project contingency.
PMI no longer provides specific guidance on what a definitive estimate range should be in their latest guidance. The
Want to know more about analysis and estimating? Check out the post 4 Categories of Project Management Methods.
Essential read
We earn a commission if you click this link and make a purchase, at no additional cost to you #ad
FAQ
How does PMI define ROM estimates?
The latest guidance no longer includes a definition. The old Sixth Edition PMBOK® Guide said that a ROM estimate is within the range of -25% to +75%. Today, PMI recognizes that teams have to create their own guidance based on what is relevant for their organization.
How do you define ROM?
The NASA Cost Estimating Handbook v4.0 defines ROM as: An estimate based on an approximation without benefit of details or detailed analysis.
What’s the purpose of a ROM estimate in project management?
A rough order of magnitude estimate represents the level of effort required to deliver a project, based on the best available information on timescales and cost. It provides decision-makers with the information they need to see if it is worth continuing with the project.
