Early ROM estimates are about risk discovery

2026-10-12T08:30:00.000Z

A ROM estimate isn’t just an effort estimate, it’s also about discovering risk.

In my last post I discussed why ROM estimates are necessary when the requirements aren’t yet firm, and why they’re rarely about being “right”.

There’s another important aspect to creating them. They’re about highlighting assumptions and risks early enough for the business to make sensible decisions. And importantly, discovering and making clear where you might be wrong.

Some of the risks will be technical and good ROM estimates tend to bring forward the same types of questions:

• Do we truely understand the difficult parts of the system? (usually not in my experience)
• Do we have the expertise in-house needed to build the difficult parts?
• Are we dependent on any hardware that may arrive late?
• Are we assuming that integration between subsystems will be straightforward?

Sometimes the risks are obvious but often they aren’t until someone has taken the time to sketch how the system might actually work. The goal isn’t to eliminate uncertainty as that’s rarely possible, the goal is to make the uncertainty visible.

But some of the most important risks aren’t technical, they’re organisational. Most businesses don’t have unlimited engineering capacity. If a major new project starts, where do those engineers come from?

• Can we afford to take experienced people away from existing projects?
• If we need additional expertise, can we realistically recruit or contract it in time?
• Are we dependent on decisions that are outside of our control?

These questions matter because software projects hardly ever exist in isolation. Starting one thing often means slowing some other thing down.

I now see ROM estimates as less of a prediction exercise and more as a methodical way of exposing unknowns and uncertainty.

Sometimes the conclusion is: “Yes, I think this is possible.” “Yes, it’s possible but only if we reduce scope.” “Yes, but we’ll need some external expertise.” “Yes, but we’ll need to purchase this software.”

Or occasionally: “No, not without unacceptable impact elsewhere.” “No, we don’t have the expertise and can’t acquire it in the timescale provided.”

All of which is valuable information. But the primary goal of an early estimate isn’t to eliminate uncertainty as that’s impossible for any non-trivial project.

It’s to make the uncertainty visible early enough to give the business options.

Post 2/4 on estimating software projects.