Planning is the only phase of a program that cannot slip. There is no baseline yet, so there is nothing to be late against. The instrument that measures lateness is the thing being built. That mechanism is most of the reason the front end takes as long as it does.
A client program lead put the question to us plainly. How many rounds of schedule building should a team do before publishing the schedule more widely? His own read was that once the macro schedule runs start to finish and the core team has scrubbed it once or twice, publish it and let the weekly refresh take over. He wanted to know how much iteration belongs in front of that.
The answer is a clock, not a count of rounds. One to two weeks to build the macro plan. Two scrubs with the core team. Four weeks from the first planning meeting to a signed baseline, with the outside partners in the room from day one. Publish at four weeks. It will not feel finished. It will not feel finished at eight weeks either, and by then you will have paid a month for the same feeling.
Why the eighth week is worse than the fourth
More planning time does not buy more information. It buys more processing of the same information.
The unknowns that make an early schedule uncertain are mostly not the kind that yield to discussion. How long the first debug cycle runs, whether the supplier’s sample meets spec, how many turns the design needs: none of that is sitting in a room waiting to be talked out. It is sitting in the work. You learn it by running the first learning cycle, and you cannot start that until there is a plan to run it against.
So the team that spends eight weeks planning instead of four buys itself a more accurate description of a launch that is now four weeks later. The precision went up. The date went down. That is exactly wrong in the plainest sense: a sharper number attached to a worse outcome.
Colin Powell’s formula was P equals 40 to 70, where P is the probability of success and the numbers are the percentage of the information you hold. Below 40 you are guessing. Past 70 the calendar has decided for you. On the advanced development programs we work on, the point where the forecast becomes predictive lands near 40 percent, which is usually two to three months in and well after the baseline is snapped. Predictive comes later, and it comes because the baseline came first.
Dr. Michael Ryan, Executive Director of the World Health Organization Health Emergencies Programme, put it in one line at a briefing in March 2020: if you need to be right before you move, you will never win.
The clock nobody starts
Executives miss this one, and it is not their fault. The number does not exist anywhere in the company.
A four-week milestone slip in month nine sets off a recovery plan, a schedule review, and a call with the customer. Four extra weeks spent perfecting a plan in month one costs the launch date the same four weeks and sets off nothing. No meeting. No metric. No line on a budget. The two are identical in effect and opposite in visibility.
At a cost of delay of $100k a day, four extra weeks of planning is $2m. Nobody reports it, because there is no baseline yet to report it against.
This is what better to be roughly right than exactly wrong means once you move it off the estimate and onto the calendar. The exactly wrong answer is not a bad number in the schedule. It is the decision to keep working on the number.
The executive who wants it perfect and wants it now
Most of the pressure to over-plan comes from the top, and it arrives disguised as its opposite.
The CEO says two things in the same meeting. I want this right. I want this now. The organization can only act on one of them, so it acts on the one that carries the punishment. Being late is survivable and it is shared across a team. Being wrong is personal, and it is remembered. So people spend their time not being wrong. They build careful, defensible plans, slowly, and the care is rewarded right up until the date arrives.
The executive reads the slowness as a lack of urgency and pushes harder on rigor, which makes the next plan slower still.
You cannot talk an organization out of caution. You can give caution a deadline. A date on the planning work is the only move we have found that reaches the reflex, because it makes slow a way of being wrong.
What the four weeks contain
Day one. The core team is in the room and so is every organization that owns work on the critical path. The macro plan gets built that same week, top down, about fifty activities that describe the whole program from start to finish. A cross-functional team does this in three to four hours, not three weeks. Most companies’ programs resemble each other closely enough that a template gets you to a first draft in an afternoon.
Week two. First scrub. The near-term work comes down to tasks of one to five days. Everything past a few weeks stays coarse on purpose, because detail out there is fiction you will pay to maintain.
Week three. Second scrub. The critical path now runs unbroken end to end, the learning cycles are in it at honest durations, and the big risks show up as tasks or as duration instead of as a footnote. The gap to the target falls out of the arithmetic, and it is usually unwelcome.
Week four. The target is set, the baseline is snapped, the schedule is published, and the people in the room sign up to it. The weekly refresh starts the following Monday, which is where the plan turns into what people actually do on Monday.
The act of building the plan is what makes it work. Drawing a continuous line from today to launch forces the unknowns into the open, because you cannot draw a line through a question nobody has asked. That is most of the value of the exercise, and you get it in week one.
What signing looks like
The largest program we have run this way was a semiconductor fab in China, roughly $10 billion of capital. The macro plan for it fit on one sheet. It was printed poster size and hung on a wall.
At the end of the planning window, the room signed it. The core team, the equipment suppliers, the construction organization, the process owners, and the executive responsible for worldwide manufacturing. Dozens of signatures across a printed schedule. Someone wrote “Yes! We Can!” across the top of it.
Nothing in that schedule became more accurate when they signed it. A team will strive to beat its own schedule and will rarely beat somebody else’s, and a plan that arrives finished from a program office is always somebody else’s.
The signature does not make the schedule right. It makes it theirs.
The scale is the other half of the argument. A fab at that number came down to about fifty activities on one wall. If that fits on a sheet, the objection that your program is too complex to plan in four weeks is not really about complexity.
Bring the outside in on day one
Any organization that owns critical path work and does not sit in your building is a partner: a contract manufacturer, a design house, a test facility, a division in another country, an internal group with its own queue.
If they arrive in week three you have two options and both are bad. Baseline without them, and you have signed a plan containing their dates that they never agreed to. That is a slip you built in deliberately, and it surfaces the first time they read the schedule. Or wait for them, and the clock is gone.
A schedule that contains someone else’s dates without their agreement is not a schedule. It is a request.
Distance on the org chart costs what distance in miles costs. The team two floors up in another division is as external as a partner ten time zones away, and often harder to get into the room, because no contract obliges them to show up.
What you lock, and what you leave loose
The baseline locks three things and nothing else.
The target. Where it comes from is a separate question with a hard answer: outside the team, and never from your own schedule.
The milestone names. This is the cheapest fix available in week two and one of the most expensive in month six. Pick the two or three milestones every program in the portfolio will track, name them once, and put those names in the first schedule you baseline. Then copy them into the others. After baseline each program has its own vocabulary, and every rollup becomes a translation exercise that never ends.
The first point of the trend. That is the whole of it.
Everything else stays loose: the task detail past a few weeks, the durations that depend on learning you have not done, the second and third critical paths that will reorder themselves by month three. A baseline is not a promise about the schedule. It is a mark on a ruler.
The baseline is not the promise
Much of the fear around baselining comes from collapsing two different acts into one.
The baseline is internal. It is the team’s honest read, snapped at week four, so the gap exists and the trend has a first point. The outward commitment to a customer or a board is a different act with a different audience, and it belongs at two to three months, once the trend has stabilized and the forecast has earned the right to be repeated outside the building.
Teams that treat the baseline as the external promise will not sign one at four weeks, and they are correct not to. Separate the two and the fear goes away.
Good enough is a second scrub that does not move the gap
Teams ask how they will know the plan is good enough to publish. It is not a feeling, and waiting for the feeling is what costs the month. There is a test.
Compute the gap after the first scrub. Compute it again after the second. If the gap moved by about a week, the third scrub will move it by a day, and you are converged. Snap the baseline.
If the second scrub moved the gap by two months, do not book a third. Stop and look past the schedule. Something structural is wrong: the target, the scope, the resourcing, the technology. That is a conversation worth having in week three of a program, while redefining the project, challenging the assumptions behind it or killing it is still cheap.
Alongside the gap test, the plan is publishable when the critical path runs unbroken from today to the target with no hand-typed dates, every critical path task has an owner who has seen it, the organizations that own the work have been in the room, and the learning cycles sit in the plan at durations the team will defend.
None of those criteria is accuracy. The schedule will be wrong. It is supposed to be wrong, and then less wrong every week.
The trend you give up by waiting
The baseline’s job is not to be right. Its job is to be first.
A single forecast tells you very little. Six weeks of forecasts tells you whether the program is closing on the target or running away from it, and that trend is the most useful number a leadership team has. It cannot exist without a first point.
Snap the baseline at week four and by month four you are reading twelve weeks of trend. Snap it at week ten and you have six weeks of trend and a launch date six weeks worse. The late baseline is more defensible on the day it is published and blinder every week after.
Waiting for enough information to build a good baseline gives up the mechanism that makes baselines good.
When you do not need the clock
We do not normally push artificial deadlines onto planning. A team that already moves does not need one, and four weeks is not a law of physics.
It is a countermeasure to a specific condition, and you can see the condition from across the room: careful people producing careful work slowly, a lot of review, a lot of preparation aimed at not being wrong, and nobody able to say what the planning phase is costing. Where that is the culture, the clock is the treatment. The executive who wanted it perfect will like how aggressive it looks, which is its own small irony.
The clock also barely scales. A six-month derivative and a three-year platform both get a macro plan in one to two weeks and a baseline in four. What changes between them is the number of learning cycles inside the plan, not the time it takes to draw one.
Put a clock on the planning and it stops being the one phase that cannot slip.
That is the point of the four weeks. They are not a planning budget. They are the first date the program is asked to hit, and a team that cannot hit the date it set for its own plan is telling you something useful about every date that comes after it.
Downloads
Related reading: From unknown to kind of known, Start with a macro plan, It is better to be roughly right than exactly wrong, Where targets come from, Schedule gap, My schedule keeps slipping, Manage the fuzzy front end, Targets and trends.