Solution Brainstorming: Turn a Validated Root Cause Into a Change Worth Piloting

Solution Brainstorming sits in the Improve phase of RDMAICS. In the product's own words, it captures solution ideas generated by the team to address validated root causes, then clusters and refines them for screening.

The timing matters. You reach for this tool after Analyse has done its job. If the causes on your list are still suspicions, brainstorming produces a pile of changes aimed at nothing in particular. If the causes are validated, every idea you capture has an owner cause attached to it, and that single link is what later lets you size the gain.

Use it in a facilitated session rather than alone. The point is volume first, then structure. People generate ideas from different vantage points, and the tool records who originated each one so you can go back and ask what the person was actually seeing when they said it.

Everything below is built on the sample data that ships with the tool. The case is fictional. It is an accounts payable process with four validated root causes behind it: manual data entry errors, invoice scan quality, approver unavailability, and PO-invoice mismatch.

A cross-functional group has put six solution ideas on the board. Two come from IT and process analysis, two from the AP side, one from the Green Belt leading the project, and one from the sponsor. The ideas are deliberately uneven in maturity. That is normal and it is useful.

The tool does not judge these ideas. It records them, attributes them, and arranges them so the group can see the shape of its own thinking. The judging happens next, in screening, and the arrangement is what makes screening quick.

Each row carries six fields. The solution idea itself. The root cause it addresses. A category. An originator. An initial feasibility rating. Fill all of them. A row with a blank root cause is an orphan and it will skew the grouping view later.

The six sample rows look like this. Idea 1 is OCR-based invoice data capture, against manual data entry errors, category Automation, from the IT Lead, initial feasibility High. Idea 2 is a vendor portal with scan validation, against invoice scan quality, category Process, from the AP Manager, feasibility Medium. Idea 3 is auto-routing with delegation rules, against approver unavailability, category Workflow, from the Green Belt, feasibility High. Idea 4 is an automated 3-way match rules engine, against PO-invoice mismatch, category Automation, from the Process Analyst, feasibility Medium. Idea 5 is a mobile approval app for managers, against approver unavailability, category Technology, from the Sponsor, feasibility Low. Idea 6 is a vendor master-data cleanup campaign, against PO-invoice mismatch, category Data Quality, from Master Data, feasibility High.

Two things to be strict about while you type. Keep the root cause wording identical to the wording you used in Analyse. If you paraphrase, the links break and coverage becomes hard to read. And treat initial feasibility as a first reaction, not a verdict. It is a rough sort, nothing more.

The tool produced a Solution Brainstorming workspace marked BUILT FROM WORKSHEET. It reports 6 ideas in 5 groups. The grouping is by method category, and the workspace states plainly that no false process sequence is implied. That note is worth taking seriously. A cluster is not a roadmap and the order of the groups carries no meaning.

The five groups break down as follows. Automation holds 2 ideas: OCR-based invoice data capture against manual data entry errors at High feasibility, and the automated 3-way match rules engine against PO-invoice mismatch at Medium. Process holds 1: the vendor portal with scan validation, invoice scan quality, Medium. Workflow holds 1: auto-routing with delegation rules, approver unavailability, High. Technology holds 1: the mobile approval app, approver unavailability, Low. Data Quality holds 1: the vendor master-data cleanup campaign, PO-invoice mismatch, High.

The tool also offers an AI review that explains the result in context. Treat it as a second reading of your own board, not as a decision.

Read the shape before you read the rows. Six ideas across five groups means the thinking is spread thin. Only Automation attracted more than one idea. That tells you the group reached for one familiar lever and then scattered.

The first decision is coverage. Look at which root causes attracted ideas and how many. PO-invoice mismatch has two ideas against it, the rules engine and the master-data cleanup. Approver unavailability also has two, auto-routing and the mobile app. Manual data entry errors has one. Invoice scan quality has one. Any cause with a single idea deserves another pass before you close the session.

The second decision is where to look for a pilot. Three ideas carry High initial feasibility: OCR capture, auto-routing with delegation rules, and the master-data cleanup campaign. Those three are your natural shortlist for screening, because they are the ones the room believed could be done. Two carry Medium. One, the mobile approval app, carries Low.

The third decision is about overlap. Approver unavailability has two ideas aimed at it, one High and one Low. You do not need both. Screening will ask whether auto-routing alone addresses the cause, and whether the mobile app adds anything beyond it.

Sizing the gain comes next, and it comes from the cause link. You already know from Measure and Analyse how much of the problem each validated cause accounts for. An idea that fully fixes a cause can be sized against that cause's share. That is how you estimate the prize before you spend anything on a pilot.

The most frequent error is screening during generation. Someone proposes the mobile approval app, someone else says it will never get funded, and the idea never reaches the board. In the sample it did reach the board, tagged Low. That is the right behaviour. Low feasibility ideas often carry a useful fragment that survives into a better idea.

The second error is overloading one category. If every idea lands under Automation, the group has defaulted to a single lever. The sample avoids this by spreading across five categories, though at the cost of thin coverage in four of them.

The third error is wording drift on root causes. Write PO-invoice mismatch in one row and purchase order mismatch in another and the tool will treat them as separate causes. Your coverage picture then lies to you.

The fourth is treating the clusters as a sequence. The workspace says no process sequence is implied. Automation appearing first does not mean automate first.

It will not tell you which idea to pick. The tool reports 6 ideas in 5 groups and tags each with an initial feasibility rating. It does not rank them, score them against criteria, or weigh cost against benefit. That work belongs to a screening tool downstream.

It will not validate your root causes. Everything here inherits the quality of your Analyse work. If manual data entry errors was never actually proven to drive the problem, OCR capture is a well-organised solution to nothing. The tool cannot detect that.

It will not size the gain by itself. No figure in the result tells you what OCR capture is worth. The sizing comes from your own data on how much of the problem each cause contributes, applied by hand to the ideas that address it. The tool gives you the link. You supply the arithmetic.

It will not tell you whether an idea will survive contact with the organisation. Initial feasibility is a reaction recorded in a room on one day. The Low rating on the mobile approval app reflects what the group believed at the time, not a tested conclusion. Pilot design is where that gets answered.

What it does do is make the thinking visible. Six ideas, five groups, every idea tied to a named cause and a named originator. That is a board you can argue with, and arguing with it is the point.