ROM estimate vs definitive estimate

What actually separates a ROM from a definitive estimate

The distinction is methodology, not just precision. A ROM uses analogous (top-down) estimating: take a similar past project's actual cost, adjust for known differences, apply a wide band. It needs no work breakdown structure because none exists yet. A definitive estimate uses bottom-up estimating: decompose the scope into a work breakdown structure, estimate each work package's roles, hours, and cost, then sum the packages into a total. The U.S. Government Accountability Office's cost-estimating guidance frames this the same way — analogy methods belong early in a program's life cycle when detailed information is limited, while a build-up (bottom-up) method is only appropriate once the analyst has the detailed information a decomposed scope provides.

That is why a ROM's accuracy band (commonly -25%/+75%) and a definitive estimate's band (commonly -5%/+10%, see what is a ROM estimate for both) aren't just "the same number, more confidently stated." They come from structurally different calculations, built on different amounts of information, at different points in the sales cycle.

The quote that wasn't a quote

The real-world failure mode is specific and common: presales gives a ROM range in an early conversation, and the client — or even the firm's own sales team, under pipeline pressure — treats the low end or the midpoint as a committed price. Nobody intended this. The ROM was mathematically honest when it was given. But a range travels badly. By the time it reaches a budget memo, a Slack message, or a verbal recap in someone else's meeting, only one number tends to survive, and it is rarely the high end.

This matters because the two estimate types protect different things. A ROM protects the decision to proceed; it says nothing about what a fixed-price contract should cost. Confusing them either commits a firm to a fee it under-priced, or leaves a client feeling misled when the definitive number lands well above the ROM's low end — even though that outcome was always inside the stated range.

When to use which — and the wrong-tool trap

Use a ROM at initiation, for a feasibility study, a business case, or portfolio prioritization — anywhere the question is "is this worth scoping." Use a definitive estimate once a work breakdown structure exists and the number is going into a firm-fixed-price proposal, statement of work, or contract. The wrong-tool trap runs in both directions: building a full bottom-up estimate for a same-day feasibility question wastes presales time scope will likely change before it is offered as a fee, and offering a ROM-derived figure as a firm-fixed-price commitment under-protects margin because the method behind it was never designed to bear that weight.

Moving from a ROM to a definitive estimate

1. Decompose the scope into a work breakdown structure once discovery has happened — deliverables, then the work required for each.
2. Estimate each work package bottom-up: role, allocation, duration, and the approved cost rate for that role (see resource-based project cost estimation for the mechanics).
3. Sum the work packages into a total, then add the firm's documented non-labour and overhead treatment.
4. Compare the bottom-up total against the original ROM range as a sanity check, not a target — a result outside the range means either the ROM's comparator was a poor match or the scope grew, and both are worth naming explicitly.
5. Present the definitive number with its own basis of estimate; do not simply say the ROM "firmed up."

How this plays out on a real project

Consider an illustrative case: a mid-size IT consultancy is proposing an ERP data-migration project for a manufacturing client.

• Kickoff: in an early call, the account lead gives a verbal ROM of "somewhere in the $150,000 to $260,000 range." The client's finance team writes "$150,000" into an internal budget-approval memo. Handling: send the range and its basis in writing within the same day, so the memo has something more durable than a half-remembered verbal figure to cite.
• Mid-proposal: the completed work breakdown structure lands the bottom-up total above the ROM's midpoint. Handling: present the definitive number with its own basis of estimate and explicitly reference which ROM assumption turned out to be wrong — usually scope, not the method.
• Pipeline pressure: sales wants to just quote the ROM's low end to close faster. Handling: this is precisely the accidental-quote failure mode above; a ROM-derived figure has never been through the estimating rigor a fixed-price commitment requires.
• Post-signature: once the contract is signed at the definitive number, a scope discussion mid-delivery starts drifting back toward ROM-level vagueness ("it's basically the same kind of work as before"). Handling: any material scope change now needs its own bottom-up delta, not a reversion to top-down reasoning; see pricing option to delivery baseline for how an approved baseline should be protected once delivery begins.

Worked instance: the same project priced two ways

Top-down (ROM). A comparable past ERP migration cost $150,000 to deliver. Applying the traditional PMI band of -25%/+75%: low = 150,000 × 0.75 = $112,500; high = 150,000 × 1.75 = $262,500. Range: $112,500 to $262,500, midpoint $187,500.

Bottom-up (definitive). Once discovery produces a four-work-package breakdown — data mapping, migration scripting, validation, and cutover support — the estimate is built role by role:

Adding a $2,500 specialist-contractor cost and 12% labour overhead (12% × $87,800 = $10,536) brings the definitive estimate to $87,800 + $2,500 + $10,536 = $100,836. That figure sits inside the ROM's range but well below its $187,500 midpoint — meaning a firm that had quoted the midpoint as a shortcut would have overpriced the deal by roughly $86,700, and a firm that happened to quote the ROM's bare low end of $112,500 would have looked closer, but only by chance, not because that number carried any real basis. Neither naive shortcut replaces the work breakdown structure that produced $100,836 with a traceable basis.

Practical mitigations to state every time you give a ROM

• Always present a ROM as a range, never a single number — say the low end and the high end every time, not just once.
• State the basis of estimate alongside any number: what comparator produced it, what's included, what's excluded, and what's assumed.
• Put in writing, the same day it's given, that the number will tighten as scope is defined — don't let a verbal caveat be the only record of that fact.

These three habits are simple enough to sound unnecessary, and they are the entire subject of giving a ROM estimate without anchoring, because the psychology working against you is stronger than the caveat you attach to the number.

Sources and methodology

• U.S. Government Accountability Office, Cost Estimating and Assessment Guide (GAO-20-195G). Used for the analogy-method-versus-build-up-method distinction and when each is appropriate.
• Project Management Institute, PM101: Estimating. Used for the top-down and bottom-up estimating framing and traditional accuracy conventions.
• Project Management Institute, Lexicon of Project Management Terms, Version 5.0. Used for the bottom-up estimating definition.
• The worked ERP-migration figures and scenario are original and illustrative, not a customer result.