ASSUMPTION HALF-LIFE
When an assumption stays in place long after the conditions that made it reasonable have changed.
What this pattern is
Projects are built on assumptions.
A resource will be available.
A dependency will be ready.
A customer will respond by a certain date.
A technical approach will work.
A decision will hold.
Most assumptions aren’t inherently bad.
The problem is that projects change while assumptions often don’t.
An assumption made weeks or months ago continues to shape the plan even though the conditions around it have shifted.
The assumption hasn’t been proven wrong.
It just hasn’t been tested again.
What this usually looks like
“We were told that would be ready.”
“That was the plan when we started.”
“I thought they were still supporting that.”
“We’ve always been working toward that date.”
Dependencies remain in the schedule without being reconfirmed.
Resource plans rely on availability discussed months earlier.
Old decisions continue driving work even though circumstances have changed.
Teams discover late that something they were counting on is no longer true.
Why this happens
Assumptions often disappear into the project once they’ve been accepted.
They become dates, plans, dependencies, estimates, and expectations.
Over time, people stop seeing the assumption underneath them.
Meanwhile, the project keeps changing.
Priorities shift.
Resources move.
Technical information improves.
Customer expectations evolve.
The assumption stays still while everything around it moves.
What this causes
Plans become increasingly disconnected from current conditions.
Dependencies fail unexpectedly.
Teams make decisions using outdated information.
Risks surface later than they should.
Schedule and cost problems appear to come out of nowhere.
The PM ends up reacting to a problem that was quietly developing long before it became visible.
First move to stabilize it
Don’t ask only:
“What assumptions are we making?”
Ask:
“Which assumptions haven’t we tested recently?”
Look especially at assumptions supporting major dates, dependencies, resources, technical decisions, and customer commitments.
Then reconfirm the ones that would hurt most if they were no longer true.
The goal isn’t to eliminate assumptions.
It’s to recognize when an old assumption is still quietly running the project.
People may appear aligned while holding different assumptions about who owns the next move.
→ See False Alignment
Formal project artifacts can remain unchanged while the team’s understanding of the project evolves somewhere else.
→ See Story Drift