The Hidden Cost of Quarterly Planning

You know that feeling in March, when your engineering teams are scrambling to jam everything into Q1 before the arbitrary deadline hits? Someone suggests we split a feature in half, not because it makes any product sense, but because March 31st is coming and we need to "show progress" on the quarterly roadmap. We can “finish” the second half of the feature in Q2- right?

I've been in that meeting. You've probably been in that meeting. But it’s not planning, and worse, it’s not helping you deliver value any faster. And to top it all off  it's costing you way more than you think.

When the Calendar Drives Your Decisions

Quarterly planning gives us a false sense of confidence. It feels structured. Responsible. Leadership loves the “predictability” of knowing what's happening in Q2, Q3, and Q4. But let me tell you what actually happens.

You sit down in October and plan work for a January start. You make assumptions. You scope initiatives. You get everyone aligned. Then January rolls around and guess what? The market shifted. Customer priorities changed. Half the assumptions you made three months ago are already outdated. That initiative you carefully scoped back in the fall? It's requirements already need rewritten. Now your teams are executing work that matters less than it did when you planned it, but you're committed because it's "on the roadmap."

The risk in this process grows because you’re making decisions about what to start based on a calendar date instead of asking the more important question: does our system actually have capacity to do this work right now?

The quarter starts. Like clockwork, you inject a predetermined amount of work into your portfolio. It doesn't matter if teams finished what they started last quarter. It doesn't matter if dependencies are resolved. It doesn't matter if anyone actually has the bandwidth to do this well. The calendar said it's time, so here comes the work.

What happens next? Your portfolio work in progress balloons. Initiatives pile up in various states of partial completion. Everyone is busy, but nothing is finishing. Cycle times stretch from weeks to months. Your teams are context switching between five partially started initiatives instead of focusing flow toward completion.

Another hidden risk in this cycle comes in the form of attempting to same size work to fit planning cycles. You have an initiative that would take four months to deliver as something coherent and valuable. But you need to fit it into a three month window. So you artificially chop it up, not along natural product boundaries that would let you validate assumptions and get feedback sooner, but along arbitrary timeline boundaries. You end up with pieces that don't deliver value independently, that can't be tested meaningfully with customers, and that create handoff dependencies between quarters.

You've optimized for quarterly reporting instead of optimizing for learning and value delivery.

What Happens When Capacity Drives the System

In a pull based portfolio kanban system, work doesn't enter your active portfolio because it's the start of a quarter. It enters because something finished. Any time an initiative reaches done (truly done, shipped to customers, validated) it creates capacity. That capacity creates a pull signal. And that pull signal triggers planning activities needed to prepare the next most important thing to start.

There are many benefits to what we call “just-in-time” planning.. You're planning work closer to when it will actually be executed. The assumptions you're making are fresh. The market context is current. Customer feedback from recently shipped work can inform what you start next. You're not executing against a stale roadmap. You're continuously adapting based on real information about what's working and what isn't.

And because you're managing work in progress at the portfolio level, you maintain flow. Teams can focus. Initiatives move from start to finish without getting stuck in that dreaded "almost done" state for months. Your system's throughput becomes more predictable because you're working within your actual capacity instead of constantly overloading it with calendar based commitments.

The planning itself changes too. You're not running those exhausting quarterly planning sessions where you try to sequence and scope twenty initiatives at once. Instead, you're running smaller, more frequent planning sessions focused on the two or three things that are actually about to start. The cognitive load is manageable. The decisions are better informed. And the plans actually survive contact with reality.

Where to Actually Start

Moving from quarterly planning to continuous flow isn't something you do overnight. It requires changing how you visualize your portfolio work, how you limit work in progress at that level, and how you create clear triggers for when planning should happen. 

1. Make Your Portfolio Workflow Visible

You can't manage flow you can't see. I know that sounds obvious. But most organizations have completely invisible portfolio workflows with many assumptions about the policies that govern that workflow.

You probably have some version of this workflow, even if you don't name it. Discovery feeds into Definition. Definition feeds into Delivery. Delivery feeds into Validation. But these stages are invisible at the portfolio level, which means you can't see where work is actually stuck or how much work is piling up in each stage.

Start by creating a portfolio board that shows every active initiative and where it sits in your workflow. Not just the stuff in delivery. Everything. The initiatives you're still exploring. The ones that are defined and waiting for capacity. The ones currently being delivered. The ones you've shipped but are still validating with customers. This gives you a complete picture of your portfolio work in progress across all stages.

Fair warning: this visualization is going to reveal uncomfortable truths. You'll probably discover you have thirty initiatives in some state of active work when you thought you had twelve. You'll see initiatives that have been sitting in "definition" for four months waiting for someone to have time to start them. You'll notice that most of your validation work isn't actually happening because things ship and immediately get forgotten as everyone moves on to the next thing.

But making this visible is the only way to start managing it deliberately. Once you can see the flow (or the lack of flow), you can start asking better questions about where the system is constrained and what to do about it.

