Someone asks for the number.
“How much will it cost?”
“How long will it take?”
“How many people do we need?”
It is a reasonable question.
There is just one problem.
Nobody has done the work before.
There is no historical benchmark. No comparable program. No proven delivery model. The requirements are still evolving. The technology may be unfamiliar. The dependencies are not fully understood.
And yet, somehow, the organization is expected to produce a number.
So a spreadsheet appears.
Assumptions are entered.
Workstreams are broken down.
Resources are multiplied by rates.
Contingency is added.
The total comes out to $18.7 million and 14 months.
It looks precise.
It may even look reassuring.
But precision is not the same thing as confidence.
“When the work is unprecedented, the goal is not to eliminate uncertainty. It is to make uncertainty visible and manageable.”
The spreadsheet can create a false sense of certainty
There is nothing inherently wrong with a detailed estimate.
In fact, detailed estimating is essential for managing complex work.
The problem comes when the level of detail in the spreadsheet exceeds the level of knowledge in the underlying assumptions.
A team may estimate 2,400 hours for a particular activity.
Why 2,400?
Because someone believes it will take six people ten weeks.
Why six people?
Because that is what the model needs to make the schedule work.
Why ten weeks?
Because that is what the stakeholder expects.
Suddenly, a chain of assumptions has become a number with two decimal places.
The spreadsheet did not create new knowledge.
It simply gave existing uncertainty a more precise appearance.
That distinction matters when leadership is making investment decisions.
There is a difference between estimating and guessing
Guessing is not a methodology.
Neither is picking a number that everyone can live with.
A credible estimate starts by separating what is known, what is assumed, and what is unknown.
That sounds basic.
In practice, it is one of the hardest disciplines in complex programs.
Suppose an organization is implementing a technology it has never used before.
Some work may be relatively predictable:
- project management
- standard infrastructure
- known integration patterns
- established testing activities
Other work may be much less certain:
- new product capabilities
- complex data migration
- unfamiliar architecture
- behavior change
- regulatory interpretation
- integration with systems that have never been connected
Treating all of those activities with the same level of estimating confidence is a mistake.
The estimate should reflect the uncertainty.
Start by asking: what do we actually know?
Before putting numbers into a model, break the work into categories.
Known work
Activities the organization understands well and has performed before.
These can often be estimated using historical evidence or established benchmarks.
Analogous work
Activities that are not identical but resemble previous work.
This is useful, provided the differences are understood.
Emerging work
Activities where there is some knowledge, but important variables remain uncertain.
These need explicit assumptions and ranges.
Unknown work
Activities where the organization does not yet understand the effort, complexity or dependencies well enough to estimate confidently.
These should not be disguised as known work.
They need discovery.
That last category is particularly important.
Sometimes the most responsible thing to put in an estimate is not a number.
It is:
“We don’t know yet.”
That is not a failure.
Pretending otherwise is.
“An honest unknown is more useful than a precise number built on an assumption nobody has tested.”
Estimate ranges, not just points
When uncertainty is high, a single number can be misleading.
Instead of saying:
Cost: $20 million
say:
Current estimate: $16–24 million, based on the assumptions we can validate today.
Then explain what drives the range.
Maybe data migration represents the largest uncertainty.
Maybe the number of integrations is still being confirmed.
Maybe the organization has not decided how much functionality belongs in the first release.
Now leadership can have a productive conversation.
What would narrow the range?
Which assumptions matter most?
What information would materially change the estimate?
Where is additional discovery worth paying for?
The range is not an admission of weakness.
It is a representation of what the organization actually knows.
Confidence should be part of the estimate
Two estimates can have the same midpoint and completely different levels of confidence.
Consider:
Estimate A: $20 million, based on three comparable implementations.
Estimate B: $20 million, based on early assumptions for a new technology, undefined requirements and limited historical data.
They are not equivalent.
The number is the same.
The quality of the estimate is not.
This is why good estimating includes a confidence assessment.
Not just:
“What is the estimate?”
But:
“How confident are we, and what would make us more confident?”
That creates a much healthier relationship between estimates and decisions.
Don’t hide uncertainty in contingency
Contingency has an important role.
But it is often used as a substitute for understanding.
The team estimates the work as best it can and then adds 20%.
Problem solved.
Except it isn’t.
If the uncertainty comes from five major unknowns, adding a generic contingency does not tell leadership what those unknowns are.
A better approach is to identify the specific sources of uncertainty and estimate their potential impact.
Maybe there is a 30% chance that a major integration requires additional development.
Maybe data quality could create significant migration effort.
Maybe a regulatory requirement could change scope.
Now contingency becomes something that can be managed.
As the unknowns are resolved, the estimate can become more precise.
That is very different from simply adding a buffer and hoping it is enough.
The estimate should evolve as the work becomes known
An estimate is not a promise made once.
It is a model of current knowledge.
Early in a program, the range should usually be wider.
As discovery occurs, assumptions are tested and design decisions are made, the range should narrow.
That creates an important principle:
The estimate should change because knowledge changes.
Not because someone wants the number to look better.
This can create uncomfortable conversations.
If a $20 million estimate becomes $24 million after discovery, some leaders will ask why the estimate “increased.”
But perhaps the better question is:
“What did we learn?”
If the organization discovered a major dependency that was previously unknown, the increase may represent better decision-making rather than poor estimating.
The worst outcome is not an estimate that changes.
It is an estimate that refuses to change even after reality does.
The first phase may be about learning, not delivering
This is particularly relevant for novel programs.
When the organization genuinely has limited knowledge, it may make sense to fund a short discovery phase before committing to the full program.
The objective is not to produce deliverables for the sake of activity.
It is to reduce uncertainty.
Prototype the difficult technology.
Test the integration.
Profile the data.
Validate the architecture.
Confirm regulatory requirements.
Run a pilot.
Engage the people who will actually operate the new process.
Then update the estimate.
A relatively small investment in discovery can materially improve the quality of a much larger investment decision.
The alternative is often to commit early based on assumptions and pay for the learning later—usually at a much higher cost.
“When uncertainty is expensive, buy information before you buy scale.”
Watch what happens to the estimate under pressure
There is another issue that has less to do with mathematics and more to do with organizational behavior.
Sometimes the estimate starts high.
Then someone asks for a lower number.
The scope is “optimized.”
The timeline is “challenged.”
The resource model is “leaned out.”
The contingency is reduced.
Eventually, the number reaches the level the organization wanted.
That may feel like progress.
It isn’t necessarily.
There is a critical difference between reducing the estimate because the work has been redesigned and reducing the estimate because the number is politically inconvenient.
The first is management.
The second is wishful thinking.
Good estimating creates enough transparency that leadership can see which levers actually change the outcome.
Reduce scope?
The cost comes down.
Extend the timeline?
Resource requirements may change.
Change the delivery model?
The risk profile may shift.
Increase automation?
Potentially reduce effort, but perhaps increase technology cost.
Those are real trade-offs.
Simply asking the estimate to be smaller is not one.
Five questions to ask when the work is new
When there is little or no historical basis for an estimate, leadership teams should ask:
1. Which parts of the estimate are based on evidence?
Separate history from assumption.
2. What are the biggest unknowns?
If they are not visible, the estimate is hiding risk.
3. What would make the estimate materially change?
Identify the variables that actually matter.
4. What can we learn before committing to the full investment?
Consider prototypes, discovery phases and pilots.
5. How will the estimate evolve as we learn?
Define the points at which assumptions and ranges will be revisited.
These questions turn estimating from a one-time finance exercise into an ongoing management discipline.
The Cybaxis perspective
When an organization is doing something for the first time, uncertainty is part of the work.
The answer is not to pretend it isn’t there.
It is to understand where the uncertainty comes from, make the assumptions explicit, quantify what can be quantified, and invest deliberately in reducing what cannot.
A good estimate does not promise that the future will behave exactly as predicted.
It gives leadership a useful view of what is known, what is uncertain and what decisions can reduce that uncertainty.
That is particularly important when the work is large, strategic or difficult to reverse.
Because when nobody has done the work before, the most dangerous number is not the wrong estimate.
It is the number everyone starts treating as a fact.
Cybaxis helps leadership teams build credible estimates for complex and unfamiliar programs—connecting scope, assumptions, resources, dependencies, risk and business outcomes so investment decisions are based on evidence rather than false precision.
If you’re being asked for a number before anyone has really defined the work, let’s start with a better question: what do we need to learn before we can trust the number?