Everything You Need to Know About Rough Order of Magnitude (ROM) Estimates

A rough order of magnitude estimate, also known as ROM, is an estimation of a project ’s level of effort and cost to complete. ROM estimates take place early in a project life cycle and guide strategy and planning choices. In this article, you’ll learn more about ROM estimates and how they are used in project management . Plus, keep reading to discover examples and how UDN Task Manager could be used to assist in creating a template for your own rough order of magnitude.

What is the rough order of magnitude?

A rough order of magnitude estimate is a general estimate of a project's level of effort and cost. It's usually performed during the selection and approval stage of a project. Generally, it’s used for estimating a project budget that doesn’t have a lot of detail.

Project estimating is a vital aspect of project management because it helps determine the total budget for the project and whether or not it’s feasible companywide . It also helps keep track of the project's milestones and budget at the very beginning (more on that later).

A rough order of magnitude is most commonly used for project screening. ROM is typically meant to be given to executives who need a high-level overview of how much work might cost. This is especially helpful when they don’t yet have the mandate to do a deep dive into the scope and requirements of the work.

Comparing the ROMs of different projects helps identify which projects should be prioritized and which ones should be shelved. It can also help uncover and prevent scope creep later on.

This tool also helps decision-makers at other levels of the organization make informed choices regarding the project's complexity and costs. That information is critical for proper scope planning before project kickoff. It’s important to know that a ROM estimate is often used for information purposes at the beginning of a project and it’s suitable for use for the lifetime of the project.

Estimating a ROM is often thought of as an art. They are quick to make, but the trick is learning how to make them well.

Those who are more experienced in coming up with these estimates may have their own way of executing this process. Regardless of how well you understand the rough order of magnitude, it is important to consider the various factors involved in developing one. These include:

Keep in mind that, when calculating ROM, the goal is to provide a rough estimate that is largely accurate even if it’s not necessarily convenient for your plans. By this, we mean you may find it tempting to choose figures on the more conservative side in order to achieve a more desirable outcome.

Unfortunately, using inaccurate stats defeats the entire point of creating the estimation in the first place. Great research can help illuminate areas of your rough order of magnitude estimate where it may be tempting to let bias enter into the equation.

All that being said, a ROM estimate's variance is not significant enough to deter you from creating one. A ROM estimate provides a starting point for moving forward in much the same way a budget estimate is also used to determine your base. For example, instead of just presenting single-point estimates, managers should present budgets as a range.

Remember: the estimate is derived from the available information. If information is missing, you’ll have to make do with what you do know for sure and move forward from there.

In fact, you can expect to improve the estimate as the project moves forward. During the planning and implementation phases, the requirements and information will be refined. As you go along, you’ll learn through trial and error what the reality of the project actually is.

One technique for creating a rough order of magnitude estimate is known as a definitive estimate. A definitive estimate is a technique that involves estimating an individual project phase or task 's level of effort. Planning with this information upfront makes it easier to plot out workloads on visual charts while keeping your team on the same page.

This step typically takes a number of hours to complete, but it is a successful way to get an accurate idea of the time and cost of any project.

Other popular techniques and procedures for estimating costs include PERT time estimation, COCOMO, and function point analysis.

When estimating ROM, it is best to try and estimate in buckets of time and costs. Doing so helps minimize the number of, well, numbers that are required to provide a complete and accurate estimate.

Rough order of magnitude examples

There are two ways to think about estimating ROM. You can create effort ranges or buckets with approximate figures that any task can fit into. Alternatively, you can use historical data to guide decision-making. Here are some hypothetical rough order of magnitude examples:

In this example, a project manager will define effort ranges such as small, medium, and large. Within each range is a total number of hours, personnel, and/or budget needed for tasks that fall in that category. For example, a small bucket may indicate that a task will take two to four hours and is relatively simple or affordable to complete. It all depends on the specific project.

Here is a very simple example. Let's say you're considering eating a sandwich for lunch. You know that tasks such as spreading peanut butter and jelly onto two slices of bread would fall into the small category — low effort, low time, and perhaps even a single knife instead of two.

However, if you noticed that you're currently out of bread and you know it would take 20 minutes to drive to the store, that task would fall into the medium category because it would take considerably more resources to complete when compared to the spreading task.

Historical data means pulling information from past projects. These projects may have similar tasks, goals, or outlines. This information is good to have on hand in your project management solution.

You can use data from projects that didn't go as well as you'd hoped in order to refrain from repeating his mistakes. You can also use data from projects that went above expectations to see where you can replicate those choices here.

Let’s continue with our sandwich example. You may have found that in the past when you were craving peanut butter and jelly, it was worth it to you to make the drive. In fact, it also allowed you to run several other errands (a.k.a. projects) at the grocery store.

Based on this historical data, you may find that, despite the effort involved, the payoff was worth it in the end. So choosing this path again will be profitable.