I worked with a leadership team last year that resisted this step for weeks. "We know what's in flight," they kept saying. When we finally got everything on a board, they counted fifty seven active initiatives for a portfolio with three delivery teams. Fifty seven. They sat there staring at it for a solid minute before someone said, "Well, that explains why nothing is finishing."

2. Limit Your Portfolio WIP

Here's the hard part. Once you can see all that work in flight, you need to limit it.

This is where organizations struggle the most, because limiting work in progress at the portfolio level means saying no to starting new things. Even when there's pressure from stakeholders. Even when you have available people. Even when it's the start of a new quarter and you're "supposed" to kick off the next batch of work.

The principle is straightforward: you should only have as much work as you have the capacity to actively be working. The reality of modern product development is that most initiatives require coordination across multiple teams which often means they share capacity. When you have more initiatives than teams, you guarantee that teams will be context switching between multiple efforts, that dependencies will create waiting time, and that nothing will finish as quickly as it could.

Start by setting a work in progress limit for each stage of your workflow. I would caution against letting the number of delivery teams or programs dictate the amount of work happening upstream. You’ll need to understand the capacity your portfolio has for every activity before delivery starts. The most important thing is to pick a number, stick to it, and measure the results with portfolio flow metrics.

Limiting work will immediately surface priority questions: which five things matter most right now? Which ones should wait until something finishes? These are the conversations you should be having anyway, but the WIP limit forces them to happen.

Many organizations focus solely on limiting WIP for the delivery teams but in order to create pull and “just-in-time” planning, you also need WIP limits in your upstream stages. How many things should be in active definition work? How many in discovery? These limits keep you from building up a massive queue of planned work that ages and becomes less relevant. They force you to do planning work just in time rather than building elaborate roadmaps full of stale assumptions.

These limits will feel uncomfortable. People will want to start things because they're excited, because stakeholders are asking, because a team (or part of a team)is available. But the discipline of limiting WIP is what creates flow. It's what keeps initiatives moving through the system instead of getting stuck in partial completion limbo.

3. Create Clear Triggers for When to Plan

The shift from quarterly planning to continuous planning requires answering a new question: when should we start planning the next thing?

In a quarterly model, the answer is easy. You plan everything at once, at the start of the quarter. In a continuous model, you need explicit triggers that tell you when to initiate planning activities.

The most important trigger is capacity. When an initiative reaches "done" in delivery, that creates capacity and triggers the question: what should we start next? If you have eighty things sitting in your backlog, that question becomes impossible to answer quickly. You'll spend days debating priorities, relitigating decisions, and trying to figure out what matters most right now.

This is why keeping your upstream queues small and current reduces that churn. You want just enough defined and ready work that when capacity opens up, the next priority is obvious. Not because someone made a decision three months ago, but because you've been continuously refining and clarifying what matters most as you learn so you can pull the next topic into definition only when you're about to need it.

These triggers create a rhythm of planning activities that's responsive to your actual capacity rather than driven by the calendar. Your discovery team isn't running discovery on twelve things at once because it's Q2. They're running discovery on the two or three things that are next in line to be defined, and they pull in the next topic when one moves forward. Your product managers aren't trying to write detailed specs for twenty initiatives. They're deeply focused on defining the few things that are about to start, and they pull in the next thing when capacity opens up.

Building Continuous Flow into Your Portfolio

The transformation here isn't really about planning cycles or workflow visualization or WIP limits. Those are the mechanics. The deeper shift is from a commitment based model to a capacity based model of portfolio management.

In a commitment based model, you commit to outcomes based on upfront planning and ideal assumptions. You say "in Q2 we will deliver these five things" and then you try to force reality to match that commitment, regardless of what you learn along the way, regardless of what actually happens It's painful for everyone involved. People working nights and weekends. Quality suffering. Morale tanking. All to hit commitments that were based on incomplete information from three months ago.

In a capacity based model, you acknowledge your system's actual capability and work within it. You say "our system can handle three concurrent initiatives effectively, so we'll start these three things, and when one finishes we'll start the next most important thing." You're committing to maintaining a healthy flow through your system rather than committing to a specific predetermined set of outcomes.

This shift makes some stakeholders nervous. It feels less certain, less predictable. But here's the truth I wish more leaders understood, quarterly roadmaps never delivered the certainty they promised. They just created the illusion of certainty while your teams scrambled to deliver against commitments made with incomplete information.

Continuous flow replaces false certainty with honest transparency about what your system can actually absorb and deliver. And in practice, continuous flow systems are consistently more predictable. When you limit WIP and maintain focus, initiatives move faster. Your delivery times become more stable. You can make reasonable forecasts about how much work your portfolio can handle over the next several months, even if you're not specifying exactly which work until closer to start time.

The organizations that make this shift successfully don't do it because they've solved all their planning problems. They do it because they've gotten honest about the cost of calendar driven planning and they're willing to trade the false certainty of the quarterly roadmap for continuous flow of value in a pull based portfolio system.

‍