The problem is rarely a lack of reporting

A programme in drift usually produces a great deal of information and very few decisions. Dashboards exist and meetings fill the calendar, yet nobody can connect a priority to an owner, a date, and evidence of delivery. The organisation can see activity. It can no longer see the trajectory.

The first instinct is often to add control. A new committee asks for new indicators, which require more tools and preparation. Governance becomes more precise about the past without making the next choice clearer. Recovery requires the opposite move: reduce the number of variables until the decision chain becomes short enough to operate.

Start with one operational truth

Before discussing architecture or methods, name the result the service must be able to produce within ninety days. This is not a completed phase or a percentage. It is an outcome that can be observed by a user, an operator, or a service team.

That statement immediately separates work into three groups:

1. work that directly contributes to the outcome;
2. work that protects a real constraint such as security or continuity;
3. work that exists because the programme has become accustomed to producing it.

The third group is not necessarily useless. It simply needs to become a deliberate choice again rather than an unquestioned obligation.

Map only the dependencies that can stop delivery

A useful map does not aim to be exhaustive. It shows dependencies capable of stopping the outcome: a legal decision, missing data, an environment that cannot be reproduced, an interface owned by a third party, or a role with no accountable person.

Every dependency needs an owner, a decision date, and a fallback. If one of those is missing, the dependency is not being managed. It is merely known.

The exercise must allow disagreement. Product, engineering, operations, and domain teams see different risks. That disagreement is useful information when it becomes a set of testable assumptions instead of a permanent political negotiation.

Replace declared progress with evidence

A work package reported as 80 percent complete can remain blocked for six months. Binary evidence is less comfortable but more useful: the journey works in a representative environment, the data reconciles, rollback has been exercised, or the receiving team can operate the service.

Evidence should remain proportionate. Recovery does not require immediate industrialisation of everything. It requires one end-to-end path real enough to expose the interfaces, responsibilities, and costs hidden by the programme structure.

Six decisions that alter the trajectory

1. Name the operational result expected within ninety days.
2. Map only the dependencies capable of blocking it.
3. Give every hard-to-reverse decision a named owner.
4. Replace progress percentages with executable evidence.
5. Isolate one complete path from input to operation.
6. Record rejected trade-offs as clearly as accepted ones.

These decisions create a common language. They also reveal whether the programme is missing capacity, authority, or clarity. Those problems may look similar in a dashboard, but they require different responses.

Leave the organisation more autonomous

A short intervention should not create a new dependency on the consultant. It should leave behind a readable decision record, an architecture explained through its constraints, a thirty, sixty, and ninety day trajectory, and a team able to continue.

Success is not a dashboard returning to green. It is the moment when the people involved can explain the next decision, the evidence that will enable it, and what will happen if the underlying assumption proves false.