Satire
We Gave It Six Months to Be Safe
The estimate was three weeks. The timeline was six months. Both were accurate.
Engineering estimates the feature at three weeks. The project manager adds buffer for dependencies, stakeholder review, and "organisational friction." The timeline is set to six months. Parkinson's Law is not a dependency item in the project plan.
What Actually Happens
Month one is discovery. Workshops are scheduled to align on requirements that were already in the original specification. Month two is design review — three rounds, each producing comments that require another round. Month three: implementation begins. Month four: scope clarification. A requirement has two valid interpretations and both teams have been building against different ones for six weeks.
The feature ships in month six, week three. The code represents approximately three weeks of active implementation. The remaining time was activity — documented, meeting-attended, Jira-tracked activity. The delivery is marked on-time.
“You gave it six months. You got six months. This surprises no one except the people who gave it six months.”
DivineForge Advisory
Recognise this pattern in your organisation? I help teams cut through the governance, make the right technical calls, and actually ship.
Let's talk architecture →How a Builder Should Respond
Fix the scope before you fix the calendar. A short, firm deadline with a defined scope produces work. A long, comfortable window with a vague scope produces process. Timebox the discovery phase. Define what done means before the sprint starts. The constraint is the forcing function — removing it removes the output, not the friction.
This scenario illustrates Parkinson's Law. See all 13 laws →
Stay in the loop
New satire drops when the enterprise does something worth documenting. No spam — just the next article.
20 articles about enterprise dysfunction. None of it billable. Buy me a coffee.
Buy me a coffee