A ROM estimate isn't about accuracy

2026-10-01T09:27:00.000Z

A ROM estimate isn’t about accuracy, it’s about whether the business can risk doing the work at all

I’ve worked in serveral engineering teams when the business has asked for an early estimate for a new feature or project. On several occasions I’ve heard the same response:

“We need firm requirements before we can tell you how long it will take.”

The problem is that the business is usually asking for an estimate precisely because the requirements aren’t firmly known yet. They’re trying to answer a more basic question:

“Can we afford to do this without risking everything else?”

In those situations I’ve found it futile to begin estimation without first gaining some idea of what the system might look like. Without this, the estimation process is essentially guesswork.

This can be an uncomfortable process because, as engineers, we like to be sure of what we’re doing. This discomfort probably explains why as engineers we sometimes resist ROM estimation. We’re being asked to reason about something we don’t yet fully understand.

I start by trying to estimate the shape of the system.

• What might a sensible architecture look like?
• Which parts would we build ourselves?
• Which parts could or should we buy or integrate?
• Where are we dependent on hardware, suppliers, or other teams?

When you have a rough idea of what the system might look like it makes estimation possible.

• We’ll need to implement module A - N man days
• We’ll need to unit test module A - M man days
• We need to purchase software B, install configure, deploy and learn how to use it - P man days
• We’ll need to integrate module A with moule B - Q man days
• We’ll need to write system tests and write the automation tests for the same - R man days
• We don’t know how to do feature X yet, make some assumptions and take a reasoned guess.

The rough system design makes creating a rough picture of the work involved possible: implementation, integration, testing, tooling and so on.

The result is never a precise number. It’s a ROM (Rough Order of Magnitude) estimate, with the assumptions clearly stated and an honest indication of confidence.

That confidence depends heavily on how much time there was to think.

• If I was given a day, it will be rough and I’ll say so.
• If I was given a week to explore options and dependencies, the estimate becomes more grounded.

Often that’s enough for the business to decide whether to proceed, adjust scope, or walk away early. Which is really the purpose of the ROM estimate in the first place.

Post 1/4 on estimating software projects.