The project ending is a design decision
An improvement can be implemented successfully and still weaken later. The original team moves on, demand changes or an experienced owner leaves. The operation then faces a test: does the new way of working have a home in everyday management, or does it depend on the people who delivered the project?
My sustainment review examines five supports: measurement, cadence, ownership, data and learning. They connect the gain to the operating system. Reviewing them creates a practical starting point when results plateau. Before announcing another programme, establish which part of the existing system has become less reliable and what evidence supports that conclusion.
Keep the measure and its meaning
A result needs a measure that continues after the project closes. Record the definition, source, owner and review rhythm. Make clear which outcome matters and which process signals help explain it. If the measure changes, preserve enough context to interpret the difference. An apparently stable chart can conceal a changed denominator or missing observations.
Use the review to examine the measure and decide what follows. A number stored in a presentation is not an active control. Put the relevant signal where the team makes decisions and agree the response when it moves outside expectations. The response should trigger investigation, not automatic blame.
Protect cadence and renew ownership
The cadence is the recurring opportunity to see whether the improvement is holding. It needs a role in the team's calendar and an owner who ensures it remains useful. If the meeting stops because one person is absent, the responsibility has not been fully embedded. Agree who can facilitate and which decisions the group can take.
Assign sustainment ownership to a role with the ability to influence the process. Name the current person, a deputy where needed and the handover expectations. A promotion or departure should trigger a review of responsibilities, open issues and working standards. Treat that transition as part of normal management rather than relying on informal memory.
Check whether people can explain the new method and why it matters. If they can repeat the instruction but cannot describe the problem it prevents, the handover is incomplete. Preserve the reasoning as well as the procedure so that future changes do not accidentally recreate the original condition.
Make data and learning usable
Keep the supporting evidence accessible in the place the team uses. It should be possible to locate the baseline, the countermeasure and the verification result without reconstructing the project from personal files. The purpose is continuity of understanding, not an archive of every workshop slide.
Write the lesson in operational terms: the condition encountered, what was changed, what was learned and when the approach should be reconsidered. Include limitations. A successful intervention in one setting does not automatically become the correct answer everywhere. The next team needs enough context to decide whether it applies.
Let the people performing the work revise the standard when the work changes. Include the normal sequence and the response to exceptions. The document supports a habit that is practiced, checked and improved. A formally approved procedure that no longer describes reality can make sustainment look stronger than it is.
Return to the operating system
When performance weakens, walk back to the point where the gain was created. Compare current practice with the original conditions and review each of the five supports. Restore what has drifted, test what no longer fits and avoid relaunching a method before understanding the gap. Sustained change comes from a system that keeps learning after the project team has left.