Sustainment Plan: Keeping the Gain Alive Long After Handover

The tool does one job. It defines the activities, owners, and cadence that will sustain the improved process and its gains over the long term.

Sustain is the last phase of RDMAICS. By the time you reach it, the fix is in place and the control mechanisms are built. The risk is no longer technical. The risk is attention. People move on. Priorities shift. The improvement quietly drifts back toward the old way of working, and nobody notices until a quarter has passed.

A Sustainment Plan is the answer to that risk. It turns good intentions into scheduled work with a named owner and a forum that will ask about it. You use it at handover, when the project team steps back and the line organisation takes over. You revisit it every few months, because a plan that is never reviewed is just a document.

Treat it as a living register, not a closing artefact. The plan exists so that a specific person, at a specific interval, in a specific meeting, looks at a specific number.

The example used throughout this guide is the sample data built into the tool. It is fictional. No real organisation, team or result is described.

The case is an accounts payable process that has just completed an improvement cycle. Exception handling was reduced, control charts were introduced, and financial benefits were agreed with Finance. The improvement team is handing the process back to the business.

The question at handover is simple. Who will keep this working when the project team is gone? The Sustainment Plan answers it with six activities, spread across daily, weekly, monthly and quarterly cadence, each with an owner and a forum.

The spread matters more than the count. Daily checks catch drift early. Monthly checks confirm the system is still sound. Quarterly checks refresh the people. A plan that only has monthly items will be slow to notice a problem. A plan that is all daily items will exhaust the team.

The table takes one row per sustainment activity. Four fields are required: the activity, the owner, the review forum and the status. Frequency and success metric are optional but you should fill them in. An activity with no cadence and no metric is a wish, not a plan.

In the worked case the six rows read as follows.

Each row is written so that someone outside the project can understand it. The activity is a verb. The owner is a role, not a person. The success metric is a number or a clear condition, so the forum can say yes or no without debate.

The tool summarises the table into five figures. Six activities. Five of six active or complete. Six owners. Five review forums. Three of six run daily or weekly. It also breaks down the cadence: daily two, weekly one, monthly two, quarterly one, and flags that Refresh training is not yet active because it is Scheduled.

Read those numbers together, not separately. Six activities with six owners means no single person carries the whole plan. That is a good sign. If the count of owners had been one or two, the plan would depend on a small number of people staying in role.

Five review forums across six activities means the plan is embedded in meetings that already exist. The two daily items share the daily huddle. The rest sit in the ops review, governance review, finance review and training review. Nothing requires a new meeting to be created, which is usually where sustainment plans fail first.

Three of six running daily or weekly is the early warning layer. Those are the activities that will tell you something has slipped within days rather than months. The monthly and quarterly items are the confirmation layer.

Below the summary, the tool lists each activity as a card with its owner, frequency, forum and success metric. An AI review is available if you want a written explanation of what the pattern of activities suggests.

The value of the plan is that it gives you signals. Each one points at a different kind of decay.

The clearest signal in this worked case is the status column. Five of six activities are Active. One, Refresh training, is Scheduled. That is not a fault at handover, because training refresh is quarterly and the first cycle has not arrived. It becomes a fault if it is still Scheduled three quarters later. A status that never changes is the most common early sign of a plan going stale.

Watch the owner count too. Six owners today. If reorganisation collapses that to three, the plan has become concentrated and fragile without anyone deciding to make it so.

Watch the forum attendance. An activity owned correctly but reviewed in a forum that has stopped meeting is an activity with no audience. The success metric is still measured. Nobody acts on it.

The first decision is whether the process is ready for handover at all. If you cannot fill in six rows with named owners and real forums, the project is not finished. The plan is a readiness test as much as a schedule.

The second decision is where to put effort when capacity is tight. The cadence breakdown tells you which activities consume the most attention. Two daily items are the highest cost. If the team is stretched, you decide deliberately whether to reduce frequency, and you record that decision, rather than letting it erode.

The third decision is escalation. A success metric that fails in a daily huddle is a local problem. The same metric failing month after month, visible in the governance review and the finance review, is a signal that the improvement itself needs reopening. The plan gives the escalation path a structure.

The fourth decision is closure. Not every sustainment activity runs forever. Some activities exist to prove stability and can be retired once stability is proven. Marking an activity complete is a legitimate outcome, and the tool counts active or complete together for that reason.

The most common mistake is naming an individual rather than a role. People leave. Roles persist. In the worked case every owner is a role: AP Manager, AP Clerk, Process Owner, Black Belt, Finance, HR. That plan survives a staffing change.

The second mistake is a vague success metric. Savings on track is acceptable because Finance already has a benefits baseline to compare against. Improve performance is not acceptable, because no forum can rule on it.

The third mistake is inventing new meetings. Every activity in the worked case sits in a forum that already runs. Five forums for six activities is efficient. If you find yourself proposing a sustainment steering group, you are adding load rather than embedding work.

The fourth mistake is making the plan too long. Six activities is a plan a team can actually run. Twenty activities is a document that gets archived. Choose the few checks that would genuinely tell you the gain is at risk.

The tool counts and organises. It does not verify. It cannot tell you whether the AP Manager really looked at the control charts this morning, or whether the daily huddle actually happened. It records the intent. Confirming the behaviour is a human job, usually the monthly process audit.

It does not measure your process. The success metrics listed are labels, not live data. Exceptions under five per cent is a target written in a table. The tool does not know the current exception rate and will not alert you if it rises.

It does not judge whether your cadence is right. Three of six running daily or weekly looks reasonable for a transactional process. For a slower process it might be excessive. The tool reports the split. You decide whether the split fits the risk.

It will also not keep itself current. A status of Active today is only true until someone changes it. Put a date in the calendar to revisit the plan, and treat the status column as something that must be re-confirmed rather than assumed.

Used with those limits in mind, the Sustainment Plan does the one thing that matters after handover. It makes the work of holding the gain visible, owned and scheduled, so that nothing depends on someone remembering.