Somewhere around year three or four of doing this, I stopped believing anyone who said planning was a waste of time. Not because a book convinced me. Because I watched what happened on the projects where we skipped it to “just get moving,” and I watched what happened on the ones where we didn’t. The pattern held up too many times to be a coincidence.
Planning has a bad reputation. It looks like a delay. Leadership wants to see progress, and a plan doesn’t look like progress, it looks like a document. So the pressure to skip past it and start building is constant, and it’s usually framed as urgency, as if planning and speed are opposites. They’re not. Skipped planning doesn’t make a project faster. It just moves the slow part later, to a point where it’s more expensive to fix.
The bill always comes due, just later
Here’s what actually happens when a team skips planning to “save time.” The work starts fast, which feels great for the first few weeks. Then somewhere around week six or eight, two workstreams that were never properly scoped against each other collide. Or a dependency nobody mapped turns out to block three other teams. Or the requirement that felt “obvious enough to skip documenting” turns out to have three different interpretations across the room, and now you’re rebuilding something that was already half-built the wrong way.
None of that shows up as a line item anywhere. It shows up as slipped dates, tense meetings, and a team that’s suddenly working nights to recover time that planning would have protected in the first place. The cost of skipping planning doesn’t disappear. It just moves downstream and gets bigger on the way.
I’ve worked under contracts with real financial penalties attached to missed delivery dates, the kind where a slipped week costs actual money, not just an awkward status update. Nothing sharpens your respect for planning quite like knowing exactly what a week of drift costs in dollars. Once you’ve felt that, you stop thinking of planning as overhead and start thinking of it as the cheapest insurance you’ll ever buy on a project.
What planning is actually for
Planning isn’t really about the document. Plenty of detailed plans have been wrong on day one and still done their job, because the value isn’t the plan itself, it’s the process of forcing everyone to say out loud what they assumed silently. Half of what planning surfaces isn’t a scheduling problem, it’s a disagreement that was always going to happen, just happening early instead of late.
That’s the real trade. Skip planning and you’re choosing to have that disagreement in week eight, under pressure, with money and reputation on the line. Do the planning and you have it in week one, on a whiteboard, where it’s cheap.
How much planning is actually enough
The other extreme is real too. I’ve seen teams plan for months and never ship anything, turning strategy into its own form of procrastination. That’s not what I’m defending here. The planning that matters isn’t the thick document nobody rereads, it’s the specific, boring work of naming dependencies, agreeing on what done looks like, and surfacing the assumptions that would otherwise stay silent until they cause damage.
A good rule I’ve used for years: plan hard enough that you could explain, to someone who wasn’t in the room, exactly how the pieces fit together and what could go wrong. If you can’t do that yet, you’re not ready to start, no matter how much pressure there is to show movement.
If your team is under pressure to skip it
You will get pushback for taking time to plan. Someone above you will call it slow. The move that’s worked for me isn’t to argue about the value of planning in the abstract, it’s to name a specific risk that a day of planning would catch, and ask whether the team can afford that risk showing up in week eight instead. Framed as a real cost instead of a principle, that conversation goes very differently.
A right-sized planning habit that doesn’t turn into procrastination
What’s worked for me over the years is treating planning as a fixed, small budget rather than an open-ended phase. Before a workstream starts, I ask three things to get answered on paper, not just in someone’s head: what is actually ‘done’ look like, what dependencies that aren’t in our control, and whether two people in the room are likely to have assumed different things without realizing it. That’s usually a half-day of real work, not a multi-week phase, and it catches most of what would otherwise surface expensively later.
The dependency question is the one people skip most, and it’s the one that costs the most when it’s skipped. It’s easy to plan your own team’s work in detail and never ask what you’re quietly counting on from a team you don’t control. Those silent dependencies are where schedules actually break, not in the tasks you planned carefully.
The other habit that’s paid off is separating “we don’t know yet” from “we didn’t bother to ask.” A good plan doesn’t pretend to have every answer. It’s honest about what’s still unknown and puts a name and a date next to finding out. What kills projects isn’t uncertainty, uncertainty is normal. It’s uncertainty nobody wrote down, so it just sits there quietly until it becomes a surprise.
Selling this upward without sounding like you’re stalling
If you’re the one having to defend planning time to a stakeholder who wants to see movement, resist the urge to talk about the process. Talk about the specific thing you’re protecting against. “I want to spend a day confirming what the data team needs from us before we build the wrong integration twice” lands very differently than “we need to do proper planning.” One sounds like caution for its own sake. The other sounds like exactly what it is, a small investment against a specific, expensive failure mode you’ve seen before.
Where has skipping planning cost you the most, and did anyone see it coming before it happened? Tell me about it.
