Cause Validation Plan: Prove Your Root Causes Before You Spend a Dollar on Improve

By the end of the Analyse phase you usually have a list of suspected root causes. Some came from a fishbone session. Some came from process mapping. Some came from the person who has run the process for nine years and has a strong opinion about it. All of them feel plausible. That is the problem. Plausible is not the same as proven.

The Cause Validation Plan exists to close that gap. In the product's own words, it helps you plan how each suspected root cause will be validated with data, statistical tests, or experiments before moving to Improve. It is a planning tool first and a record second. You write down what you believe, how you intend to test it, what data that test needs, who owns the work, and what the test actually returned.

Use it at the point where your cause list has stopped growing and has started to need pruning. That is normally the back half of Analyse. Running it too early wastes effort on causes you will discard anyway. Running it too late means you have already built a solution for a cause that was never real.

The walkthrough below uses the sample data that ships with the tool. This case is fictional. It is built around an accounts payable team dealing with errors and delays in invoice processing, and it is useful precisely because the four suspected causes are the kind of mixed bag most teams end up holding.

The four suspects are manual data entry errors, approver unavailability, invoice scan quality, and PO to invoice mismatch. Notice how different they are from each other. One is a human accuracy issue. One is a scheduling issue. One is an input quality issue. One is a data matching issue. Each one needs a different kind of evidence, and that is the first thing the plan forces you to confront.

A single test will not cover all four. If you try to validate everything with one survey or one sample, you will produce evidence that is thin in three places and strong in none.

The table has six columns. Work left to right and fill one row per suspected cause. Keep each row to a single cause. If a row needs the word "and", split it into two rows.

Here is how the sample case fills out. Manual data entry errors is paired with a hypothesis test using two proportions, needing error rates before and after an OCR pilot, owned by the Black Belt. Approver unavailability is paired with a time study plus regression, needing approval times and an availability log, owned by the Green Belt. Invoice scan quality is paired with a chi-square test, needing defect counts by scan quality, owned by the QC Lead. PO to invoice mismatch is paired with Pareto analysis, needing mismatch type frequency, owned by the Process Analyst.

The Validation Method column is where most of the thinking happens. Match the method to the shape of the data you expect. Comparing two rates before and after a change points to a two proportion test. Looking for a relationship between a continuous input and a continuous output points to regression. Comparing counts across categories points to chi-square. Ranking categories by frequency points to Pareto. The sample data demonstrates all four, which makes it a useful reference even after you replace it with your own rows.

The Owner column is not decoration. One named role per row. Shared ownership across a row is the fastest route to a plan that sits untouched for three weeks.

Once the rows carry status values, the tool produces a readiness summary. For the sample case it shows three causes Validated and one In Progress. That is the headline the tool calculates, framed as evidence readiness before Improve.

The detail sits in the Result column. Manual data entry errors returned p equals 0.002, recorded as significant. Approver unavailability returned r equals 0.68 with p below 0.001. PO to invoice mismatch returned a Pareto finding where the top three mismatch types account for 78 per cent. Invoice scan quality shows pending data collection, which is why it sits In Progress rather than Validated.

Read the summary as a gate, not a score. Three validated out of four does not mean you are 75 per cent ready. It means three causes have evidence behind them and one does not yet. The tool also offers an AI review that explains the result in context, which is worth reading before you present the plan to a sponsor.

The first decision is which causes earn a solution. In the sample case, three causes have recorded evidence and one does not. You can design improvements for the three now. The fourth waits for its data.

The second decision is sequencing. The Pareto result shows the top three mismatch types account for 78 per cent of mismatches. That tells you where to aim first within that cause, without any further analysis.

The third decision is whether to proceed at all while a row sits In Progress. Sometimes you hold the whole phase. More often you proceed on the validated causes and keep the open row running in parallel, with the owner reporting back. The plan makes that choice visible and deliberate rather than accidental.

The fourth decision is what to tell your sponsor. A plan with named owners, chosen methods and recorded results is a far stronger conversation than a fishbone diagram and an assurance that the team feels confident.

The most frequent error is marking a row Validated because the team agrees with it. Agreement is not evidence. A row moves to Validated when the Result column holds a finding, as it does for the three validated rows in the sample case.

The second error is choosing the method after collecting the data. That order lets you shop for a test that produces the answer you wanted. Decide the method first, write it in the Validation Method column, then collect.

The third error is leaving the Data Needed column vague. "Error data" is not a specification. "Error rates before and after the OCR pilot" is. The owner should be able to start collecting without asking a follow up question.

The fourth error is treating a p value as the whole story. A significant result tells you a relationship is unlikely to be chance. It does not tell you the relationship is large enough to matter commercially. That judgement stays with you.

The Cause Validation Plan will not run your statistical tests. It records the method and the result. The hypothesis test, the regression, the chi-square and the Pareto analysis all happen elsewhere. If you enter a result that was produced badly, the plan will store it faithfully and tell you nothing is wrong.

It will not check that your chosen method suits your data. Nothing stops you writing chi-square against a row where regression was the right call. The tool holds the structure. The methodological judgement is yours.

It will not tell you whether a cause is worth fixing. Approver unavailability returned r equals 0.68 with p below 0.001 in the sample case. That is a recorded relationship. Whether fixing approver availability is affordable, politically possible or worth the disruption is a separate conversation the plan does not have.

It will not find causes you failed to list. A plan with four rows validates four suspects. If the real driver never made it onto the fishbone, the summary will still read three Validated and one In Progress, and it will look reassuring. Completeness of the cause list is an input, not an output.

Finally, it will not keep itself current. A row marked In Progress stays In Progress until someone updates it. The tool gives you a clear view of evidence readiness. Keeping that view honest is still human work.