ROM stands for rough order of magnitude. It is a first, rough range for what a project will cost or how much effort it needs, given before the details are known so a client can decide whether to go further. It is a planning range, not a quote. Whether any document creates an obligation or counts as an approved budget depends on its terms and the approval process, not on the label “ROM”. Always say whether the range is your cost or the client’s price.
In plain words
ROM stands for rough order of magnitude. A ROM estimate is a first, rough answer to “about how much will this cost, or how long will it take?”, given before anyone knows the details. It is a range, not a single price. It is not a quote, and unless the document says otherwise, nobody has agreed to deliver for that amount. Construction and engineering teams use the same words for early cost ranges, so searches for “ROM in construction” lead to the same idea; the examples here come from consulting and IT services.
Who this helps: Presales consultants, sales and account managers, new project managers and finance partners: anyone who is asked “roughly how much?” before a project is defined.
Questions this guide answers:
- What does ROM stand for in project management, business and sales?
- What is a ROM cost estimate and how is it different from a quote?
- How is a ROM used for a budget or for pricing?
- Does ROM mean the same thing in construction?
- Is a ROM estimate a contract?
What does ROM stand for, and what is a ROM estimate?
In a presales team, a ROM estimate is the answer to “roughly how big is this?” when nobody has yet written down the scope. A client asks for a number to take to a budget meeting. You do not know the systems, the data or the people involved, but saying nothing loses the deal and guessing one number can hurt you later. So you give a range, you say what it is based on, and you say when it will be replaced.
Three things are always true of a ROM. It is a range, because the unknowns are real. It is labelled: you say whether it is your internal cost or the price the client would pay, because the two differ by your margin. And it is temporary: it has a review point, usually after discovery or when the scope is written down.
A ROM is not a quote and not a contract. Nobody has agreed to deliver for that amount, and calling a number a ROM does not by itself decide whether it binds anyone: that depends on the wording and the agreement. The safe habit is to write “planning range, not a quote” next to it.
Try the free ROM estimate calculator
Enter a low and a high effort case, your cost rate and your target margin, and the ROM estimate calculator shows the cost range, the price range and wording you can paste into an email. Your figures stay in your browser.
What does ROM mean in construction, business and sales?
The same three words are used in several fields, and they all mean “early, rough, wide”.
| Where you hear it | What it means there |
|---|---|
| IT projects and project management | An early cost or effort range given before requirements are written, to decide whether to scope the work properly. This is the meaning used in this guide. |
| Construction and engineering | An early cost range for a project that is barely designed. Estimating standards in these fields classify estimates by how much of the project is defined, and the least-defined class has the widest range. |
| Sales and presales | A rough price range the seller gives before scoping, often by email after a first call. It signals scale, not commitment. |
| Government requests for information (RFIs) | A rough price or cost that an agency asks for as planning information. It is not an offer; follow the agency’s instructions for what the response may and may not include. |
| Contracts | There is no standard “ROM contract”. A ROM can sit inside a proposal, but it commits no one unless the agreement says it does. |
If you arrived searching for “ROM in construction”, the idea is the same; the worked examples here come from IT and consulting work.
Terms used in this guide
- Planning rate: the hourly cost the firm’s finance team approves for estimating. It is a cost, not what the client is charged.
- Discovery: a short, usually paid, piece of work that answers the biggest unknowns before a firm price.
- Target margin: the share of the price the firm wants to keep after all its costs (the fully loaded, or managed, margin).
- Deal desk: the small group that approves discounts and prices that fall below policy.
- Baseline: the approved plan that delivery is measured against.
- Σ (sigma): “add up”: here, the sum of hours times rate over every role.
Where does a ROM fit in the project lifecycle, and who checks what at each stage?
A ROM is one step in a chain that runs from the first conversation to a delivered project. Each stage has an owner and a checkpoint: a question you answer before the work moves on. This is how a presales lead would walk a new teammate through it.
| Stage | Who owns it | What happens to the ROM | Checkpoint before you move on |
|---|---|---|---|
| 1. Qualify the opportunity | Sales or account manager, with the presales lead | Find out what decision the number is for: a budget meeting, a funding request, a vendor shortlist. | Can you name the decision, the date and who will use the number? |
| 2. Build the ROM | Presales consultant, with a delivery lead | Pick comparable past projects, list what is different, work out a low and a high case and cost them with approved planning rates. | Are the assumptions written down, and has delivery said the hours are plausible? |
| 3. Review and send | Presales lead and sales manager; finance for fee rules | Turn the cost range into a price range at the target margin. Keep the cost range and the margin inside the firm. Write the cover note. | Does the message say range, basis, “not a quote” and when it will be replaced? |
| 4. Narrow it | Presales consultant and the client sponsor | Answer the unknowns that explain the gap between low and high, often through a short discovery. | Can you show the evidence for every unknown you narrowed? |
| 5. Commit | Presales lead, delivery lead, finance (and a deal desk if there is a discount) | Replace the ROM with a detailed estimate and a quote or fixed price. See ROM vs definitive estimate and from ROM to fixed price. | Are scope, acceptance criteria and the role plan agreed, and does the margin meet policy? |
| 6. Hand over | Project manager receiving the deal | Keep the ROM, the detailed estimate and what changed between them with the project baseline. | Did the assumptions travel with the deal? |
Two stages are where new teammates most often slip: stage 3, where a cost range is sent to the client as if it were a price, and stage 5, where a ROM is quietly promoted to a fixed price without new evidence.
How do you build a ROM estimate step by step?
- State the decision. What will the client do with this number? Budget approval, a go/no-go, a comparison of suppliers? That tells you how rough it can be.
- Write down what you know and do not know. Systems involved, data, deadline, who decides. The unknowns become the difference between your low and high case.
- Find evidence. One or two comparable past projects with their real hours are better than a feeling. If you have none, break the work into familiar pieces and size each.
- Adjust for differences, openly. If the new project has two more integrations, add their hours. Do not copy the old total.
- Work a low and a high case. Say what changes between them and what would prove each one wrong.
- Cost the hours with the firm’s approved planning rates, and add other costs you will pay, such as licenses.
- Turn cost into price using the formula below, keep cost internal, and label what you send.
- Record who made it, the date, the assumptions and the review point.
Five complete worked examples, with hours, cost and price for ERP integration, a website, data discovery, a support transition and a change request, are in ROM estimate examples.
ROM estimate formula: how do you turn effort into cost and price?
Cost = Σ (role hours × approved hourly cost) + other costs you will pay
Price = cost ÷ (1 − target margin − any charge that is a share of the price, such as commission)
Why divide, and not just add 30%? Margin is a share of the price, not of the cost. Adding 30% to cost gives a margin of about 23%. Dividing by 0.70 gives exactly 30%. This is the single most common beginner mistake, and the target-margin guide explains it in full: how to price a project to a target margin.
Real example: a presales consultant gives a ROM before a client’s budget meeting
An illustrative story with invented figures, to show how the idea works in a real office.
On Monday morning Dan, a sales manager, forwards a message from a client’s operations director: “Roughly what would it cost to automate our invoice matching? We set budgets on Thursday.” Priya, the presales consultant, has a one-page brief and no system list. She does not guess a single number.
Checkpoint 1. She asks Dan what the number is for. The answer: a budget line, not a commitment. That tells her a wide range is acceptable.
Checkpoint 2. She finds two similar past projects that took 400 and 650 hours, and checks with a delivery lead that the new job has no unusual systems. The gap between 400 and 650 hours comes down to one unknown: how many systems the invoices come from. Her planning cost rate for the team is USD 60 an hour, so her cost range is 400 × 60 = USD 24,000 to 650 × 60 = USD 39,000.
Checkpoint 3. Her firm aims for a 30% margin, so she divides by 0.70: about USD 34,300 to USD 55,700. She tells Dan to send only the price range, rounded to USD 34,000–56,000, and to keep the cost range and the margin internal.
Dan’s email says three things: it is for budgeting only, it rests on two similar projects, and a two-day discovery will confirm it. After discovery finds three source systems, the estimate narrows to a range of USD 38,000 to USD 44,000. Nobody felt misled, because the first number was always a range with a reason.
How accurate is a ROM estimate? Is it always −25% to +75%?
You will meet the figure −25% to +75% in training courses. Older editions of the PMBOK Guide described a ROM that way, a budget estimate as about −10% to +25% and a definitive estimate as about −5% to +10%. It is a rule of thumb for calibrating expectations, not a standard you must apply, and it was not written for IT work.
The construction and process-industry estimating practice published by AACE International (recommended practice 18R-97) shows how much wider the earliest class of estimate can be: low-side ranges of −20% to −50% and high-side ranges of +30% to +100% for its least-defined class. That tells you the range depends on how much of the project is defined, and that the honest range for a vague IT project can be wide. It does not give you a multiplier to copy.
What to do instead: do not choose a percentage to look confident. Build a low and a high case from this project’s own unknowns, and explain each one. Read the cone of uncertainty for why the range narrows as you learn.
When should you use a ROM estimate, and when should you not?
Use one when a rough scale answers the question being asked: qualifying an opportunity, a first budget conversation, a business case, a request for information. Agree first whether the reader needs your cost, the client’s price, or the client’s total investment including their own costs.
Do not use one when the client wants to sign. A fixed price needs agreed scope, acceptance criteria, a role plan and an approved margin; a ROM has none of these. If the unknowns are so large that even a wide range would not help the decision, propose a short paid discovery instead: see paid discovery pricing.
What are the most common ROM estimate mistakes, and how do you fix them?
| Mistake | What it looks like | How to fix it |
|---|---|---|
| Giving one number | “About fifty thousand” on a call; the client remembers fifty | Always give the range, what drives it and when it will be replaced. See presenting a ROM without anchoring. |
| Mixing cost and price | The internal cost range goes to the client as if it were the fee | Label every figure as cost or price, and send only the price range. |
| Copying an old project | The reference total is reused unchanged | List the differences, add or remove their hours and reprice at current rates. |
| Forgetting the unglamorous work | Testing, release, project management and client reviews are missing | Add them explicitly. See why estimates run low. |
| No review point | The ROM lingers for months | Write when it will be replaced and who will replace it. |
| Treating a percentage band as a rule | “We add −25% and +75%” to every number | Base the range on this project’s unknowns and say so. |
ROM vs analogous, parametric or bottom-up: which estimating method should you use?
A ROM is a purpose (an early rough range), not a method. Several methods can produce one. Use an analogy when a close past project is your best evidence. Use a parametric model when you have a countable driver, such as screens or interfaces, that has predicted effort on past work. Use a bottom-up estimate once the work can be broken into tasks. Choose paid discovery when one unanswered question prevents any useful decision and investigation can answer it. The guide to project estimation methods compares them.
How do you work up a ROM in Managed Margin?
In Managed Margin you enter the role hours for each stage or week, use the approved planning rates and add the project cost rules. For different effort assumptions you create separate strategies, for example a low-effort and a high-effort one, and compare them. The optional ROM price range varies the price of one strategy and leaves its effort unchanged, so it does not simulate extra delivery hours and it does not do discovery. You supply the effort assumptions; the software does the arithmetic. See the project pricing workflow.
- How to Present a ROM Estimate to a Client Without Anchoring
- ROM vs Quote vs Definitive Estimate: What Differs?
- Software Project ROM Estimate From a Short Brief
- ROM Quote and Estimate Email Examples: 6 Templates
- Cone of Uncertainty in Project Estimation, Explained
ROM estimate: frequently asked questions
What does ROM stand for in project management?
Rough order of magnitude: an early estimate given as a range before the scope is defined, to decide whether to investigate further.
What does ROM mean in business and sales?
A rough price range a seller gives before scoping, usually in writing after a first call. It signals scale and is not a quote or a commitment.
Is a ROM a cost estimate or a client price?
It can be either, so label it. Cost is what delivery will spend; the price must also cover the margin and any charges that are a share of the price, such as commission.
Is a ROM binding, and is there such a thing as a ROM contract?
A ROM is not a contract term. It binds no one unless the agreement says it does, so state that it is a planning range and not a quote.
Must a ROM use a standard percentage range?
No. A range needs evidence and a stated basis. Percentage bands from training material or from construction practice are not multipliers for IT work.
How do I turn a ROM into a number I can commit to?
Resolve the unknowns, agree scope and acceptance criteria, build a task-level estimate and get it reviewed and approved. See from ROM to fixed price.
Are a ROM quotation, a budgetary ROM and ROM costing the same thing?
Not exactly. “ROM quotation” and “ROM quote” usually mean a rough range that is not a quote; “budgetary ROM” usually means a ROM given to help a client plan a budget; “ROM costing” is the work of building the cost side of a ROM. Ask which meaning the other person has, because a label alone does not settle what has been agreed.
How do you construct a ROM estimate for a project?
Five steps. (1) Write the scope in a few sentences and list the biggest unknowns. (2) Choose a basis: a similar past project, a count multiplied by a known effort per unit, or hours by role. (3) Estimate a low and a high number of hours for each role. (4) Multiply by your cost rates and add other costs to get a cost range. (5) Divide by one minus your target margin (and minus any fee-linked charges) to get a price range, then state the assumptions and the fact that it is a range. Worked examples are in ROM estimate examples and a software project ROM, and you can try it in the ROM estimate calculator.
Does ROM mean the same thing in construction?
The idea is the same: an early, rough cost range before the design is detailed. Construction teams usually build it from quantities and unit costs, while the examples on this site are for consulting and IT services and are built from hours, roles and rates. The method here is not a construction cost-estimating standard.
Continue the sequence: guides to read next
- ROM Cost Estimate Examples for IT Projects: five worked ROM examples
- Project Estimation: Process, Methods and What to Consider: five estimation methods and how to choose between them
Sources and methodology
The figures and stories are Managed Margin’s own teaching illustrations, not customer results or market benchmarks. The accuracy bands are cited as conventions: the PMBOK Guide figures come from the Project Management Institute’s earlier editions, discussed in PM101: Estimating; the construction ranges come from AACE International recommended practice 18R-97, which is published by AACE and is not linked here because its freely available copy is only a table-of-contents sample. The US GAO Cost Estimating and Assessment Guide supports the practice of documenting assumptions and updating an estimate as the program is defined. Product steps reflect the application as built on 13 October 2026.