How to calculate a ROM estimate and when to use it

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.

A ROM estimate is useful when you need to make a decision before you have enough information for a detailed estimate. It gives you an early indication of likely cost, time or resources, but it should not be treated as a firm project commitment.

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.

ROM estimate vs definitive estimate and when to use them

Later in the project, you can provide those detailed estimates, and this is really what execs want to see.

ROM and definitive estimates aren’t competing approaches, one isn’t ‘better’. They are a natural evolution of project management work and appropriate at different points in the project lifecycle.

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 – this is when you would use 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 PMBOK® Guide used to suggest it could be from -5% to +10%, but again, use your common sense for what works for you and what your Finance team or PMO advises in their internal guidance.

	ROM estimate	Definitive estimate
When?	Early project / initiation	Later planning
Purpose	Decide whether an idea is viable	Establish a realistic project budget
Information available	Limited	Detailed
Accuracy	Wide range	Much narrower range
Effort to produce	Relatively quick	More time-consuming
Typical approach	High-level / analogous / expert judgement	Detailed / bottom-up estimating
Confidence	Low	Higher

OK, back to ROM!

Want to know more about analysis and estimating? Check out my article on 4 Categories of Project Management Methods.

How do you present 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.

But don’t give your sponsor a number without explaining what it means. Share it like this:

£1.2m ROM estimate
Current estimate: £0.9m–£2.1m, based on the information available at initiation.

Include the assumptions behind the range, for example:

• Scope is still high level
• Supplier costs aren’t confirmed
• Resource requirements are based on similar projects
• Requirements may change
• Technical solution hasn’t been fully designed or approved by the architect.

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 pricing will give you a ballpark estimate based on best guesses and with plenty of hedging built in.

Not sure when to use a ROM estimate or whether it’s 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.
• Construction projects, where you have to provide a ROM budget figure to a client.
• 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. They might also have a ROM calculator if your business regularly prices client projects and has a standard way to do it.

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. In other words, we’re asking how accurate is a ROM estimate.

ROM is considered the broadest, least accurate way of representing the budget. (If you don’t count completely making the number up.)

There is no perfect ‘bucket’ for what boundaries you should put on your ROM and ROM accuracy ranges are not universal.

The Project Management Institute used to provide guidance in the PMBOK Guide Sixth Edition that said a ROM estimate is within the range of -25% to +75%. However, ROM cost estimates are no longer mentioned in the current version of the Guide.

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. The ROM estimate accuracy is not expected to be high, so don’t worry too much about it.

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%, like this.

• Initial ROM: £1.2m
• Range: £900k–£2.1m
• Confidence: Low
• Key assumptions: 12-month delivery, existing team, no major technology procurement
• Biggest uncertainties: scope, supplier costs and resource availability

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.

The estimate changes as you gather:

• better requirements
• supplier quotations
• resource information
• solution design
• delivery assumptions
• risk information

A ROM estimate is not “wrong” because it changes. The expectation is that your estimate will become more precise as uncertainty reduces, and leaders expect that.

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.

When should you stop using the ROM estimate?

As we’ve seen, the ROM cost shouldn’t become a permanent project budget. As you learn more about scope, requirements, resources, suppliers, delivery approach, risks and assumptions, you should revisit the estimate.

If your project has moved into detailed planning but you’re still reporting the original ROM as though it were a firm budget, you’ve got an estimating problem.

What is a ROM quote?

A ROM quote, or ROM price, would be provided to you by a supplier. Or you might be the supplier, providing it to the client.

Essentially, it’s a pretty vague statement of how much they think the work will cost at this time. It’s common in construction — when we had an extension built on our house, the project manager came round to view the property and then told us the ballpark figure of how much the work would cost. That was before they’d done a proper survey or anything, so it’s a good way to understand whether you want to go ahead with the work at all.

It’s also a faster way of gathering multiple quotes so you can see if suppliers are all broadly providing similar costs at this time, or whether one is particularly cheaper or more expensive than the others — why would that be?

The ROM calculation from the supplier’s side also helps them work out if they want the job. If it’s too small a piece of work, based on the high-level requirements provided, they might not want to contract with you.

FAQ