A rough order of magnitude (ROM) estimate gives an early range from a stated scope and a credible estimating basis. Build plausible low and high effort scenarios, apply relevant cost rates, and separate cost from the client price. The five examples below show the arithmetic and the unknown that drives each range.
Terms used in this guide. fee: the amount charged to the client; cost: the expense included in the stated project model; margin: revenue left after the included costs; margin percentage = that amount / revenue × 100; baseline: the approved original plan kept for comparison.
In plain words
A ROM cost estimate is built from two things: how much effort the work might need (a low and a high case) and what each hour costs. The five examples show the arithmetic step by step, from a small website job to a change request, so you can copy the method. Each one also shows the single unknown that makes the range wide.
Who this helps: Presales consultants and new project managers who want to see a ROM worked out in numbers, and sales managers who want to understand what sits behind the range they send.
Questions this guide answers:
- How do you calculate a ROM cost estimate?
- What is a rough order of magnitude estimate, with examples?
- How do you turn a ROM cost into a price?
- What does a ROM estimate look like for a services project?
Read first: What is a ROM estimate? explains the basics and the lifecycle this guide builds on.
What are the formulas for a ROM cost estimate and price?
Role labor cost = estimated role hours × hourly planning cost rate
Scenario cost = sum of role labor costs + other included project costs
Client fee = non-revenue-based cost / (1 − revenue-based cost share − target margin)
Margin % = (fee − total included costs) / fee × 100
Hours describe the work expected from a role, not the elapsed project duration. The planning cost rate is an internal finance-approved hourly input, not the client billing rate. Sum the role lines separately for each low and high scenario. Add licenses, travel and any applicable cost rules once. Use decimal shares in the fee formula: 30% becomes 0.30. The formula assumes a positive divisor and the stated linear cost bases.
For the simple ERP table example, low cost is 600 × USD 60 = USD 36,000 and high cost 900 × USD 60 = USD 54,000. With no other costs and a 30% target margin, the corresponding client fees are 36,000 / 0.70 = USD 51,428.57 and 54,000 / 0.70 = USD 77,142.86. Adding 30% to the cost would be markup, not a 30% margin.
The USD 60 rate in that summary is a simplified blended assumption. A proposal needs the actual role mix behind it. The application walkthrough below reconstructs the USD 36,000 low case with distinct role rates and shows how to test the more difficult case.
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.
How do you read a ROM estimate example?
These ROM estimate examples describe internal delivery cost, not a selling price. The low and high cases vary effort; they are not statistical confidence limits. A range is useful only when someone can explain what changes between its endpoints. No universal accuracy percentage applies to all consulting, agency or IT projects.
Use the range to decide whether a project merits discovery, not to silently commit to a fixed fee. For pricing, add the applicable project costs and revenue-based charges, then test the required margin. A delivery cost of USD 40,000 and a budget of USD 40,000 are different statements.
Begin by asking what decision the estimate supports. A finance team comparing two possible initiatives needs a consistent cost boundary; a buyer checking affordability needs a supplier fee range. Keep the intended audience on the estimate sheet. Then choose the estimating unit that explains the work: comparable interfaces, repeatable pages, investigation hours or role-based transition effort. Applying a precise hourly rate to an unsupported effort guess does not make that guess more reliable.
Build the endpoints from plausible delivery conditions. The low case should still include the work needed to achieve the stated outcome. The high case should explain a difficult but relevant condition, rather than represent every imaginable disaster. If the two cases describe different scope, label them as separate options. This distinction helps the reader understand whether discovery will narrow uncertainty or whether a commercial scope decision is required.
Five ROM estimate examples with hours, cost and price
| Project and method | Low case | High case | Main uncertainty | Fee range at 30% margin |
|---|---|---|---|---|
| ERP integration: analogous | 600 h × $60 = $36,000 | 900 h × $60 = $54,000 | Clean API versus custom reconciliation | USD 51,429–77,143 |
| Agency website: parametric | 20 pages × 6 h × $55 = $6,600 | 20 pages × 10 h × $55 = $11,000 | Approved content versus rewriting | USD 9,429–15,714 |
| Data-platform discovery: sizing | 80 h × $75 = $6,000 | 140 h × $75 = $10,500 | Scope option: two source systems (low) or five (high); agree which one the client wants before sharing the range | USD 8,571–15,000 |
| Managed-services transition: resource-based | Lead 80 h × $80 + engineer 240 h × $50 = $18,400 | Lead 120 h × $80 + engineer 360 h × $50 = $27,600 | One migration rehearsal versus two | USD 26,286–39,429 |
| Live change request: bottom-up | Analysis 8 h × $70 + build 24 h × $60 + test 8 h × $45 = $2,360 | Analysis 16 h × $70 + build 40 h × $60 + test 16 h × $45 = $4,240 | Existing export versus new data mapping | USD 3,371–6,057 |
In the table, analogous means starting from a similar past project, parametric means multiplying a count by a known effort per unit, sizing means picking a size band (small, medium, large) and attaching hours to it; the discovery row uses 80 hours for the small band and 140 for the large band, resource-based means hours by role and bottom-up means adding up tasks. The website model assumes the design system already exists. Add a separate fixed work package for a new design system rather than hiding it inside a per-page factor. The discovery figures cover investigation and recommendations, not platform implementation. Transition assumes the stated hours include handover and documentation; overnight coverage would require another line.
1. ERP integration: investigate the reconciliation work
For the ERP integration, the extra 300 hours cost USD 18,000 at the stated rate. Investigate the mapping and reconciliation process before changing that allowance: does the API return stable identifiers, are retries supported, and who resolves mismatched records? An API demonstration can support the low case only if it uses representative transactions. A successful connection by itself does not establish that reconciliation will be simple.
2. Agency website: cost repeatable pages and shared setup
For the website, the uncertain unit is effort per page. Six hours assumes reusable layouts and approved copy; ten hours allows more content work within the assumed page family. Twenty visually different interactive pages would require a different model. Shared work, such as analytics setup and accessibility review, should appear once outside the page multiplier when it is not already included.
3. Data discovery: price the investigation outputs
For discovery, the additional 60 hours cost USD 4,500. Explain which interviews, source-system assessments and analysis outputs use those hours. A discovery estimate should describe the investigation being purchased and the decision it enables. It should not imply that examining five source systems also includes building production pipelines for them.
4. Managed-services transition: check the role mix
For transition, the low case contains 320 total hours and the high case 480. The lead-to-engineer mix remains one to three, so the cost rises proportionally in this illustration. A second rehearsal may need disproportionately more lead time, however. Review the actual transition activities before preserving the same mix. Coverage outside normal working hours and operational support after handover are separate scope questions.
5. Change request: isolate incremental effort
For the change request, the extra work is 8 analysis hours, 16 build hours and 8 testing hours. Together they explain the USD 1,880 difference between endpoints. Trace these hours to the requested export fields and error cases. That trace lets the team re-estimate a smaller request without removing an arbitrary percentage from the fee.
What should you send the client with a ROM estimate?
Send the fee range, not the cost range, with the same scope explanation. For the integration example: “Our planning range is about USD 51,000–77,000, based on one integration and the stated reconciliation scope. It is for budgeting, not a quote. We will test the API and sample data before confirming the delivery plan.” The internal cost (USD 36,000–54,000) and the margin stay inside the firm. At a 30% target margin the fee range is the cost range divided by 0.70 (about USD 51,429–77,143), rounded to the nearest thousand for the message. These amounts are an original illustration, not market prices; show whether expenses or revenue-based charges change the calculation, and see the target-margin pricing guide for the divisor.
For a change request, say which baseline is affected: “This range covers the new export only. It excludes changes to the existing authentication flow. We will confirm the mapping before issuing the change price.” Specific wording beats a generic disclaimer. Record the date, the estimate owner and the next evidence checkpoint, and choose that checkpoint to address the biggest driver: API access for the integration, approved copy for the website, a rehearsal plan for the transition.
Which mistakes make a ROM estimate misleading?
- Calling an internal labor cost a customer quote without including other costs and margin.
- Using historical project totals without checking whether the old scope included testing or transition.
- Multiplying every component by one blanket range even when only one integration is uncertain.
- Presenting a high case as guaranteed coverage of every possible change.
Retain the input hours as well as the totals. If the client reduces scope, you can remove the affected work package rather than discounting the whole project. When uncertainty resolves, revise both endpoints and explain the evidence behind the change. A narrow range earned through investigation is more useful than one narrowed for presentation.
Real example: a presales lead reviews a junior consultant’s ROM before it goes out
An illustrative story with invented figures, to show how the idea works in a real office.
Chloe, a junior presales consultant, has drafted a ROM email for the ERP integration example. It says: “We estimate USD 36,000 to USD 54,000.” She sends it to Naveen, the presales lead, for review.
Naveen goes through the checkpoints. The figures are the cost range: 600 hours and 900 hours at USD 60. Sending them would show the client what the work costs the firm, and at a 30% margin it would also undercharge: the price range is the cost range divided by 0.70, about USD 51,000 to USD 77,000.
He asks Chloe two questions. What is the one unknown behind the 300 extra hours? (Whether the client’s API returns stable identifiers.) Where does it say so? (It does not.) Chloe rewrites the email with the price range, the unknown and a next step: “We will test the API with sample data before confirming.” It takes ten minutes, and it is the difference between a number the client can plan with and a number the firm has to defend later.
Can a ROM estimate example become a fixed-price quote?
Yes, after scope, delivery assumptions, acceptance criteria and risk ownership support a commitment. They are starting structures, not ready-to-send rates. For a priced plan, convert the selected scope into roles and stages, add cost rules once, and compare the resulting margin against your approval threshold.
Where do these examples fit in an IT project?
A ROM is easy to produce and easy to get wrong, so in most presales teams a second person reads it before it is sent. Think of it as a checkpoint between “I have a number” and “the client has a number”. A presales lead checks these things, in this order:
| Check | What the reviewer asks | Who answers |
|---|---|---|
| The decision | What will the client do with this number? Is a range what they need? | Account manager |
| The unknown | Which single unknown drives the gap between low and high, and is it written next to the range? | Presales consultant |
| The evidence | Which past project or driver supports the hours, and what was adjusted? | Presales consultant, with a delivery lead |
| The supporting work | Are testing, release, project management and client reviews included? | Delivery lead |
| Cost or price | Is every figure labelled, and does the client see only the price range? | Presales lead |
| The margin | Does the price range meet the margin policy at both ends? | Finance or presales lead |
| The review point | Does the message say what will replace the ROM and when? | Presales lead |
These checkpoints are why the examples above each name their one big unknown. For where a ROM sits in the whole project lifecycle, read what a ROM estimate is.
ROM estimate examples: frequently asked questions
Should I add a ROM percentage after estimating low and high cases?
Check what uncertainty the cases already cover. Adding a generic percentage can count the same exposure twice. If additional risks remain, describe them and show their separate treatment. Keep the original case assumptions visible so a reviewer can distinguish effort variation from a separately approved risk allowance.
Can I use these example rates in my proposal?
Use your own approved rates and cost policy. The figures demonstrate a method and are not salary, contractor or market-rate benchmarks. For a client proposal, present the approved price and scope; retain sensitive cost details internally.
When should a ROM become a firm quote?
When scope, assumptions and acceptance criteria are written down and agreed. Until then the number is a range. Moving to a quote is a new estimate with its own review, not a rounded ROM.
Should I show the client both the cost and the price range?
Show the price range. The cost range is internal: it contains your cost rates and margin. Use it to check that the price range still meets your target managed margin at both ends.
How many examples should I base a ROM on?
One close analogy is enough to start, and two or three are better. What matters is whether each comparable shares the drivers that dominate effort, such as integrations and data volume.
How do you work the ERP integration example in Managed Margin?
Consider a consulting team investigating an ERP integration before offering a fixed fee. This is a realistic editorial example, not a customer result. The team must analyze mappings, build the connector, verify transactions and coordinate acceptance. Assume a 40-hour working week for the selected work locations.
Build the low scenario from four role allocations: engineer 8 weeks × 40 hours × 100% = 320 hours at USD 60; analyst 4 weeks × 40 × 50% = 80 hours at USD 70; QA 4 weeks × 40 × 100% = 160 hours at USD 45; lead 4 weeks × 40 × 25% = 40 hours at USD 100. Labor cost is 19,200 + 5,600 + 7,200 + 4,000 = USD 36,000. Those 600 hours explain the table total, while the stage sequence still needs a delivery dependency review.
In Managed Margin, create a service order and an estimation strategy. Add the approved role profiles in Roles & Rates, then plan stages such as Analysis, Build, Verification and Handover. Load the roles into the stages or weekly grid until their totals reconcile to 320, 80, 160 and 40 hours. The application calculates effort from available hours, allocation percentage and quantity, and labor cost from effort multiplied by the planning rate.
For the difficult scenario, create a separate alternative strategy rather than overwrite the first. Increase engineer effort to 440 hours, analyst to 160, QA to 240 and lead to 60. Total effort is 900 hours; at the distinct rates its labor cost is USD 54,400. This differs from the table’s simplified USD 54,000 because the role mix changes. At a 30% target with no other charges, the role-specific fee is approximately USD 77,714.29. The difference teaches why a blended summary needs a role-level check.
Add the real project cost rules, choose Target Margin to calculate the fee, or choose Quoted Price to test the client’s available budget. Compare the alternatives on the same scope. The optional ROM price range varies price while keeping the strategy’s effort unchanged; it does not automatically create the two effort scenarios above. Finalize the accepted option as the pricing baseline, then use delivery actuals and remaining allocations to compare the current margin with the approved plan. See the stage-based estimation workflow.
Background reading: what is a ROM estimate? and ROM vs Definitive Estimate.
Continue the sequence: guides to read next
- What Is a ROM Estimate? Meaning, Cost and Example: the definition and accuracy range these examples rely on
- How to Price a Project to a Target Margin: Formula and Example: turning the cost range into a price range from a target margin
- Cost Rate vs Billing Rate: Costing and Rates Explained: keeping the cost and the price in these examples apart
- How to Present a ROM Estimate to a Client Without Anchoring: how to present early numbers so the client does not anchor on one end
Sources and methodology
This guide states no outside facts that need a citation: the formulas, stages and worked figures are Managed Margin’s own, built with the application.
The worked figures are original educational illustrations. The linked references provide background for the estimating and management concepts; they do not establish the example rates or guarantee the outcomes. Product instructions describe the current implementation and are separate from methods the reader performs outside the application.
The examples, templates and calculations are original editorial illustrations, not market benchmarks or customer results. Monetary amounts are in USD, exclude tax unless stated, and use the cost boundaries defined in the article. Validate assumptions against your own delivery history before quoting.
Further background: GAO cost-estimating process. The worked arithmetic and scenarios above are original; this reference provides context and is not a source for market rates or the stated example amounts.
The application walkthrough was checked against the current stage, pricing, cost-rule and delivery calculation code on 13 October 2026. Forecasts describe recorded actuals plus the remaining plan, not predicted customer outcomes.