Every project starts with a plan.
You define the scope. Estimate the work. Build a timeline. Get buy in from stakeholders.
Then you start building. And within days, the plan is already wrong.
The feature is more complex than expected. A key person gets sick. Requirements change. Technical debt surfaces. A dependency slips.
By the end, the project looks nothing like the original plan.
Why does this happen every single time?
The Illusion of Control
Plans give us the illusion of control. If we think hard enough, document thoroughly enough, estimate carefully enough, we can know what will happen.
But software projects are inherently uncertain.
You're building something that doesn't exist yet. You're solving problems you haven't seen before. You're coordinating people with competing priorities.
There's no way to plan for every contingency. The plan is a guess. Sometimes an informed guess, but still a guess.
What We Don't Know
Here's what we underestimate when we plan:
Technical complexity: "This should be simple." Then you discover the API doesn't support what you need, the library has bugs, and the database schema needs refactoring.
Scope creep: "Just one more thing." Stakeholders add requirements. You discover edge cases. The definition of "done" keeps expanding.
Human factors: People get sick. They leave. They're less productive than expected. They misunderstand requirements.
Dependencies: Your work depends on another team. That team is delayed. Now you're delayed.
Unknown unknowns: Things you didn't even think to plan for. A security vulnerability. A performance issue. A compliance requirement.
Plans assume we know what we don't know. But we can't plan for what we can't anticipate.
The Planning Fallacy
Psychologists call it the "planning fallacy": we systematically underestimate how long things will take, even when we know we tend to underestimate.
Why? Because we plan based on the ideal scenario:
- No bugs
- No scope changes
- No interruptions
- No technical surprises
- No people issues
We plan for the best case and call it the expected case.
Then reality introduces friction at every step, and we wonder why we're behind schedule.
The Compounding Effect
Small deviations compound.
Task A takes 20% longer than expected. That delays Task B. Task B reveals a problem that requires rework on Task A. Now you're 40% behind.
Meanwhile, stakeholders are asking for updates. That's more meetings, more context switching, more delay.
The further you get from the plan, the less useful the plan becomes.
Why We Keep Planning Anyway
If plans are always wrong, why do we keep making them?
Because organizations demand predictability. Finance needs budgets. Sales needs timelines. Marketing needs launch dates.
Plans make people feel comfortable, even if they're fiction.
So we make plans, knowing they'll be wrong, because not having a plan is worse than having a wrong one.
The Agile Compromise
Agile tried to solve this by shortening planning horizons. Don't plan six months out. Plan two weeks.
This helps. Short term plans are more accurate than long term ones.
But it doesn't solve the fundamental problem: even two week plans go off track.
And at some point, the business needs longer term visibility. You can't just shrug and say "we'll figure it out sprint by sprint."
What Actually Works
Since projects never go as planned, what should we do instead?
1. Plan lightly
Make rough plans that set direction without over committing to details. The further out, the lighter the plan.
2. Expect deviation
Build buffers. Assume things will take longer. Plan for interruptions.
3. Replan frequently
Don't treat the plan as sacred. Check it weekly. Adjust as you learn.
4. Focus on outcomes, not tasks
Instead of "complete these 20 features," aim for "improve onboarding conversion." You can adapt the approach while keeping the goal.
5. Communicate uncertainty
Be honest with stakeholders. "Here's our best guess, but expect it to change."
6. Ship incrementally
Release small pieces frequently. This reduces risk and gives you real feedback faster than planning ever could.
The Acceptance
Here's the mindset shift: stop expecting projects to go as planned.
Plans aren't predictions. They're starting points. They give you direction, not destiny.
The goal isn't to follow the plan. The goal is to ship something valuable. If the plan gets you there, great. If not, change the plan.
The plan is a tool, not a commitment.
The Better Metric
Instead of asking "did we hit the plan?" ask:
- Did we ship something valuable?
- Did we learn quickly when the plan was wrong?
- Did we adapt effectively?
- Did we communicate changes clearly?
Success isn't following the plan. It's achieving the goal despite the plan falling apart.
The Bottom Line
Why does no project go as planned?
Because reality is more complex than any plan can capture.
Technical work is uncertain. People are unpredictable. Requirements evolve. Stuff happens.
The teams that succeed aren't the ones with perfect plans. They're the ones who adapt quickly when the plan breaks.
Plan lightly. Ship frequently. Learn constantly. Adjust ruthlessly.
That's how you ship great products, even when nothing goes as planned.