Cause-and-Effect Matrix: How to Rank Which Causes to Investigate First

The Cause-and-Effect Matrix evaluates potential causes against process outputs using a weighted scoring matrix. The output is a priority order. It tells you which causes to investigate first, not which cause is guilty.

You use it in the Analyse phase of RDMAICS. By that point you have defined the problem and measured the process. You usually have more candidate causes than you have time to chase. A team of five people can generate twenty theories in an hour. Investigating all twenty is not realistic.

The matrix forces a structured comparison. Each cause is scored on three dimensions. Severity is how badly the cause hurts the output. Occurrence is how often it happens. Detection is how hard it is to spot before it reaches the customer. The three scores multiply into a risk priority number, or RPN.

The value is not the arithmetic. The value is the conversation that happens while people argue about the scores.

Everything in this guide comes from the sample data that loads with the tool. The case is fictional. It exists to demonstrate the mechanics, not to report a real result.

The scenario is an accounts payable process. Invoices arrive, get keyed in, get matched against purchase orders, get routed for approval, and get paid. The problem the team is working on is late payment.

Five potential causes have been collected, spread across four process steps. Manual data entry carries two of them. The 3-way match, approval routing and payment processing steps carry one each.

That spread matters. A matrix that loads every cause onto one step usually means the team has not looked across the whole process yet.

The tool asks for four things per row. A process step, a potential cause, and then the three scores on a one to ten scale.

Here is the sample data exactly as it loads. Illegible invoice scans sit under manual data entry with severity 8, occurrence 7, detection 5. Inexperienced staff sit under the same step with severity 6, occurrence 5, detection 6. PO/invoice mismatch sits under 3-way match with severity 7, occurrence 8, detection 4. Approver unavailable sits under approval routing with severity 9, occurrence 6, detection 3. Bank holiday delays sit under payment processing with severity 5, occurrence 4, detection 8.

Two scoring habits make the difference between a useful matrix and a decorative one. First, anchor your scales before you score anything. Agree what a severity of 8 means in your process and write it down. Second, score the detection dimension the right way round. A high detection score means the problem is hard to detect. Bank holiday delays score 8 on detection because the delay is invisible until the payment misses its date.

Score as a group. One person scoring alone produces one person's assumptions dressed up as data.

The tool multiplies the three scores and ranks the rows from highest RPN down. In the sample data the order is illegible invoice scans at 280, PO/invoice mismatch at 224, inexperienced staff at 180, approver unavailable at 162, and bank holiday delays at 160.

Look at what the ranking does to intuition. Approver unavailable carries the highest severity in the set at 9. It still lands fourth, at 162. The reason is detection. It scores 3, because an unavailable approver is easy to spot. A problem you can see coming is a problem you can work around.

Illegible invoice scans top the list at 280 without the highest score on any single dimension. Severity 8, occurrence 7, detection 5. The cause is consistently mid-to-high across all three. That is what RPN rewards.

The gap between the top two and the rest is worth noticing. 280 and 224 sit clearly above 180, 162 and 160. The bottom three cluster within twenty points of each other. Treating 162 as meaningfully worse than 160 would be reading precision that the scoring does not support.

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

The first decision is where to send your investigation effort. The sample ranking points at illegible invoice scans and PO/invoice mismatch. Those two become the subject of root cause work, data collection and process observation.

The second decision is what to deliberately leave alone for now. Bank holiday delays sit last at 160. That does not mean the cause is harmless. It means it is not where your next week goes.

The third decision is about the shape of the problem. Two of the top three causes sit in steps that depend on document quality and data accuracy at the front of the process. That pattern is more useful than any single row.

The fourth decision is about detection controls. Bank holiday delays score 8 on detection while scoring only 5 on severity and 4 on occurrence. If you ever wanted a cheap improvement, making a hard-to-detect issue visible is often simpler than preventing it.

The most common mistake is scoring to justify a decision already made. Someone wants to replace the data entry system. The scores for data entry causes drift upward. The matrix then confirms what the room already believed.

The second mistake is inflation. When every severity lands between 7 and 9, the ranking collapses. In the sample data severity runs from 5 to 9 and occurrence runs from 4 to 8. That spread is what makes the ranking separate.

The third mistake is listing symptoms instead of causes. Late payment is the problem, not a cause. Illegible invoice scans is a cause, because it names a condition you could change.

The fourth mistake is treating RPN as a measurement. It is an ordered judgement produced by multiplying three opinions. The number 280 does not mean anything on its own. It only means more than 224.

It will not find your root cause. The matrix ranks candidates. Illegible invoice scans ranking first at 280 tells you to go and look. It does not tell you why scans are illegible, or whether fixing them would move your payment times at all.

It will not validate your scores. The tool multiplies what you enter. If the team scores occurrence at 7 when the real rate would support a 3, the output is confidently wrong and looks identical to a good result.

It will not generate the causes. Any theory nobody raised is absent from the ranking. The matrix cannot rank what it was never given, and the cause that matters most may not be in the room.

It will not quantify impact. Nothing here converts to hours, dollars or defect counts. RPN is a comparison between rows in one matrix, not a figure you can carry into a business case.

It will not survive the process changing. The sample scores describe a process at one moment. Change the data entry step and the occurrence score for illegible scans is no longer current. The matrix is a snapshot, so rescore it when the process moves.