Statistics
The Root-Cause Prioritization Matrix scores each validated root cause by impact, evidence and ease of fix, then ranks them for you. This walkthrough uses the built-in sample data to show how the scoring works, what the chart tells you, and where the tool stops being useful.
The Root-Cause Prioritization Matrix sits in the Analyse phase of RDMAICS. Its job is narrow and useful. It prioritises validated root causes by impact, evidence strength and ease of fix, so your improvement effort lands where it will do the most good.
Note the word validated. This tool is not where you discover causes. By the time you open it, you should already have run your cause hunting, tested the candidates against data, and discarded the ones that did not hold up. The matrix is the step after that, when you hold five or ten surviving causes and you cannot work on all of them at once.
Reach for it at the end of Analyse, just before you move into Improve. If you skip it, you tend to default to the cause that is loudest in the room rather than the cause that moves the measure. The matrix makes that trade visible on a single screen.
The walkthrough below uses the sample data that ships with the tool. The case is fictional. It is there so you can see the mechanics before you load your own numbers.
Picture an accounts payable team working on invoice processing time. The team has been through Measure and Analyse. They have five causes that survived testing: manual data entry errors, approver unavailability, invoice scan quality, PO to invoice mismatch, and bank holiday delays.
Each one is real. Each one has evidence behind it. None of them can be fixed by Friday. That is the exact situation the matrix is built for.
Each row is one validated root cause. You fill in four things, and the tool calculates the fifth.
Impact on Y is scored from 1 to 10. It asks how much this cause moves the outcome measure you care about. Data evidence is a short written note, not a score. It is where you record the proof that made you keep this cause. Ease of fix is scored from 1 to 10, where 10 means simple and fast and 1 means difficult or expensive.
In the sample data, manual data entry errors carries an impact of 9 with an evidence note of a 35 per cent error rate at that step, and an ease of fix of 7. Approver unavailability scores 8 on impact, with an average delay of 3.2 hours per invoice, and 5 on ease. Invoice scan quality scores 7, with 12 per cent of scans illegible, and 8 on ease. PO to invoice mismatch scores 6, affecting 22 per cent of invoices, with an ease of 6. Bank holiday delays scores 3, affecting 2 per cent of payments, with an ease of 9.
The priority score is impact multiplied by ease of fix. That gives 63, 40, 56, 36 and 27 respectively. The arithmetic is deliberately plain so that any person in the room can check it.
The tool plots impact against ease of fix on a chart that runs from 0 to 10 on both axes, with gridlines at 3 and 6. The guidance on the chart is direct: upper right causes are strong candidates for action.
In the sample data, manual data entry errors lands high on both axes and takes the top priority score of 63. Invoice scan quality follows at 56, pulled up by a strong ease rating of 8 despite an impact of 7. Approver unavailability scores 40 because its high impact of 8 is dragged down by an ease of 5. PO to invoice mismatch scores 36. Bank holiday delays scores 27, the lowest, because an ease of 9 cannot rescue an impact of 3.
That ordering is worth sitting with. The cause with the second highest impact is not the second priority. The cause that is easiest to fix is last. The multiplication forces both dimensions into the decision at once.
The tool also offers an AI review that explains the result in context. Treat it as a second reader, not as the decision.
The first decision is sequencing. With scores of 63 and 56 at the top, the sample team has a defensible case for starting with manual data entry errors and invoice scan quality. Both sit in the upper right region the chart points at.
The second decision is what to defer without losing it. Approver unavailability has an impact of 8. It matters. An ease of 5 tells you it needs a longer piece of work, probably a change to how approvals are routed rather than a quick fix. Parking it is not the same as dismissing it.
The third decision is what to stop discussing. Bank holiday delays affects 2 per cent of payments and scores 27. It is easy to fix, which is exactly why it attracts attention in meetings. The matrix gives you a calm reason to leave it alone for now.
The fourth decision is how to explain your choice to a sponsor. A score built from two visible inputs and one multiplication is easier to defend than a preference.
The most frequent error is loading unvalidated causes. If a row has no evidence note, it does not belong in the matrix. The sample data makes this discipline visible, because every row carries a specific figure such as 35 per cent, 3.2 hours, 12 per cent, 22 per cent or 2 per cent.
The second error is scoring ease of fix from the perspective of the person who will not do the work. Ease should reflect effort, cost, dependencies and disruption as experienced by the team that owns the change. Score it with them in the room.
The third error is inflating impact. If every cause scores 8 or 9, the matrix collapses and the ease column decides everything. Spread your scores. In the sample, the range runs from 3 to 9, which is what makes the ranking informative.
The fourth error is treating the priority score as final. It is an input to a conversation, not an output of one.
The matrix will not find root causes. It ranks what you give it. If your Analyse work missed the real driver, the tool will confidently prioritise the wrong list and the scores will look just as tidy.
It will not validate your evidence. The data evidence column is free text. The tool does not check whether 35 per cent came from a sound measurement or a rough guess. Two rows with identical scores can rest on very different quality of proof, and the priority score cannot tell them apart.
It will not tell you how much improvement to expect. Nothing in the output forecasts time saved, error reduction or cost. A score of 63 is a rank, not a benefit. If you need a projected result, you need a separate piece of work.
It will not weight the two dimensions for you. Impact and ease carry equal weight in the multiplication. In some projects impact should dominate. The tool does not adjust for that, so you need to notice it yourself when a high impact cause with low ease gets pushed down the list.
It will not account for risk, dependency or sequencing. Fixing scan quality might be a precondition for fixing data entry errors. The matrix does not know that. It will not flag regulatory constraints, capacity limits, or a change already underway elsewhere.
Finally, it will not make the decision. The AI review explains the result. The chart points at the upper right. Both are aids. The choice of what to improve next, and the responsibility for that choice, stays with you and your team.
RDMAICS, A3, Just Do It and Kaizen projects with the full Lean Six Sigma toolset, AI interpretation and tollgate presentations built from your real evidence.
Process Capability Analysis sits in the Control phase of RDMAICS and asks one blunt question: does the improved process still meet the specification when nobody is watching. This guide walks through the built-in sample data in Ci Flow, a post-improvement invoice cycle time study of 30 units, and shows how to read it.
Read the article
This guide walks through the Equal Variance Test in the Analyse phase of RDMAICS using one fictional three team dataset. You will see how the tool picks a method, what the output means, and where the tool stops being useful.
Read the article
A control chart tells you something moved. A trigger and threshold matrix tells you who acts, at what number, and how fast. This guide walks through the tool using its built-in sample data of four controlled metrics.
Read the article