KPI Monitoring Plan: How to Hold the Gain After the Project Team Moves On

The KPI Monitoring Plan sits in the Control phase of RDMAICS. In the tool's own words, it lets you define the key performance indicators monitored after improvement, with baseline, target, data source, and review cadence.

That sounds administrative. It is not. Control is the phase where most improvement work quietly fails. The team has solved the problem. The pilot worked. Then the team disbands, attention moves to the next project, and the process slides back toward where it started. Nobody notices for months because nobody was watching a specific number on a specific day.

A KPI Monitoring Plan is the answer to that drift. It names the handful of measures that prove the gain is still there. It fixes where each number comes from. It sets how often somebody looks. And it puts a name against every line so the looking actually happens.

Use it once your improvements are implemented and verified. Not before. You need a real baseline and a real target before this tool has anything to hold.

Everything below is built on the sample data that loads with the tool. The case is fictional. It describes an accounts payable invoice processing improvement, and it is there so you can see the shape of a finished plan before you build your own.

The scenario is simple. An invoice process had a high error rate, slow cycle times and a high cost per invoice. A project team ran through the earlier RDMAICS phases and made changes. The Control phase now needs to answer one question on an ongoing basis. Are the gains still in place?

Five KPIs carry that answer. Each one has a baseline from before the improvement, a target to hold, a named data source, a review frequency, an owner and a current status.

The table is the whole tool. You add one row per KPI and fill the columns. The sample plan has five rows.

Invoice error rate moved from a baseline of 35% to a target of 8% or lower. The data source is the QA audit log. It is reviewed daily and owned by the Green Belt. Average cycle time started at 18.5 hours with a target of 4 hours or lower, drawn from the workflow system, reviewed daily, owned by the AP Manager. On-time payment percentage started at 82% with a target of 97% or higher, taken from an ERP report, reviewed weekly, owned by the AP Manager.

DPMO, defects per million opportunities, started at 350,000 with a target of 80,000 or lower. It comes from the defect log, is reviewed monthly and is owned by the Black Belt. Cost per invoice started at $12.40 with a target of $5.00 or lower, taken from a finance report, reviewed monthly, owned by the Sponsor.

Notice the discipline in the frequency column. The fast operational measures, error rate and cycle time, are checked daily. The financial measure is checked monthly. You match the cadence to how quickly the number can move and how quickly you would want to react.

The tool produces a summary block and a chart. The summary reports five KPIs, four of five on target, one not on target, and four owners across the plan.

The line that matters most is the plain statement. Four of five KPIs are on target. Not yet on target is on-time payment percentage. That single sentence is what a sponsor reads first. It tells you the improvement is largely holding and it names the one measure that still needs attention.

Four of the five rows carry a status of On Target. On-time payment percentage carries a status of Monitoring. The status column is a judgement you enter, not something the tool calculates for you. The tool counts and summarises what you have recorded.

The chart plots baseline against target for each KPI on a shared scale running from 0 to 360,000. Because DPMO dominates that range, the other four KPIs sit low on the axis. Read the chart as a visual confirmation that baselines and targets are both recorded for every line, and read the table for the detail on each individual measure.

The tool also offers an AI review that explains the result in context.

A finished plan gives you a short list of decisions you can actually make.

The first is where to put attention. With four of five KPIs on target, you do not spread effort evenly. You focus on on-time payment percentage, which sits at a baseline of 82% against a target of 97% or higher and carries a status of Monitoring. Everything else gets routine review.

The second is handover. The plan names four owners across five KPIs. The AP Manager holds two lines. The Green Belt, the Black Belt and the Sponsor hold one each. When the project team moves on, this is the document that tells each of those people exactly what they inherited and how often they need to look at it.

The third is cadence of governance. Two KPIs are daily, one is weekly, two are monthly. That tells you how to structure the review meetings. A daily stand-up covers error rate and cycle time. A monthly review covers DPMO and cost per invoice. You do not need a monthly meeting to discuss a number that is checked every day.

The most frequent error is too many KPIs. The sample plan has five. That is a sensible upper bound for most processes. Twenty KPIs means nobody reviews any of them properly. If a measure would not change a decision, leave it out.

The second error is a vague data source. QA audit log, workflow system, ERP report, defect log and finance report are all specific. A source listed as the team or reporting is not specific. When the owner has to work out where the number lives, the review gets skipped.

The third error is a shared owner. Each row in the sample has exactly one owner by role. Two names on a line means no name on a line. Use roles rather than individuals so the plan survives staff changes.

The fourth error is a target without a direction. Note how the sample writes 8% or lower and 97% or higher. The direction removes argument about whether a number is good news.

Be clear about the limits. The KPI Monitoring Plan is a register and a summary. It is not a live data feed. It does not connect to the QA audit log or the ERP report. The numbers in the table are the numbers you typed. If the process drifts and nobody updates the status column, the plan will keep reporting four of five on target long after that stopped being true.

It does not calculate status. The On Target and Monitoring labels are your judgement entered as text. The tool counts them. It does not test your current performance against your target for you.

It does not tell you why on-time payment percentage is not yet on target. That is analysis work, and it belongs back in the Analyse phase or in a focused follow-up. The plan only flags that a gap exists.

It also does not enforce the review cadence. Daily written next to invoice error rate is a commitment, not a control. The discipline has to come from the governance routine you build around the plan.

Within those limits the tool does one thing well. It turns an improvement that worked once into a short, owned, scheduled set of checks that keep working after the project team has gone.