Process Ownership Handover: Keep the Improvement Alive Long After the Project Team Leaves

The Process Ownership Handover tool does one thing. It formally hands over ownership of the improved process from the project team to the process owner. It records each item that moves, who released it, who received it, the date and the status.

You use it in Sustain, the last phase of RDMAICS. By then you have recognised the problem, defined it, measured it, analysed it, improved it and put controls around it. The risk at this point is not technical. The risk is human. The people who built the improvement move on, and nobody is quite sure who now owns the dashboard, the standard, the risk list or the training.

A handover that lives in a meeting conversation does not survive a reorganisation. A handover that lives in a table with names, dates and evidence does. That table is what this tool produces.

Run it when the control plan is stable, the measures have settled and the project team is about to stand down. Running it earlier means handing over something that is still moving. Running it later usually means it never happens.

Everything below is built on the sample data that ships with the tool. The case is fictional. It is there so you can see the shape of a complete handover before you build your own.

The scenario is an accounts payable improvement. A Black Belt and a Green Belt have run the project. Two people take over on the receiving side: an AP Manager and a Process Owner. Human resources holds the training evidence.

Five items move. A control plan. SPC dashboards. SOPs and work instructions. A risk register. Training records. All five are dated 2025-06-02, which makes this a single handover event rather than a drift of loose transfers across weeks.

Five items is a reasonable size for a first handover. It covers the rules of the process, the eyes on the process, the written method, the known exposures and the capability of the people doing the work.

The table asks for six columns. Four are mandatory: the handover item, the person or role it goes to, the date and the status. From and Notes are optional, but in practice both earn their place.

In the sample, the From column shows that the control plan and risk register came from the Black Belt, the SPC dashboards from the Green Belt, the SOPs from the AP Manager and the training records from HR. That spread is useful. It tells you the project team was not the only source of truth. Documents and training sat with the line and with a support function.

The Notes column is where the sample data does its best work. Each note is evidence rather than commentary. Signed. Access granted. V2.0 published. 4 residual risks. 12 of 12 trained. Each one can be checked by someone who was not in the room.

Write your entries at the level of a thing that can be owned. Avoid vague items such as knowledge or alignment. If you cannot point to it, grant access to it or sign it, it is not a handover item.

The tool returns five headline numbers. Handover items: 5. Handed over: 5 of 5. Receiving owners: 2. Handover date: 2025-06-02. Past due date: 0.

Underneath, it restates the position in one line. Five of five items are handed over. The AP Manager receives three. The Process Owner receives two. Then it lists each item as a card showing the status, the evidence from the notes, the date, and the from and to pair.

Read the receiving owners count first. Two is a workable number. The split of three and two tells you the load is shared rather than dumped on one person. A result showing one receiving owner for every item is worth a second look, because single point ownership of a whole control system tends to fail quietly when that person changes job.

Past due date of zero means nothing on the list has slipped past its planned date. That field is the one that will change first if your handover stalls. The tool also offers an AI review that explains the result in plain language if you want a second reading.

The first decision is whether the project team can stand down. With 5 of 5 handed over and 0 past due, the sample case says yes. If two items were still open, the answer would be not yet, and the tool tells you which two.

The second decision is where to direct follow up. The AP Manager now holds the control plan, the dashboards and the risk register. That is the operating spine of the improvement. If you only have time to check in with one person at the ninety day mark, the result tells you who it is.

The third decision concerns residual risk. The risk register note records 4 residual risks. Those four did not disappear at handover. They transferred. A handover record that names the risk register and its residual count gives the receiving owner a defensible starting point for their first review.

The fourth decision is about training. The record shows 12 of 12 trained. That number is a baseline. When new people join the process, the gap between the current trained count and that baseline is the clearest early warning you will get.

A handover is not an event that succeeds once. It is a claim that decays. The useful question is what you would look at three, six and twelve months after 2025-06-02 to test whether the claim still holds.

Start with the items themselves. The SOPs were handed over at v2.0. If the process has changed and the SOPs are still at v2.0, the written method and the actual method have parted company. The same logic applies to the control plan. A control plan that has never been amended since the signing date is either perfect or unread.

Then check access. The SPC dashboards moved on the strength of access granted. Access is the easiest thing in this list to lose. A role change, a system migration or a licence review can quietly end it. If nobody has opened the dashboards, the measurement side of the control system has stopped, even though the handover record still shows the item as handed over.

Finally check the people. Two receiving owners carried this handover. If either role changes hands and the handover record is not revisited, you are relying on an informal briefing to carry five items. Re-run the tool whenever a receiving owner changes. A short second handover beats a long investigation later.

The most common mistake is handing over to a team rather than a person or a role. A team cannot be called. The sample avoids this by naming AP Manager and Process Owner, both of which point at a single accountable seat.

The second mistake is empty notes. Status alone tells you a box was ticked. Evidence tells you what was ticked. Signed, access granted and v2.0 published all survive the departure of the person who wrote them.

The third mistake is a partial list that looks complete. If you hand over the control plan but not the training records, you have transferred the rules without the capability to follow them. Ask yourself what the receiving owner needs on day one, then check that each of those things appears as a row.

The fourth mistake is treating the record as closed. Store it where the receiving owners can find it, and open it again at your first review. A handover record that nobody reopens is a filing exercise.

The tool records a transfer. It does not verify it. The status column says handed over because someone typed handed over. The note says signed because someone typed signed. If the signature does not exist, the tool will still report 5 of 5.

It does not measure whether the process is still performing. Zero past due refers to handover dates, not to process results. You will need the control charts and the control plan itself to answer the performance question.

It does not track changes over time by itself. The record is a snapshot taken on one date. If you want to see decay, you have to re-run the tool or review the original entries against reality. Nothing in the result updates on its own.

It also does not tell you whether the receiving owners accepted the work willingly or had capacity for it. A name in the To column is a record of allocation, not of agreement. Have that conversation separately, before you fill in the table. The tool is at its best when it documents a decision that people already understand, and at its weakest when it is used to create one.