Plan because it will change

Nobody I know stops keeping a budget in a year when prices won’t sit still. That’s the year they watch it hardest. The budget isn’t a prediction of what things will cost. It’s the place where a new cost has to show up next to everything else it’s taking money from.

Quarterly planning on a fixed team works the same way, and I watched a room full of smart people, me included, nearly forget that.

The standup

The client is a regional insurance broker. We’d been working with their team on an agent-portal rollout, delivered by a fixed team that also carries a second project on the same people. Same heads, two bodies of work. That detail matters more than anything else in this piece.

The rollout was behind. We’d built them a rollout-plan doc early on, the kind of thing that says what ships in what order and who’s doing it, and their team hadn’t kept it current. Nothing unusual about that. Plans go stale when people are busy doing the work the plan describes.

The part I was worried about was what came next. The portal was starting to reach its users, which meant change requests. Small improvements, tweaks, “can it also do this.” Every rollout I’ve been part of gets them, and they’re a good sign. Somebody is using the thing.

I couldn’t make the client call that week, so I sent notes ahead with the one point I cared about most. I wrote it close to this: they can request whatever they want and prioritize whatever they want, but that means a slowdown on the other project. I wanted that said crystal clear before the requests started, not after. Once a request is in flight, the conversation about what it costs sounds like pushback. Before it’s in flight, it’s just the rules of the road.

At our internal standup, one of my colleagues asked when quarterly planning was. She half-apologized for not having checked the calendar herself. Then she handed me the argument I should have already had loaded: “Make your case… this is how many people we have.”

I like that line a lot. It isn’t a lecture on prioritization. It’s one sentence a client sponsor can’t really argue with, because it isn’t an opinion. It’s a headcount. Every request that comes in lands on those people or it doesn’t land at all.

Then our engagement lead reported what the sponsor had signaled. Planning might get skipped this quarter. The view was that it’s not worth the effort, because it’s all going to change.

My colleague’s first reaction was, “Oh, that makes sense.”

And it did. That’s the problem.

Where we almost went wrong

The first reaction in the room was agreement. Not grudging agreement either. It sounded reasonable because it is reasonable on its face: the portal is live, feedback is arriving, whatever we plan now will be wrong before the quarter’s out, so why spend the hours?

What should have stopped us sooner was the doc. The plan everyone depended on had already gone stale. So at the exact moment change requests were about to start arriving, there was no shared place where a trade-off would show up. Skip planning on top of that and a new request doesn’t compete with anything. It just gets absorbed, and the other project quietly slows down, and nobody decided that it should.

To her credit, my colleague turned in the next breath. Sympathy first, then the fix: “maybe we need a short-term triage.” Something for the in-flight projects, so there’s a way to trade things off until planning comes back around. Our engagement lead agreed something had to be in place. So did I. But I want to be clear that we got there on the second thought, not the first.

Why “it will change” is the argument for planning

Here’s the reframe, and I think it’s the part most teams get backwards.

When nothing is changing, you barely need a plan. The work is known, the people are known, you just do it. Planning earns its keep in exactly the quarters when things are moving, because that’s when requests show up faster than anyone can hold them in their head.

A fixed team makes this sharper. If you can add people whenever demand goes up, a new request is mostly a budget conversation. When the team is fixed, every yes has a price, and the price is paid by some other piece of work. The only question is whether anyone sees the price before it’s paid.

Planning is where you see it. That’s all it is, underneath the ceremony. It’s the page where the new request from the portal’s users sits next to the other project’s next milestone, and somebody has to say which one waits. Without that page, both get a yes in two different conversations, and the team finds out they’re over capacity when somebody asks why the other project slipped.

So when a sponsor says planning isn’t worth it because it’s all going to change, I hear something slightly different. I hear that the change is coming and there won’t be anywhere to put it.

We’ve written before about roadmaps that are works of fiction, the plans nobody believes because the dates were picked to end arguments. Skipping planning in a volatile quarter produces the opposite failure and it’s just as bad. There’s no fiction, because there’s no document at all. Every request is priority one at the moment it’s made, and the only thing that decides what actually gets built is who asked last.

What a fixed team does to a yes

I want to slow down on the mechanism, because it’s where the damage hides.

A change request comes in. It’s small. It’s reasonable. Somebody on the delivery team picks it up because saying no to a reasonable small thing feels petty. Nobody logs that it came out of the other project’s time, because there was no plan for it to come out of.

Then another one comes in. Same story.

None of those individual decisions is wrong. The problem is that none of them is a decision. They’re just things that happened. By the time the other project is visibly behind, the cause is a pile of small yeses nobody can point to, and the conversation turns into whose fault it is instead of what to do about it.

This is the cost that makes skipping planning feel free. The effort you save is visible right away. You got a meeting back. The cost shows up weeks later as slippage on work that wasn’t even part of the conversation. By then it looks like a delivery problem, not a planning problem.

It also wears on the team. When the work keeps shifting under people without anyone saying it shifted, they lose any sense of what finishing looks like. I’ve written about how morale problems are usually system problems, and this is one of the quieter ways a system produces them. Nobody decided to overload the team. It just accumulated.

Shrink the ritual, don’t cancel it

My colleague’s triage idea is the right shape, and I’d push it a little further as a general rule. When a planning ritual is under pressure, the answer is usually to make it smaller, not to drop it.

A full quarterly plan might genuinely be too much in a quarter where the ground is moving. Fine. What you can’t drop is the part that does the work: a short, regular moment where in-flight requests get put next to each other and somebody with authority says which one moves and which one waits. That’s the triage. It doesn’t need a deck. It needs the list, the headcount, and a decision.

The sentence in my notes to the client was meant to set that up in advance. They can have anything they want. It’ll cost them time on the other project. Say it before the requests start and it’s a rule everyone agreed to. Say it after and it sounds like a vendor making excuses.

Who’d push back

I know who’d argue with this. There’s a camp in product and delivery circles that says heavy upfront planning is waste when conditions are volatile, and that the right move is to stay light, respond to what’s in front of you, and let the backlog sort itself out. They’d look at a live rollout collecting user feedback and say that’s exactly when a quarterly plan is least useful.

I think they’re half right. A detailed quarterly plan in a volatile quarter will be wrong, and spending days on it would be a bad trade. Where I part ways is the idea that the answer is no plan at all. On a team you can’t grow, “respond to what’s in front of you” means responding to whatever arrived most recently, at the expense of whatever’s been waiting longest. Staying light is fine. Staying blind isn’t.

The question nobody asked

Here’s the one I’d put to any sponsor who wants to skip planning this quarter: if we don’t plan, where does a new request go to compete with the work it will displace?

It doesn’t get asked because skipping planning feels like saving effort, and the bill for it arrives weeks later on a different project. If there’s no good answer, you don’t have a planning problem yet. You have a place for trade-offs that doesn’t exist, and a team that’s about to find out the hard way.