What is ROM and how to calculate it (with example)

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.

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.

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 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 the deliverable or new product is 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 projects 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 PMBOK® Guide says that a ROM estimate is within the range of -25% to +75%.

However, back in the real world, we don’t have to do exactly what the PMBOK® Guide says, although it’s useful to have those figures in the back of your mind for your PMI exam. 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.

The PMBOK® Guide suggests this 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.

Want to know more about analysis and estimating? Check out the post 4 Categories of Project Management Methods.

FAQ

Pin for later reading: