Operational Definition Review: Keep Your Control Metrics Meaning the Same Thing Next Year

Operational Definition Review sits in the Control phase of RDMAICS. Its job, in the product's own words, is to re-confirm operational definitions for control metrics so measurements stay consistent and unambiguous post-improvement.

That sounds administrative. It is not. Most control plans fail quietly. Nobody argues about the target. People simply start counting different things. One analyst counts a rejected invoice as an error. Another counts the field, not the invoice. Six months later the chart looks stable and the process is drifting.

You use this tool at handover. The improvement is in place. The control chart is running. Before the project team steps away, you write down what each metric means, how it is captured, what unit it is reported in, and who confirmed all of that. Then you set a review date so the definition gets checked again rather than assumed.

There are four moments where this tool earns its place.

Run it at the end of Improve, as you build the control plan. Run it again when a control metric changes owner. Run it when a measurement system changes, for example a new reporting tool or a new ERP field. Run it on the scheduled review date you set the last time.

If you only run it once, run it at handover. That is the point where the knowledge is still in the room.

The tool ships with sample data, and this article is built entirely around that sample. The case is fictional. It is not drawn from any real organisation.

The scenario is an accounts payable process that has just finished an improvement cycle. Three metrics were carried into Control. Field error rate, measured as a percentage. Cycle time, measured in hours. On-time payment, measured as a percentage.

Each one looks obvious until you ask the second question. Error rate of what, against what denominator? Cycle time from when to when? On time against which date field? Those second questions are exactly what the worksheet forces you to answer in writing.

The worksheet uses one row per control metric and six columns. Metric, Operational Definition, Measurement Procedure, Units, Validated By, Review Date.

In the sample, row one is Field error rate. The operational definition is mis-captured fields divided by total fields times 100. The measurement procedure is that the QA tool compares OCR against verified. The unit is a percentage. It was validated by a Green Belt, with a review date of 2025-05-12.

Row two is Cycle time. The definition is hours from invoice receipt to payment post. The procedure is a workflow timestamp delta. The unit is hours. The validator is the AP Manager, reviewed on the same date. Row three is On-time payment, defined as payments made on or before the net due date divided by total times 100, measured by comparing the ERP due date against the post date, reported as a percentage, validated by Finance on 2025-05-12.

Notice the separation between the definition and the procedure. The definition is the arithmetic and the boundary conditions. The procedure is the mechanical act of getting the number. Both can fail independently. A correct formula pulled from the wrong system field still produces a wrong number.

The tool reads the worksheet and returns a short control output. For the sample data it reports three definitions from the worksheet. It then reports three of three validated by someone, three of three with units stated, and a latest review date of 2025-05-12. The summary line states that every definition has units and a named validator.

Those are completeness checks, not quality checks. The tool is telling you that nothing is blank. Three metrics went in, three have a unit, three have a named validator, and they all carry the same review date. The chart repeats 2025-05-12 across the three rows so you can see at a glance whether the reviews are clustered or scattered.

A clustered date is a good sign at handover. It means the definitions were confirmed together, in one sitting, by people in the same conversation. A scattered set of dates later on tells you something different. It tells you some definitions have been revisited and others have been left alone.

The tool also offers an AI review that explains the result in plain language. Treat it as a second reader, not as a sign off.

The output is small, so be clear about what you do with it.

First, it supports a go or no go on control plan sign off. If units are missing or a validator is blank, the plan is not ready. In the sample, both checks return three of three, so the plan can proceed on that basis.

Second, it sets accountability. A named validator is not decoration. When the field error rate is questioned next quarter, you know the Green Belt confirmed the definition and the AP Manager confirmed cycle time. The question goes to a role, not to a vacuum.

Third, it schedules the next conversation. The review date is the trigger. With 2025-05-12 recorded as the latest review date for all three, you have one date to diarise rather than three.

Fourth, it protects against silent redefinition. If someone later proposes reporting cycle time in days rather than hours, the worksheet makes that a visible change with a new review date, not an unrecorded drift.

The most common mistake is writing the metric name in the definition column. Field error rate is a name. Mis-captured fields divided by total fields times 100 is a definition. If the text in the definition column could not be handed to a stranger who would then produce the same number, it is not finished.

The second mistake is leaving the validator generic. Finance validated the on-time payment definition in the sample, and that is a role you can go back to. Written as a department with no owner behind it, the trail goes cold at the first reorganisation.

The third mistake is treating three of three as proof of correctness. It is proof of completeness. A definition can be fully populated and still wrong. The tool cannot taste the arithmetic.

The fourth mistake is setting a review date and never returning. A date that passes without a review is worse than no date, because it creates false confidence that the definitions are current.

Be honest about what this tool will not do. It will not tell you whether your definitions are correct. It checks that a unit is present and that a validator is named. It does not verify that the formula matches the process, that the denominator is the right one, or that the system field actually contains what the procedure claims.

It will not perform a measurement system analysis. Repeatability, reproducibility and bias are separate questions handled by separate tools in the Measure phase. A definition can be perfectly written and still be measured by an unreliable gauge.

It will not tell you whether your control metrics are the right metrics. Three definitions went in and three came back. The tool has no view on whether a fourth metric should exist, or whether one of these three has stopped mattering.

It will not enforce the review date. The date is a record, not an alarm. Someone has to own the calendar.

Finally, it will not keep people honest on its own. The worksheet is a prompt for a conversation between the person who built the metric and the person who now owns it. Run that conversation, record the result, and the gain has a better chance of staying where you left it.