Execution and delivery
Five Early Signs That a Program Is Slipping
Large programs rarely fall behind overnight. A delay is usually preceded by small warnings that, taken one at a time, look minor. A date that moves, a report that sounds a little too cheerful, a person who starts missing meetings. Each sign has an easy explanation. Together, they tell a different story.
Spotting them early does not guarantee avoiding the delay, but it gives something very valuable: room to decide calmly instead of reacting in a rush when time has run out.
How to use this list
The signs below are not a diagnosis, and none of them alone proves a program is in trouble. They are questions to bring to the review meeting. If several keep showing up in the same program, it is worth stopping to look more closely.
Sign one: dates move, but deliverables stay the same
When a milestone shifts once, there may be a specific reason. When it shifts several times without any change in what is promised, something in the planning or in the team's capacity is not working.
A useful question is what exactly will be delivered on the new date, and what has changed since the last one to make it possible now. If the answer is vague, the new date probably will not hold either.
Sign two: the report says "green" and nobody can explain why
Status dashboards are useful, but they can also hide things. A green indicator with no concrete explanation often means nobody has checked the detail, or that reporting green is more comfortable than reporting anything else.
It helps to ask for examples: what was finished this week, what is still at risk and what depends on others. A healthy status can be described with facts. A doubtful one is described with adjectives.
Sign three: an outside dependency has gone weeks without an answer
Every large program depends on other teams, suppliers, authorities or customers. When one of those dependencies goes unanswered, risk grows quietly, because the team does not control how it ends.
An open dependency deserves an owner, a deadline and a fallback plan. If none of those exist, the program is waiting without knowing it.
Sign four: the same people are stretched across too many tasks
When a few people hold the key knowledge, they become bottlenecks. An overloaded person answers later, makes more mistakes and may eventually leave the project.
This sign shows up in calendars, in unanswered emails and in the tiredness of the team. It is among the easiest to ignore because, on the surface, everything still moves forward thanks to those same people.
Sign five: bad news arrives later and later
This is the hardest to see, because it depends on whether the team feels safe enough to speak up. When reporting a problem feels like a personal risk, problems stay hidden until they can no longer be hidden.
A good indicator is how much time passes between something going wrong and the leader finding out. If that gap is growing, it is worth asking what reaction teams have learned to expect when they bring a problem forward.
An example
What follows is an invented example to illustrate the list. It does not describe a real program.
A modernization program reports an overall green status for several months. In review meetings, milestones slip a little each time. A dependency on an outside supplier remains unanswered, and two team members hold nearly all the technical decisions. One day, someone mentions in passing that a problem had been known for weeks.
None of these signs was serious on its own. Together, they showed a program that relied on luck more than on a plan.
What to do when a sign appears
Spotting is not the same as acting, and some responses help more than others:
- Ask before concluding. A sign is an invitation to talk, not an accusation.
- Make the risk visible. Log it, give it an owner and set a date to review it.
- Adjust the plan honestly. It is better to admit a realistic new date than to hold on to one nobody believes.
- Protect whoever raises the alarm. A person who brings bad news in time is helping the program, and should feel that.
A short, regular review
No audit is needed to keep watch on these signs. A few minutes in each review meeting is enough, always in the same order. Regularity matters more than depth: a list checked every week catches changes that a long review, done once a quarter, lets slip by.
Closing thought
A delay is rarely a surprise to the team. It tends to be a surprise to those who had no way of finding out. Creating the conditions in which signs are seen, named and acted on is among the most useful tasks of anyone leading a program.
What other early sign have you learned to watch for when a program gets complicated?
