A rough order of magnitude (ROM) estimate is an early, wide-range cost figure used to decide whether a project is worth pursuing — not to quote a fee. Built top-down from a comparable past project before any work breakdown exists, its accuracy band is wide (commonly -25% to +75%), so present it as a range with its basis stated, never as a single number.
What a ROM estimate actually is
A ROM estimate is the roughest class of cost estimate in standard project-estimating practice. It is produced when almost nothing about the project is defined yet: no work breakdown structure, no confirmed roles, often not even a signed statement of work. What exists is a one- or two-line description of scope and, ideally, at least one comparable past engagement to reason from.
Because so little detail is available, a ROM is built top-down (analogous estimating), not bottom-up. An estimator takes the actual cost of a similar past project, adjusts it for known differences in scale or complexity, and applies a wide accuracy band around that point estimate. The result is a range, not a figure — and the range is the useful part, not an inconvenience to be rounded away.
Why a ROM estimate exists
The decision a ROM supports is narrow and specific: is this initiative worth the cost of scoping it properly? For a presales team at an IT-services or consulting firm, that shows up as the first exploratory call, where a prospect asks "just to get a sense of scale, what would this cost?" before any discovery has happened. Answering that question with a defensible range — rather than either refusing to answer or guessing a single number — protects two things at once: the client's time, by telling them early whether the initiative fits their budget at all, and your own delivery team's time, by avoiding a fully scoped proposal for a deal that was never going to be funded.
A ROM is also the standard input to feasibility studies, business cases, and portfolio-level prioritization, where several candidate initiatives are compared on order-of-magnitude cost before any of them gets a real proposal. None of these uses require precision. They require an honest, labeled range.
Accuracy bands: PMI's convention and AACE's alternative
Two widely referenced classification systems attach numeric accuracy bands to estimate types. PMI's Practice Standard for Project Estimating and the PMBOK Guide's traditional convention associates three estimate classes with progressively tighter bands as a project moves from initiation toward execution. AACE International's cost estimate classification system (18R-97), developed for engineering and construction but referenced well beyond it, uses a five-class system where Class 5 is the roughest.
| Estimate class | Typical accuracy band | Convention |
|---|---|---|
| Rough order of magnitude | -25% to +75% | PMI (traditional convention) |
| Budget estimate | -10% to +25% | PMI (traditional convention) |
| Definitive estimate | -5% to +10% | PMI (traditional convention) |
| Class 5 estimate | -50% to +100% (as wide as -20%/+30% at the mature end of Class 5) | AACE International 18R-97 |
The -25%/+75% figure is widely cited and useful for calibrating expectations, but it is not a still-mandatory rule you can cite as binding. More recent PMBOK Guide editions moved away from prescribing one fixed universal band and instead leave the exact accuracy range to the performing organization's own documented estimating practice. Treat the numbers above as a well-established convention worth stating out loud to a client, not as a formula PMI requires you to follow.
When a ROM applies — and when it's the wrong tool
A ROM is the right tool for a feasibility study, an early business case, a portfolio-prioritization exercise, or the first exploratory conversation with a prospect who has not yet described real scope. It is the wrong tool the moment the number is going to appear in a contract, a statement of work, or a budget line that finance will later hold a delivery team accountable to as if it were approved scope. That number needs a completed work breakdown structure and a bottom-up build — see ROM vs definitive estimate for the methodology difference and the failure mode that happens when the two get confused.
Building a ROM estimate, step by step
- Identify one or more genuinely comparable past projects — same type of work, roughly similar scale and client context.
- Take that project's actual delivered cost, not its original quoted price, as your point estimate.
- Adjust the point estimate for known differences in scale (for example, if the new scope is clearly double the data volume or user count).
- Apply an accuracy band appropriate to how little is actually known — the less comparable your data, the wider the band should be.
- State the basis of estimate alongside the number: which comparator you used, what is included and excluded, and which convention set the band.
- Present the full range, not the point estimate and never the midpoint alone.
How this plays out on a real project
Consider an illustrative case: a 40-person IT-services consultancy fields an inbound request to modernize a client's legacy claims-processing system. Nobody has scoped anything yet.
- The first call: the prospect asks, "just to see if it's worth talking further, what would this cost?" The rep is tempted to name one number to sound confident. Handling: give the ROM as a range grounded in a comparable past modernization project, and say plainly that it is wide because no scope exists yet.
- Internal handoff: the sales rep relays the ROM to the delivery lead as "the number," dropping the range along the way. Handling: the basis of estimate — comparator, assumptions, and band — should travel with the figure in writing every time it changes hands, not survive only as a verbal caveat in the room where it was first given; see giving a ROM without anchoring for why this matters more than it sounds.
- Portfolio prioritization: the client's PMO stacks this ROM against ranges from two other vendors for competing initiatives, without realizing the vendors used different accuracy conventions — one effectively PMI's -25%/+75%, another closer to AACE's wider Class 5 band. Handling: always name which convention produced your range so a client comparing multiple ROMs isn't comparing apples to oranges.
- The follow-up meeting: the client calls the range "too vague" and pushes for a tighter figure before any discovery has happened. Handling: explain that tightening the range requires defining scope, not artificially narrowing the same guess — that progression is exactly what a definitive estimate is for, not a reason to fake precision now.
The formula, and two worked instances
ROM low = Point estimate × (1 − accuracy low%)
ROM high = Point estimate × (1 + accuracy high%)
Instance 1 — PMI convention. The comparable past project actually cost $80,000. Applying the traditional -25%/+75% band: low = 80,000 × 0.75 = $60,000; high = 80,000 × 1.75 = $140,000. Range: $60,000 to $140,000.
Instance 2 — AACE Class 5 convention, same point estimate. Low = 80,000 × 0.50 = $40,000; high = 80,000 × 2.00 = $160,000. Range: $40,000 to $160,000.
The point estimate did not change — only the classification convention did — yet the presented range moved by tens of thousands of dollars on each side. This is exactly why step five above matters: a client comparing two vendors' "ROM ranges" without knowing which convention produced each one will draw the wrong conclusion about which vendor is more confident, when the real difference is just which band they applied.
From a ROM to a number you can commit to
A ROM's job ends once it has answered the feasibility question. Turning it into a number a client can sign against requires a different method entirely — see ROM vs definitive estimate for the top-down-to-bottom-up progression, and resource-based project cost estimation for how the definitive number actually gets built from roles, rates, and hours.
Sources and methodology
- Project Management Institute, PM101: Estimating. Used for the rough order of magnitude, budget, and definitive estimate types and their traditional accuracy conventions.
- AACE International, 18R-97: Cost Estimate Classification System. Used for the Class 5 accuracy range and project-definition maturity levels.
- The worked ROM figures and the modernization scenario are illustrative and are not a customer result.