Rough order of magnitude rom что это
What Is the Rough Order of Magnitude (ROM) and How Is It Calculated?
During the project initiation phase (or when you are preparing for a project management exam) you will likely come across the term rough order of magnitude (ROM). The PMI’s Project Management Body of Knowledge refers to the rough order of magnitude as an initial estimate in the “estimate cost” process (source: PMBOK®, 6 th edition, part 1, ch. 7.2). As the book does not elaborate on the details of the ROM, you might be wondering how it is defined and determined – especially as it is relevant for the PMP exam. The short answer is:
Read on to learn more details and background. If you wish to calculate the ROM range for an initial estimate, use this free ROM calculator.
What Is the Rough Order of Magnitude (ROM)?
The rough order of magnitude (ROM) is a type of cost estimate that is used in various kinds of projects. These include but are not limited to strategy development and implementation projects, IT projects as well as construction projects. It is typically used in the preparation and initiation phases of projects for the development of a project business case, for instance, or for the determination of the required financial resources that are stated in the project charter.
The accuracy of ROM estimates is -25% to +75% according to the PMBOK (source: PMBOK®, 6 th edition, part 1, ch. 7.2). Other authors set the range at +/-50% which can be used as an alternative in practice if the estimate is deemed conservative.
Illustration of the use of ROM and definitive estimate in different project phases for cost estimating purposes.
To narrow this wide range of possible outcomes down, this rough cost estimate is expected to be refined in the course of the project as more information and better estimates can be obtained over time (similar to the concept of progressive elaboration).
It shall then be replaced with a so-called definitive estimate that is much more accurate (see below section on the differences between both estimates).
How Is the ROM Determined?
The calculation of the rough order of magnitude range is relatively straight forward. The formulas for the calculation of the upper and lower boundaries are as follows:
Upper Boundary = ROM_Estimate x (1 + 75%) = ROM_Estimate x 1.75;
Lower Boundary = ROM_Estimate x (1 – 25%) = ROM_Estimate x 0.75.
In practice, the more challenging part is usually to come up with the ROM estimate (i.e. the basis for the ROM range) rather than calculating the boundaries of that range. It can be determined using established estimation techniques such as analogous or parametric estimates.
As the ROM is typically used for projects in the initiation phase with a high level of ambiguity and uncertainty with respect to the expected cost, the required input data for these techniques may not be available though. The same holds true for the option to involve subject matter experts: they might not be assigned or available for bottom-up estimating at the time of a project’s initiation.
The initial estimate is therefore often based on high-level expert judgment, sometimes in conjunction with three-point estimating.
What Is the Difference between Definitive Estimate and Rough Order of Magnitude?
There are three key differences between the ROM and the definitive estimate:
Comparison of the accuracy ranges of rough order of magnitude (ROM) and definitive estimate.
This is because the rough order of magnitude is typically determined in the initiation phase of projects (or parts of projects) when information that is required for proper estimating tends to be vague. Resources, as well as data, may also be limited. The definitive estimate, on the other hand, is calculated in subsequent project phases when these constraints are broadly resolved.
Thus, the definitive estimate can be computed using more accurate estimation techniques, such as bottom-up estimation or parametric estimates. Both may not be available at the time the ROM estimate is determined.
Conclusion
The rough order of magnitude estimate is a rather inaccurate type of project cost estimate. However, it is typically used in the initiation phase of a project when the available information and resources do not suffice to produce better estimates.
In this situation, the ROM provides at least a rough idea of the cost range of projects which is often useful for the purpose of stakeholder communication in an early stage. The ROM estimate can also be used to develop a project business case or a project charter, for instance.
If you wish to learn more about cost and time estimating, read our guide to estimating costs take a look at our other articles on this topic.
The Rough Order of Magnitude Estimate
Project estimating is one of the most important aspects of project management. By their very nature, projects have fixed budgets and their owners want to know how much they will cost. Hence, project estimating begins prior to project initiation and estimates are usually updated at important project milestones.
A Rough Order of Magnitude estimate, often called ROM Estimate, is the first estimate in the life cycle of a project.
Usually it is used for project screening, that is, to decide which among several projects to proceed with. It is also often used to estimate projects prior to funding being approved.
Accuracy
How to Develop an ROM Estimate
ROM estimates are developed primarily using analogous techniques, meaning that cost information from previous projects is used to determine an estimate for the new project. Applicable adjustment factors are applied, for example if the new plant will have five assembly lines and the old plant only had four, the cost would be increased by 25%.
So how do you know that the estimate has an accuracy level of exactly 50% and not 40%, 30%, or whatever? This is a question many beginners have, and the answer is that this is a maximum range of this type of estimate, not a universally achievable objective. If the estimate cannot be produced to this accuracy, it cannot be called an ROM estimate. But if it can, well, you’re in luck.
Bottom line, you gather statistical evidence of how often each task fails to perform satisfactorily if it was performed many times. Often this data is sparse, but with experience you can estimate it quite well. When you can establish that each task has at least 50% accuracy, you can safely call the estimate an ROM estimate.
A 50% accuracy level is fairly easy to obtain, and almost all projects will have to ability to estimate at this level. The exception might be research and development projects, or software projects that continually change and evolve.
Project Definition Level
The definition level of a project for an ROM estimate is about 0 – 5%. That means that the design of the relevant products and services are at an infant stage, or have not started at all.
For example, the design of the building has not yet started when the ROM estimate is produced.
Example
Other Types of Estimates
ROM estimates are the first (lowest) level in a hierarchy of estimates that are produced as a project proceeds through its life cycle. The others are:
Rough Order of Magnitude (ROM) Estimate and How to Calculate It (with example)
What is a ROM estimate used for?
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.
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.
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.
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:
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:
Medium effort:
Low effort:
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.
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.
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.
Want to know more about analysis and estimating? Check out the post 4 Categories of Project Management Methods.
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 Wrike 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:
Creating buckets
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
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
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 Wrike to create a rough order of magnitude template
Wrike 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 Wrike 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 Wrike.
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 Wrike 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 Wrike can help you improve your planning and execution with our free trial.