Why digital programmes fail before anything goes wrong

Programmes that end badly tend to start well. For the first stretch the status reports are green, the team is busy, and the milestones land on time. Then, somewhere in the middle, the picture turns — dates slip, the reports settle on amber and stay there. Trace the cause back and it is not in the middle, where the trouble surfaced. It is at the very start, in a decision taken while everything still looked fine.

This is what makes a digital programme hard to govern. The period when its outcome is decided and the period when the trouble becomes visible are not the same period. By the time a problem shows on a report, its cause is months behind you — and a decision that old is expensive to change.

A CEO judges a programme by its signals: milestones hit, team busy, report green. Early on, those signals are blind. Discovery, hiring, the roadmap sign-off — real work, all of it, and all of it on time, because none of it is hard yet. Nothing is late because nothing is due. The report reads green not because the programme is sound, but because nothing has happened that could turn it amber.

Underneath that calm, the structure of the programme is being set. Three decisions in particular will decide whether it works — and all three are being made now, while every signal you have shows nothing wrong.

The first is how success is defined. Ask a programme what it is trying to achieve early on and you will hear about activity: the platform chosen, the team hired, the discovery phase completed. These are real, and they feel like progress. None of them is an outcome. A programme can deliver every one of them on time and still change nothing in the business — which is the thing it was funded to do. Activity is what you can guarantee. An outcome is what you were paying for. When the first stands in for the second, the gap stays hidden until something later depends on it.

The second is ownership. When a programme is measured by activity, no one in particular has to own it, because there is no single result anyone answers for — only a plan to run. The work spreads across functions, each holding its piece, none holding the whole. This looks like collaboration. It is a vacuum. The first time something goes wrong between two functions — and that is where things go wrong — there is no one whose job it is to resolve it. Everyone is busy. No one is in charge. In week three it does not feel like a problem. It already is one.

The third is mandate. Suppose there is an owner. The early phase still will not tell you whether that person can act. A programme worth funding will eventually ask the business to change — to give up a process, to alter a system another department depends on, to drop a way of working older than the programme itself. If the owner holds the task but not the authority to force those changes, the programme stalls at the exact point where it starts to matter. Until then it runs smoothly, because nothing it has done so far requires anyone to give anything up.

None of the three looks like a fault while it is being made. Measuring activity looks rigorous. Spreading ownership looks inclusive. Handing over a task without full authority looks like ordinary delegation. Each turns into a fault only under load — and the early phase applies none. That is the trap in one sentence: the programme feels healthiest at the precise moment its outcome is being set.

This inverts the instinct most CEOs run on. You scrutinise what looks troubled and trust what looks fine. At the start of a programme, that instinct points the wrong way. “Looks fine” tells you nothing here, because nothing has been tested. The absence of bad news is not evidence that the programme is sound. It is evidence that the part which produces bad news has not happened yet.

So you cannot wait for a warning. No warning will arrive while the structure is still cheap to change. The only way to know whether it is sound is to test it directly — now, by asking the questions that nothing yet forces you to ask. Three of them do most of the work:

1. What will be different in the business when this is finished — not what will be built, but what will be different — and how will you know?
2. Who owns that outcome, by name? And do they have the authority to change how other parts of the organisation work when the programme needs them to?
3. When the programme runs into something the business will not willingly give up, who decides — and does that person already know it is their job?

If the answers are clear, the trap is mostly avoided. If they are vague — if success is a list of things to be built, if ownership turns out to be everyone and therefore no one, if the question of authority produces a pause — the faults are already in place. They will surface later, as the slipped dates and the reports stuck on amber. By then their cause is months old and costly to undo. Which is why these questions cannot wait for a reason to ask them. In a programme this young, the absence of a reason is the reason.