First-hand experience refers to how experienced the person creating the rough order of magnitude is in this particular field, project type, or as a project manager in general. An expert who understands project management will likely come up with a more accurate ROM than someone on their first day of work.

First-hand experience is valuable because you have plenty of anecdotal evidence to back up your estimations from other related projects. It's also helpful because it allows planners to be intuitive about the process and consider the people involved. For example, you may find that a particular supplier often experiences delays. Although the supplier representative promises otherwise, you've seen it happen time and time again. Knowing this, you can factor that into your rough order of magnitude.

Now we’ve come full circle with our peanut butter and jelly project. You may have learned from first-hand experience that, despite your intense craving for it, these sandwiches aren't actually worth it for you.

You may even have regretted eating them right after you finished and wished you’d opted for a turkey sandwich instead. Knowing this, you may draft an estimate that confirms the amount of resources and effort needed will not have the ROI expected and it would be better to not move forward with it after all.

This information isn’t something you can necessarily track with a report. It’s simply a memory of what you’ve experienced in the past. Using this knowledge will help you make better, more informed decisions in your ROM with information you can’t find elsewhere.

How to use ROM in project management

Project estimation techniques help managers identify the most critical elements of a project and provide them with accurate estimates. These techniques can also be used to plan for resource allocation .

It is important that you have an estimate in place before you start a project. Without an estimate, you may not know how long it will take or what resources will be needed.

Cost is often one of the most challenging constraints in project management. Having enough money to complete the project is one of the most critical factors in managing it. Creating a ROM will help you understand whether or not it’s financially viable before you even begin.

Another key component of a project is time. Having the ability to determine the duration of the work and when specific tasks will take place is very important to project planning.

By estimating your project schedule , you can arrange for the people and resources that you need when they are needed. It also allows you to set expectations for the clients.

You can create a rough order of magnitude for any project. But there are several project management situations in which it may be necessary to come up with a ballpark idea of what resources will be needed:

Even if your project doesn’t fall into one of these categories, a ROM can be used to determine whether or not it’s viable. This is helpful when you’ve got limited resources and more than one project to choose between.

Using UDN Task Manager to create a rough order of magnitude template

UDN Task Manager is a project management tool that streamlines the process of organizing, creating, and coordinating a rough order of magnitude.

First, start by checking for any historical data from relevant projects you’ve successfully completed. All UDN Task Manager users have access to their own detailed project reports .

If you have historical data, you can go straight to a more detailed cost figure. It will give you a more accurate and detailed estimate. If you don’t, continue creating your ROM.

Then, start breaking the big components of the project down into smaller pieces.

Some planners use the top-down approach or the bottom-up approach, both of which can be accomplished with the help of UDN Task Manager .

A top-down estimating technique breaks down a project into discrete phases and tasks. This method works by estimating the overall time for the project, as well as the phases and work tasks that will be completed within that time frame.

If a client tells you that the project has to be done in six months, a top-up approach allows you to estimate how much time you can dedicate to each activity within the project.

A bottom-up estimate is a technique that works by estimating multiple tasks and aspects of a project. This step-by-step process combines the various estimates into one final project estimate.

In project management, orders of magnitude are typically referred to as broad-brush categorizations of sizes. So use a range when adding in timelines for individual phases and expenses.

Tip: don’t forget about project costs spent preparing the ROM and the project management itself. This will take up about 20% of your estimated total time allotted to the project.

Next, go above and beyond by using UDN Task Manager to calculate risk . Project risk is a set of events that could significantly affect the quality or schedule of a project. It can be triggered by various factors such as unforeseen delays, budget cuts, and legal issues.

By estimating the risks involved in a project, you can plan for how those risks will affect the project and develop a risk management strategy later on if you feel that the ROM is convincing enough to adopt the project.

Tip: If you’re stuck, talk to your finance department to see if they can help you get a better idea of what things cost.

Finally, consider what project planning may look like. Project planning for Agile projects is usually done in phases, with estimates being created initially before the beginning of the sprint. These estimates are then updated during the sprint.

Estimation can also happen during a sprint retrospective , where you update the backlog based on the outcomes of the previous sprints. It can also be done during the sprint planning session.

The project team is responsible for estimating projects and managing the estimates. They are also involved in the development of the project's documents and databases.

Having one central hub for all project estimates makes it easier to organize and communicate your vision and ROM results.

As you progress through the project, you should start to produce smaller ranges for accuracy. Over time you will reach a cap for each category that is both realistic and attainable. As the project details become more detailed, the accuracy of the ROM estimates decreases until they are no longer accurate.

In conclusion

The more data you have about your project, the better it is to draft current project estimates. A project estimation tool can help you build up estimates and track against actuals. It can also help you improve your estimates by recording errors and lessons learned. Discover how UDN Task Manager can help you improve your planning and execution with our free trial.