Data Collection Plan: Keep Measuring the Gain After the Team Moves On

The Data Collection Plan sits in the Control phase of RDMAICS. Its job is narrow and useful. It specifies the ongoing data collection needed to sustain control: what you measure, how you measure it, who records it and where it is recorded.

You reach for it near the end of a project, once the improvement is in place and the numbers have moved. At that point the team is about to disband. The question changes from how do we fix this to how do we know it stays fixed. A control chart or a response plan is only as good as the data feeding it. If nobody is named as the recorder, and no storage location is agreed, the measurement quietly stops within weeks.

The tool also works earlier. If you are about to start measuring a baseline, the same four questions apply. But its natural home is Control, where the plan becomes a handover document for the process owner.

Everything below is built from one case. It is a fictional example that ships with the tool as sample data, so you can see the shape of a finished plan before you build your own.

The case is an accounts payable process. Invoices arrive, get scanned, get coded, get approved and get posted. The project team has worked on error rates and speed. Now it needs four metrics watched on an ongoing basis.

The four are field error count, cycle time, defect type and approval time. Two cover quality. Two cover speed. Between them they describe whether the process is still behaving the way the project left it.

Each row in the worksheet is one metric. You fill in seven things beside it: a definition, a collection method, a sample size, a frequency, a recorder and a storage location.

Field error count is defined as wrong fields per batch. It is auto-logged from OCR QA, at 100 per cent sample size, daily, recorded by the system and stored in the data warehouse. Cycle time is defined as receipt to post in hours. It comes from a workflow timestamp, 100 per cent, daily, system recorded, stored in the workflow database.

Defect type is the odd one out. It is defined as a categorised invoice defect. The collection method is manual coding. The sample size is 30 a day rather than the full population. The recorder is an AP clerk, not the system, and it is stored in a defect log. Approval time returns to the pattern of the others: assigned to approved in hours, workflow timestamp, 100 per cent, daily, system, workflow database.

Notice how specific the definitions are. Cycle time is not just cycle time. It is receipt to post, in hours. That removes the argument six months from now about where the clock starts.

The tool summarises the worksheet into a small set of counts. For this case it reports four metrics. Four of four have a definition. Three of four are recorded automatically. Three of four cover the full population at 100 per cent. The frequency line reads daily on four metrics, and the tool notes that every metric has a definition.

Read those four counts as a health check on the plan itself, not on the process. They tell you how durable the measurement will be once the project team is gone.

Four of four with a definition is the number you want to see first. An undefined metric is an argument waiting to happen. Three of four recorded automatically tells you most of the load sits with systems rather than people, which is the stronger position for sustaining anything. Three of four at full population tells you most of these numbers are not samples, so you are not debating representativeness.

The tool also offers an AI review that talks through what the plan says. Use it as a second read rather than a verdict.

A finished plan drives a small number of concrete decisions at handover. Each one is visible in the sample data.

The first is who owns the number. Three metrics say system. One says AP clerk. That single human dependency is a named handover. Somebody has to brief that person, cover their leave and check the coding is still happening.

The second is where the number lives. Three locations appear here: the data warehouse, the workflow database and the defect log. If you want a single control dashboard, you now know it has to pull from three places. That is a build decision, and you have made it before the project closes rather than after.

The most common mistake is a vague definition. Writing cycle time with nothing after it invites four different interpretations. The sample data avoids this by writing receipt to post in hours. Every definition in this plan names its boundaries or its unit.

The second mistake is assigning everything to a person. Manual collection is sometimes unavoidable, as it is for defect type here, because categorising a defect needs judgement. But every row you can move to automatic is a row that keeps running when the roster changes. This plan has three of four automatic, and that is deliberate.

The third mistake is leaving storage blank. A metric that is collected but not stored anywhere findable is a metric that disappears. Every row in this plan has a named destination.

The fourth is mismatched frequency. Collecting daily and reviewing annually produces a large pile of unread data. If your plan says daily on four metrics, the control review cadence has to be close to that.

Be honest about the limits. This tool records a plan. It does not collect any data. Nothing in it reaches into a workflow database or a defect log. The counts you see are counts of what you typed.

It does not judge whether your metrics are the right ones. Four metrics with four definitions scores the same whether those four metrics describe the process well or badly. Choosing what matters is still your job, and it belongs to the Measure and Analyse work that came before.

It does not verify that the collection method works. Auto-log from OCR QA is a sentence in a box until somebody confirms the log exists and is accurate. The same applies to the workflow timestamps. Test each method before you sign the plan off.

It does not set control limits, define a response plan or tell you what to do when a number moves. Those are separate Control phase activities. The Data Collection Plan feeds them. It does not replace them.

Finally, it will not keep itself current. Processes change, systems get replaced and people move roles. Put a review date on the plan. A plan that named the right recorder two years ago may name nobody useful today.

Start with the metrics you actually used to prove the improvement. If a number was good enough to demonstrate the gain, it is usually the right number to watch afterwards. Keep the list short. Four metrics, as in this example, is a manageable set for a process owner to review.

Then work along the row. Define it tightly. Name the method. Decide whether you need the full population or a sample, and write the sample size plainly, the way 30 a day is written here. Set a frequency you will genuinely review. Name a recorder. Name a storage location.

When all the counts line up, the plan is ready to hand over. Four of four with a definition is the minimum bar. Everything else is a judgement about how much human effort you are willing to depend on.