Assumption: Impossible
Theyβre the invisible gremlins in your project plan
β¦ the things you think are true, act like theyβre trueβ¦ but havenβt actually confirmed.
And yes, theyβre everywhere.
π€ What is a project assumption?
A project assumption is something youβre treating as fact β even though it hasnβt been verified.
They often sound like:
βThe client will get back to us this week.β
βThe budget includes final delivery costs.β
βWeβll have access to the staging site by Friday.β
βEveryone will be available during the launch window.β
Assumptions can relate to:
Timelines
Budget
Resources
Stakeholders
Access
Approvals
Team availability
Basically, anything youβre counting on.
β οΈ Why assumptions are dangerous
Assumptions seem harmless β until they arenβt.
When you build a timeline or delivery plan around something unconfirmed⦠and it turns out to be false?
π₯ Youβve got a delay.
π₯ A risk turns into an issue.
π₯ Or youβre explaining to leadership why the plan just fell apart.
And the worst part? Because it was never captured explicitly, itβs hard to even explain what went wrong.
β What to do with project assumptions
Simple: Capture them. Question them. Review them.
Example:
Assumption: The client will provide feedback within 48 hours
Risk: If not, the project may slip by 3β5 days
Action: Set a deadline, follow up proactively, and build a buffer
You donβt have to eliminate all assumptions β thatβs not realistic.
But you do need to:
Know they exist
Make them visible
Create contingency plans when it matters
Thatβs what makes your RAID log more than just admin β itβs how you protect your timeline.
π΅οΈββοΈ How to spot hidden assumptions
Ask your team (and yourself):
What are we assuming, but havenβt confirmed?
What are we basing this timeline on?
What would derail us if it didnβt happen?
What do we think we know β but havenβt checked?
Most assumptions are hiding in plain sight:
In Slack messages
In casual meetings
In throwaway lines like βThat should be fineβ
If you use a good Projects, Operations & Collaboration tool, you can track all this information there. So that you donβt lose it.
π© βShould be fineβ is almost always a red flag.
TL;DR:
Assumptions are unverified beliefs baked into your plan.
If theyβre wrong, they become risks β or worse, issues.
Track them. Question them. Talk about them.
Add them to your RAID log and review them regularly.
π― Wrapping up the RAID Series
RAID logs arenβt just another PM checklist β theyβre one of the most powerful tools in your project toolkit.
They help you:
Spot risks before they become issues
Manage issues before they escalate
Navigate dependencies before they block you
Catch assumptions before they bite
And when you use them consistently?
They give you something rare in project management: control.
So the next time someone says βa RAID log is overkill,β
Just ask them how often they find themselves firefighting.