ASSUMPTION HALF-LIFE
The schedule assumes a resource will be available.
A dependency is supposed to be ready. The customer is expected to respond by a certain date. A technical decision made months ago is still shaping the plan.
All of those assumptions were reasonable when they were made.
But the project has changed since then.
The assumption hasn’t necessarily been proven wrong. No one has gone back to see if it’s still true.
That’s Assumption Half-Life.
What is Assumption Half-Life?
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.
Signs old assumptions are still driving the project
“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 project assumptions outlive the conditions behind them
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 happens when project assumptions aren’t retested
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.
What to do when your project depends on old assumptions
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.
If this feels familiar, you’re not the only one dealing with it.
I write PM Clarity for project managers navigating the messy parts of the job — unclear expectations, shifting priorities, difficult decisions, and the things that don’t always show up in the project plan.
People may appear aligned while holding different assumptions about what was decided, what matters, or what happens next.
→ See False Alignment
Formal project artifacts can remain unchanged while the team’s understanding of the project evolves somewhere else.
→ See Story Drift