Insight
What a missed baseline actually tells you
A second missed date is rarely an estimating problem.
Forward Leaning Consulting
Every large programme misses something. The interesting question is not whether a date moves but what the organisation learns when it does, and most organisations learn the wrong thing.
The common reading of a missed baseline is that the estimate was optimistic. That reading is comfortable, because it implicates nobody in particular and its remedy is arithmetic: add contingency, re-plan, move on. It is also usually wrong.
A first slip tells you the plan was wrong. A second slip tells you the reporting is.
By the time a programme misses a second baseline, the plan has already been rebuilt once with full knowledge of why the first one failed. If it fails again in the same way, the failure is not in the estimate. It is that the information reaching the people who approved the new plan did not describe the work accurately enough for them to approve a realistic one.
How reporting separates from work
This separation is almost never dishonest. It is structural, and it happens through a sequence that is recognisable across sectors.
A workstream lead knows their area is three weeks behind. They also know they have a credible plan to recover two of those weeks, and that raising a red flag will trigger a review that costs them a week. So they report amber with a recovery plan. Every individual judgement in that chain is defensible. Thirty of them, aggregated weekly, produce a status report that is green at the top and untrue at the bottom.
The mechanism is not people hiding problems. It is that the reporting line asks each person to summarise, and summarising is where information is destroyed. By the third level of aggregation the specific fact that would have changed a decision - a single integration dependency, a data volume nobody has tested against, a vendor resource who left in March - has been compressed into a colour.
Three things worth checking
Before accepting any programme's status at face value, three questions tend to be more diagnostic than a review of the plan.
Who last changed a status from green to red, and what happened to them? If nobody can name an instance, the reporting is decorative. Organisations learn very quickly whether raising a flag is rewarded or punished, and they do not need to be told explicitly.
What has actually been tested end to end, as opposed to built? Build progress is easy to report and easy to over-report, because a component that is ninety per cent complete looks identical to one that is complete until something depends on it. Integration and end-to-end testing are where a programme discovers what it actually has.
Would the people who have to deliver the date put their own name to it? Not whether they have agreed to it in a meeting, which measures organisational pressure rather than belief. Whether they would write it down.
Why this matters commercially
A reset that produces a plan nobody believes is worse than no reset at all. It consumes the credibility that the next attempt will need, and credibility with a board is not renewable at the same rate it is spent. The second reset is materially harder to get approved than the first, and the third generally is not approved at all - at that point the conversation changes from how to recover the programme to whether to continue it.
Which is the practical argument for treating a first missed baseline seriously rather than absorbing it. It is the cheapest point at which the gap between the reporting and the work can be closed, and it is the last point at which closing it is a management exercise rather than a governance crisis.
Forward Leaning Consulting directs enterprise transformation programmes, and is most often engaged where one has missed a baseline or is about to set one. How we work →