Pocket PMOROM estimate example for project managers
A ROM estimate gives stakeholders a directional range before detailed planning is possible. It should clearly communicate uncertainty instead of pretending early numbers are precise.
Example structure
For each major phase, capture a low, likely, and high estimate. Add the assumptions that drive the range, such as integration complexity, vendor dependency, or unknown data quality.
How to communicate the range
Present the estimate as a decision support range, not a commitment. Explain what would need to be learned before the range can narrow.
When to refine it
Refine the ROM estimate after scope validation, WBS decomposition, vendor quotes, or technical discovery. Each refinement should reduce uncertainty or make risk explicit.
A worked ROM example
Suppose an integration phase carries three work packages: data migration, API integration, and user training. Low, likely, and high estimates of 12, 18, and 30 person-days each give a phase range of 36 to 90 days around a 54-day expected value. The width of that range, not the midpoint, is the message stakeholders need.
Communicating the range to sponsors
Present the range together with the assumptions that drive it, and name what learning would narrow it: vendor confirmation, data-quality checks, or a short discovery spike. Sponsors who can see which assumption dominates the spread can decide whether to buy certainty or carry the risk for another planning cycle.
Refining without losing the baseline
Keep the original ROM visible as the project refines. Comparing the current estimate against the early range is a health signal: estimates collapsing toward the low bound or drifting past the high bound both deserve attention long before the budget is formally revised or the schedule slips into the red.
Run the example on your own schedule
Run the same low, likely, and high structure on your own work packages in Pocket PMO and give stakeholders a decision support range instead of a single guess.