Feasibility Assessment: Size the Gain Before You Commit to a Pilot

By the time you reach the Improve phase of RDMAICS, you have done the hard diagnostic work. You recognised a problem, defined its boundaries, measured the baseline and analysed the causes. You now hold a short list of candidate solutions. Each one claims to address a verified cause. Each one also carries cost, effort and risk that nobody has written down yet.

Feasibility Assessment closes that gap. In the product's own words, it assesses technical, operational and financial feasibility of each solution to validate viability before piloting. The output is a comparison, not a verdict. You still choose. The tool makes the basis of that choice visible to everyone in the room.

Use it at the point where the conversation shifts from what causes the problem to what we are going to do about it. Use it before you book pilot resources. Use it again if a sponsor asks why option two was chosen over option four, because the scores give you an answer that does not depend on who spoke loudest in the workshop.

There is a specific moment in Improve where teams lose momentum. They have four or five ideas, all plausible, none costed. Debate circles. Someone suggests piloting everything. Someone else suggests piloting nothing until a business case exists. Both responses stall the work.

Feasibility Assessment is designed for that moment. It forces three questions per option and nothing more. Can we build it. Can we run it. Can we fund it. Three numbers per solution is enough structure to separate the obvious from the arguable, and light enough that a team can complete it in a single session.

This article follows a single worked example throughout. The case is fictional. It is the sample data that ships with the tool, and it describes an invoice processing improvement with four candidate solutions on the table.

The four options are OCR-based invoice capture, auto-routing with delegation, automated three-way match rules, and a vendor portal with validation. Each one targets a different part of the same process. Capture at the front, routing in the middle, matching at the back, and supplier behaviour upstream of all three.

That spread is typical. When you analyse a transactional process, the causes rarely sit in one place. The question is not which cause is real. The question is which fix you can actually deliver with the people, systems and budget you have this year.

The worksheet asks for one row per solution. You give each solution a name, then score it from one to five on three dimensions. Technical feasibility covers whether the change can be built and integrated. Operational feasibility covers whether the organisation can absorb and run it. Financial feasibility covers whether the money is available and justified.

In the sample, OCR-based invoice capture scores four on technical, four on operational and three on financial. Auto-routing with delegation scores five, five and five. Automated three-way match rules score four, four and four. Vendor portal plus validation scores three, three and three.

The last column is the one teams skip and should not. Each row carries a risk note. OCR capture is flagged for ERP integration complexity. Auto-routing is flagged for policy change required. The match rules are flagged for rule tuning effort. The vendor portal is flagged for vendor adoption. These notes do not change the scores. They explain them, and they tell the next reader what the team was worried about.

Score honestly rather than diplomatically. A three is a useful signal. A row of fives for every option tells you the team avoided the conversation.

From those scores the tool calculates an overall feasibility rating for each row. Auto-routing with delegation comes out as Highly Feasible. OCR-based invoice capture and automated three-way match rules both come out as Feasible. The vendor portal with validation comes out as Conditional.

The result view presents this as a decision portfolio. Options are compared on both decision dimensions, and cost and deployment time remain visible. The chart is built from the worksheet, with both axes running from zero to eight, so you see position rather than rank. Two solutions can share a rating and still sit in different places.

The tool also offers an AI review that explains the result in narrative form. Read it after you have formed your own view, not before. The value of the scoring exercise is the discussion that produced the numbers. Use the review to check whether you missed something, not to replace the judgement you just made.

The first decision is sequencing. Auto-routing with delegation rates Highly Feasible with fives across all three dimensions. That makes it the natural first pilot. Its risk note says policy change required, which is a governance task rather than a technical one. You can start the policy work in parallel with the pilot design.

The second decision is the middle of the field. OCR capture and the match rules both rate Feasible. OCR scores three on financial and carries ERP integration complexity. The match rules score four across the board and carry rule tuning effort. If you can only run one, the match rules carry the lower financial and integration burden on these scores. That is an argument, not a conclusion, and the team should say so out loud.

The third decision is what to park. The vendor portal rates Conditional with threes on every dimension and a risk note of vendor adoption. Conditional does not mean rejected. It means something has to be true before this is viable. In this case the condition is supplier behaviour, and you do not control it. Park it with the condition written down so the next review knows what to test.

The most frequent error is scoring the solution you want rather than the solution you have. Enthusiasm inflates technical scores. If one person has already built a prototype, the whole row drifts upward. Ask what would have to go wrong, then score again.

The second error is treating financial feasibility as a cost estimate. It is not. It is a judgement about whether the money is available and defensible given the expected gain. A cheap change with no sponsor can still score low. An expensive change with a committed budget can score high.

The third error is ignoring the risk note. In the sample, auto-routing scores five on every dimension yet still requires a policy change. A perfect score with an unaddressed condition is a trap. The note exists so the score does not have to carry the whole story.

Feasibility Assessment compares options. It does not validate benefit. Nothing in the sample data states how much time or money any of the four solutions saves. The ratings describe how deliverable each change is, not how valuable. You need your Measure phase baseline for that, and you need it before you commit to a pilot.

It also does not resolve interactions. The four options in the sample touch the same process. Capture, routing, matching and supplier input are connected. Delivering one may change the feasibility of another. The worksheet scores each row independently, so the sequencing judgement stays with you.

Finally, the scores are opinions made visible. A three is a group's view on a day, held by the people in the room. Change the people and the number can change. That is acceptable as long as you treat the output as a structured record of judgement rather than a measurement. The purpose is to make the reasoning behind a pilot decision legible, so that when the pilot runs you know exactly which assumption you are testing.