ROM estimates and what must be true for the schedule to hold

2026-10-26T08:30:00.000Z

One of the more common mistakes I’ve seen in software projects is treating an effort estimate and delivery date as the the same thing. An effort estimate answers:

“How much work is involved?”

And the delivery date answers:

“When will it be ready?”

They sound alike, but they’re really different questions. In my earlier career project plans tried to make the distinction explicit. We’d estimate six engineer months of work and then build a schedule based on the number of engineers available. The problem with this approach was that the schedule often assumed the engineers were available 100% of the time. In reality they’re not.

Engineers get pulled onto customer support, priorities change, holidays and illness happen, new bids arrive for future work. The engineering capacity was rarely what the project plan assumed.

Modern Agile approaches handle this differently. Rather than trying to predict the entire project up front, teams begin work and use observed velocity, throughput and forecasting tools to predict completion dates. Personally, I’ve found that to be an improvement as the forecast is based on observation rather than assumption.

But it still doesn’t answer the question the business really wants answered.

“When will it be ready?”

And usually they want that answer before the team has started, when we don’t yet have a velocity. So, we’re back to making assumptions again.

What I have noticed though is that projects don’t slip because the engineering estimate was wildly off. They slip because the assumptions about capacity were wrong. The estimate said:

“This looks like 6 engineer months of effort.”

The schedule quietly assumes:

“We have 2 engineers available full time.”

A few months later we discover those engineers were available closer to 60% of the time. Even with resource utilisation applied to the project the completion date was nearly always wrong even though the effort estimate hadn’t changed. The problem, of course, was that utilisation was just another assumption. One of my old PM colleagues would say:

“The only thing you can be sure of with a project plan is that tomorrow it will be wrong.”

This is one reason I’ve become uncomfortable discussing project delivery estimates. The technical uncertainty is often obvious but the organisational uncertainty usually isn’t.

• Can we recruit the people we need?
• Will individuals be shared across projects?
• How much support work will interrupt delivery?
• How stable are priorities?

These factors can have more impact on the schedule than the technical implementation itself. Which is why I’ve come to think that early estimates are often less about prediction and more about exposing assumptions. Not just:

“How much work is this?”

But:

“What must be true for this schedule to hold?”

Because in my experience, projects rarely fail because nobody estimated the effort. They fail because nobody challenged the assumptions that turned effort into calendar time.

Post 4/4 on estimating software projects.