Start a Quarter Plan in 2026: The Simple Plan (and the Fatal Mistake)

Most organizations aren't short on projects. They're short on things they're willing to give up. The portfolio swells, teams burn out juggling it all, and no one ever really says no — because saying no takes a big-picture view that no one has. The Quarter Plan isn't a project-management method. It's a discipline of trade-offs. It starts with one simple question: if we can only do ten things this quarter, which ten?

The 4 entry points depending on your context

A — CEO + CFO + CIO: protect the business The warning sign is the leadership meeting where no one knows exactly how many projects are underway, nor what they truly cost in human effort. The CFO sees budgets slipping without understanding why. The CIO is stuck with last-minute trade-offs because leadership has no consolidated view. Here, the Quarter Plan isn't an IT tool — it's a financial and strategic steering instrument. It answers a single question: can we deliver what we promised this quarter, yes or no, and at what real cost?

B — CIO alone: rebuild credibility IT delivers. But no one knows it. The business sees delays, postponements, "it's in progress" with no date. The problem isn't technical — it's about visibility. Here the Quarter Plan becomes a communication tool as much as a steering tool: it makes visible what's being done, what's blocked and by whom, what was decided and by whom. When a project slips, the CIO can point to the decision that caused the slip — and the meeting where it was made. That's what credibility is: not "we're doing our best," but "here's what we decided, and here's what it produced."

C — CEO: the 20% of projects that create 80% of the value Most project portfolios suffer from silent inflation: every department has its emergencies, every director has their priorities, and the list keeps growing without ever really being pruned. The CEO who starts with the Quarter Plan isn't after completeness — they're after alignment. Which are the 20 projects that, if they land this quarter, genuinely change something for the business? The rest isn't cancelled, it's put on explicit hold. The difference is huge: a project on deliberate hold doesn't consume mental bandwidth.

D — Constrained teams: start from the bottlenecks In any organization, there are two or three teams that are on every project at once. The data team. The architects. The integrators. The ones without whom nothing ships. The problem isn't that they're overloaded — it's that we know it and keep piling projects onto them without ever looking at what that produces at the bottom of the stack.

The right starting point is to identify these bottleneck teams first. Then to list the projects that draw on them constantly — not the most visible projects, not the most expensive, but the ones that consume the most of their capacity on a recurring basis. Those are the projects to prioritize, sequence, or sometimes simply stop. Not because they're strategically top priority — but because as long as they clog the bottleneck, nothing else can get through.

Here the Quarter Plan starts with a simple question: which five projects are saturating our critical teams this quarter? The answer to that question says more about the reality of the portfolio than any progress report.

The real launch plan: 5 steps before the big day

Step 1 — The project brief, accelerated by AI You start from a given scope: the projects flagged as priorities by the CEO or the CIO. For each one, AI generates a structured brief from even a vague description — context, objectives, constraints, assumptions. It's not a perfect brief. It's a brief good enough to get everyone aligned on what we're planning. The project owner validates it, amends it, signs off. On to the next.

Step 2 — Defining the skill groups The PMO or the CIO structures teams not by org chart, but by homogeneous skill groups: back-end development, integration, data, infrastructure, business steering, and so on. That's the level of granularity that matters for planning — not divisions, not business units. A project consumes skills, not boxes on an org chart.

Step 3 — Breaking work into deliverables per team For each briefed project, AI proposes a breakdown into deliverables assigned by skill group. Which deliverable? For which team? In what order? This breakdown is then handed to the team lead to be challenged. Not to be rubber-stamped in a plenary meeting — to be corrected by the people who actually know how the work gets done. That's the difference between a theoretical plan and a plan that holds up.

Step 4 — The estimate, challenged twice AI produces a first estimate in person-days per deliverable, per team. A ballpark — not a to-the-detail costing. This estimate is sent to the team leads for a first pass, then to the teams themselves for a second. The goal isn't consensus — it's to surface the points of friction before the big day, not during it.

Step 5 — Real capacity: subtract the day-to-day Each team calculates its real capacity available for projects this quarter. Not theoretical capacity — net capacity, once the day-to-day is subtracted: support tickets, maintenance, recurring meetings, time off, training. It's often the first time a team does this calculation explicitly. The result is invariably lower than everyone imagined.

The big day — the half-day of truth You bring together the team leads, the PMO, the CIO, and if possible a CEO-level sponsor. You lay the projected workload and the real capacity side by side. And there, invariably, you discover that a third of the teams are already at 180% before you've even added this quarter's projects. Not because the teams are bad. Not because the projects are poorly estimated. Because it's the first time everyone looks reality in the face, together, with the same numbers in front of them.

That's the moment that changes everything. Not the governance, not the configuration, not the reporting. The half-day when someone finally says: "we can't do everything, so what do we decide?"

The fatal mistake: Excel + PowerPoint

Excel and PPT kill the Quarter Plan over the medium term — not because they're useless, but because they go stale instantly, demand constant manual consolidation, and turn steering into slide production.

The symptom: the week before the monthly review, someone spends two days "updating the file." That time isn't steering — it's data entry. And meanwhile, the decisions wait.

The deeper problem is worse still: a spreadsheet doesn't answer the question "who decided what, when, and on what basis?" When a project goes off the rails six months later, no one can find the context. The decision that caused the slip is nowhere to be found, and therefore indefensible. The Quarter Plan must be alive — reliable real-time data, traceable decisions, a consultable history. That's the difference between a reporting tool and a steering tool.

Where AI really helps (no bullshit)

AI isn't there to steer for you. It's there to shorten the time between the request and the deliverable — and between the deliverable and the decision.

Concretely: turning a vague request into a structured brief in thirty seconds. Breaking a project into actionable deliverables per team without a two-hour workshop. Producing a usable ballpark estimate — 80% of the time, that's enough to make the call. Spotting inconsistencies and hidden dependencies before they surface in committee. Preparing two comparable scenarios in under ten minutes.

The real gain isn't in generating content. It's in the speed of getting to a decision — and in the quality of the trade-offs when the right information arrives at the right moment, rather than a week too late.

You can have the best strategy in the world. Without cadence, without a capacity view, without a formalized quarterly trade-off, your strategy stays a document. It inspires, it sets a direction, it reassures the shareholders — but it steers nothing.

The Quarter Plan is the minimal system for making your decisions hold up over time. For making your team know what it's doing this quarter, why, in what order, and what we consciously decided not to do. Not because it doesn't matter — but because capacity is finite, and owning that is the only way to stay credible.

That's how trust is built.

This article first appeared in my LinkedIn newsletter Il était une fois un CODIR, where every two weeks I share real situations from the executive committee.