ROM

A ROM (Rough Order of Magnitude) is a fast, non-binding cost estimate with an explicitly stated uncertainty band. A contractor gives a ROM early, often for market research, to show roughly what a requirement will cost before a formal proposal exists. It answers "is this a $200,000 problem or a $2,000,000 problem," not "what will you charge."

When does a contracting officer ask for a ROM?

Most requests come during market research, before a solicitation exists. The request arrives with a sources sought notice or a request for information (RFI), in a capability statement request, or as a direct question to industry.

The government uses a ROM to size a requirement and to build the Independent Government Cost Estimate. A ROM also helps the government choose an acquisition strategy and confirm that funding is plausible.

A ROM appears during performance as well. When the government evaluates a modification, it often wants a number before it requests a formal proposal.

What a ROM should contain

• A single figure or a stated range. Label the accuracy band explicitly. Do not imply it.
• The scope it covers — the work you priced and, critically, the work you excluded.
• The period assumed — the base period and any option periods. A per-year figure and a total-value figure are very different answers to the same question.
• The assumptions — quantity, staffing profile, government-furnished items, place of performance, security level.
• The basis — analogous prior work, published rate schedules, comparable historical awards, or vendor pricing.
• A validity date. Labor rates and material prices move.

The mistake that makes this term matter

A program office asks for a rough number, and the word "rough" is right there in the request, so the whole thing reads as a low-stakes favor. Someone answers it from a spreadsheet in an afternoon, sends a single figure in the body of an email, and returns to the work that has a real deadline attached.

The government does not read it as a rough number. It reads it as what this company thinks the work costs, and that figure travels: into the independent estimate, into the funding request, into whatever briefing sets expectations for the acquisition. Later the solicitation appears, the real proposal is materially higher, and the conversation is no longer about the estimate. It is about why the price moved. Nobody remembers the caveats, because the email never had any.

What goes wrong with ROMs in practice

The government treats it as a bid. A ROM without a stated accuracy band and without an exclusions list becomes a price in the record. When the eventual proposal arrives materially higher, the credibility damage is real, and it lasts across the whole program office.

Nobody bounds the scope. A ROM for "system integration" that does not say whether it includes testing, documentation, training and transition is not an estimate. It is a number that the reader will misread.

The period is ambiguous. A reader who cannot tell an annual figure from a total figure will choose the convenient reading.

The estimate omits wrap. Direct labor times hours is not a price. A ROM built on unburdened labor understates the cost by a large multiple. It sets an expectation you cannot meet.

The contractor anchors low to look attractive. Market research is not a competition. A ROM that undershoots badly can cause the government to under-scope or under-fund the requirement. The result is a solicitation nobody can execute profitably, including you.

What to do

1. Build the ROM from a comparable prior effort or a published benchmark.
2. Apply your actual burden structure to the direct labor.
3. State the accuracy band and the exclusions with the number, never separately.
4. State the period the figure covers, and label it annual or total.
5. Compare the result against historical award values for comparable work.
6. Keep the assumptions you used, and compare them against the solicitation when it appears.

Federal award data is public through USAspending and FPDS. An estimate far outside the range of comparable awards deserves a second review before you send it. The difference between your ROM assumptions and the actual requirement is the fastest measure of how much the requirement moved.

What a ROM is not

A ROM is not a Basis of Estimate, and you must never represent it as one. It carries no auditable per-element justification. Nobody builds it for cost realism analysis. It is not certified cost or pricing data.

A ROM is also not a binding offer. It is still a representation to the government, and the government will remember it as one. The honest number is therefore also the commercially smart number.

Silas™ produces ROM figures from a company's own labor structure and benchmarks them against comparable historical federal awards.