Transformation

How to evaluate a transformation partner and a transformation design

A partner who cannot explain their design in plain English is a partner who does not own the risk. This checklist helps you tell the difference before you sign.

By Zakir Hoosen, Director, Fuzzelogic Solutions. Plain English guidance for business leaders.

A transformation partner is not a vendor. A vendor sells you software. A partner owns the outcome. The difference shows up in the design, not the pitch.

Most organisations evaluate transformation partners the wrong way. They compare feature lists. They compare price. They compare logos on a slide. None of those tell you whether the partner can deliver the change without stopping the business. The design tells you that.

"Ninety percent of companies have launched some flavor of digital transformation, and only a third of the expected revenue benefits, on average, have been realized." ::

That gap is not a technology gap. It is a design and delivery gap. The partner who designed the programme did not account for the business constraints. The partner who delivered it did not own the outcome after cutover. The evaluation should have caught both.

Fuzzelogic Solutions has been modernising banking, insurance, healthcare, retail, manufacturing, and government platforms since 2007. Nine regulated financial institutions sit among our clients. Platforms run on three continents. This article is the checklist we use when a new client asks us to evaluate a design, a vendor, or a programme.

What a good design looks like before you sign

A serious transformation partner gives you a written design before you commit. Not a slide with boxes and arrows. A document you can hand to an architect who does not work for the partner and get a coherent critique. If the partner cannot produce that, you are buying a pitch, not a design.

The design must answer seven questions. If any of them are missing, the design is incomplete.

Source: McKinsey, Rewired to Outcompete

frame 1. What is the pattern? Strangler fig, blue-green, parallel run, or phased cutover. The pattern must be named and justified against the downtime risk. 2. What is the first slice? One product, one channel, one plant, or one book. The slice must be bounded with success and stop criteria. 3. How does the data move? Field-level mapping, trial-load plan, reconciliation definition. The data movement is where most programmes fail. 4. How do you test? Testing gates with named people who can fail them. Not "we will test at the end". 5. How do you go back? Rollback design that is written, rehearsed, and timed. Named decision maker. Evidence required. 6. What is the timeline? Not a single date. A sequence of slices with decision points between them. 7. Who owns it after launch? Maintenance, support, and ongoing ownership. If the partner disappears after cutover, the programme is not complete. :::

If the partner cannot answer all seven, you are not ready to sign. You are ready to assess.

The evaluation checklist

Use this checklist before you approve a partner, a pattern, or a date. Share it with your architecture team, your risk committee, and your business owners. If the partner objects to the checklist, that is information.

Design quality

Is there a written design an architect who does not work for the partner can review?
Is the pattern named (strangler, blue-green, parallel, phased) and justified against downtime risk?
Is the first slice bounded, with success and stop criteria?
Is there a field-level data map, a trial-load plan, and a reconciliation definition?
Are testing gates real, with named people who can fail them?
Is rollback written, rehearsed, and timed?
Is the three-year cost of staying versus moving based on your numbers, not a brochure?

Partner capability

Has the partner delivered a similar transformation in your industry? Not a similar technology. A similar industry with similar constraints.
Can the partner explain the design in plain English, without jargon, to a business owner who does not work in IT?
Does the partner stay after launch, or disappear at cutover?
Does the partner have a named team, or "resource allocation" that changes every sprint?
Can the partner show you a reference client who will say the programme delivered what was promised?

Risk and governance

Is there a named person on the partner side who can halt the programme?
Is there a named person on your side who can halt the programme?
Is the regulatory environment accounted for before cutover, not after?
Is the security design reviewed before the data moves?
Is the operational runbook rehearsed before cutover?

Value and measurement

Is the baseline measured before the transformation starts?
Is the improvement measured after each slice?
Is the three-year cost of ownership compared honestly, including maintenance?
Is the business owner accountable for using the new capabilities, not just the IT team?
Is the programme designed to deliver value in slices, or all at once at the end?

If you cannot tick those, you are not ready to sign. You are ready to assess.

Red flags in a partner proposal

Some proposals tell you what you need to know before you sign. Watch for these.

"We will figure it out during delivery." The design is incomplete. If the partner does not know how the data moves before they start, they are learning on your budget.

"The cutover is a single weekend." It concentrates all risk into one night. A partner who recommends a big-bang cutover without explaining why is not designing for your risk.

"Rollback is simple." If the partner cannot describe the rollback in detail, with timing and evidence requirements, they have not designed it.

"We will train the team at the end." Training at the end is too late. The team needs to know what the new system can do before the cutover, not after.

"The old system will be decommissioned in three months." If the old system is the system of record, three months is optimistic. Ask for the run-off plan.

"We have done this a hundred times." Ask for a reference in your industry, with your constraints. A hundred implementations in SaaS do not prepare you for a core replacement in banking.

"67% of enterprise AI programs exceeded first-year budget." ::

Transformation programmes overshoot for the same reasons: the data work was underestimated, the integrations were not listed, and the process change was treated as someone else's problem. The evaluation should catch these before you sign, not after.

The fixed-price assessment as an evaluation tool

The best way to evaluate a transformation partner is to buy a fixed-price assessment before you commit to the full programme. Two to four weeks. Fixed price. You own the verdict and the roadmap whether or not you build any of it.

The assessment tells you three things. First, whether the transformation is justified. Second, what the actual design looks like, in writing, with the data movement and the rollback. Third, whether the partner can explain it in plain English.

If the assessment produces a design you can hand to an independent architect and get a coherent critique, the partner is worth considering. If the assessment produces a slide deck with boxes and arrows, the partner is selling, not designing.

Fuzzelogic Solutions offers this assessment at a fixed price. You own the verdict and the roadmap whether or not we build any of it. That is not a sales tactic. It is the honest way to evaluate a transformation before you commit.

The assessment also tells you whether the partner can work with you. A two-to-four-week engagement at a fixed price is a low-risk way to test the relationship. If the partner cannot deliver a clear, written design in that window, the full programme is unlikely to be better.

What the assessment should produce

A serious assessment produces three deliverables. If any of them are missing, the assessment is incomplete.

Source: Infosys, AI Tokennomics

frame 1. A written design. Pattern, first slice, data movement, testing gates, rollback, timeline, post-launch ownership. All seven elements, not a subset. 2. A cost comparison. Three-year cost of staying versus three-year cost of moving, including maintenance, training, and the cost of a failed cutover. Your numbers, not a brochure. 3. A verdict. Is the transformation justified now, later, or not at all? If the honest answer is "not now", say so. Maintenance is a valid project. :::

The assessment should also produce a set of risks. Not a list of generic risks. The specific risks for your programme, with named owners and mitigation plans. If the assessment does not mention the risks, the assessment is incomplete.

How to compare partners

Do not compare feature lists. Compare designs.

Ask each partner for a written design for your specific transformation. Not a generic proposal. A design that accounts for your data, your integrations, and your constraints.
Give the design to an independent architect. Ask them to critique it. If the design cannot survive a critique, it is not ready.
Ask each partner to explain the design in plain English to a business owner. If the business owner does not understand it, the design is not clear enough.
Ask each partner for a reference in your industry. Not a similar technology. A similar industry with similar constraints.
Ask each partner what happens after cutover. If the answer is "we move to the next project", the partner is a vendor, not a partner.
Ask each partner what happens if the programme needs to stop. A partner who can pause and reassess honestly is worth more than one who pushes through regardless.
Ask each partner for their failure stories. A partner who has never had a programme stop or pivot is either lying or has not done enough work.

The partner who produces the clearest design, explains it the best, and stays after launch is the partner you should choose. The partner who produces the fanciest slide deck is the partner who will disappear after cutover.

The evaluation scorecard

Use this scorecard to compare partners side by side. Rate each category from 1 (poor) to 5 (strong). The partner with the highest score is not automatically the right choice. The partner with the highest score in the categories that matter to your programme is.

Design quality (25%): Written design, pattern justified, data movement mapped, rollback rehearsed.
Industry understanding (20%): Reference in your industry, understands your constraints, speaks your language.
Delivery model (20%): Working slice in 12-16 weeks, phased cutover, honest timeline.
Post-launch ownership (15%): Maintenance, support, ongoing modernisation. Stays after cutover.
Communication (10%): Explains in plain English, keeps you informed, flags risks early.
Price (10%): Honest pricing, no hidden costs, fixed-price assessment available.

If a partner scores below 3 in design quality or industry understanding, the other categories do not matter. Those are the foundations. Everything else is built on top.

Start with the design, not the pitch

The transformation opportunity is real. The cost of staying on the old system is real. The cost of a bad partner is also real. The difference is a design you can review, a partner who can explain it, and a checklist that catches the gaps before you sign.

Start with the assessment. Two to four weeks, fixed price, and you own the verdict and the roadmap whether or not we build any of it. When you are ready to talk software, maintenance, or AI, call Fuzzelogic Solutions and ask for Zak.

Frequently Asked Questions

How do we evaluate a transformation partner?

Ask for a written design for your specific transformation. Give it to an independent architect. Ask the partner to explain it in plain English. Ask for a reference in your industry.

What should a transformation design include?

The pattern, the first slice, the data movement, the testing gates, the rollback, the timeline, and the post-launch ownership. All seven, not a subset.

How long should a transformation assessment take?

Two to four weeks at a fixed price. You own the verdict and the roadmap whether or not you build any of it.

What if the partner cannot explain the design in plain English?

The design is not clear enough. If the partner cannot explain it to a business owner, the business owner cannot challenge it.

What is the difference between a vendor and a partner?

A vendor sells you software. A partner owns the outcome. The difference shows up after cutover, not before.

How do we start?

A fixed-price assessment over two to four weeks. You own the verdict and the roadmap whether or not we build any of it.

What if we choose the wrong partner?

The assessment is the low-risk way to test the relationship. If the partner cannot deliver a clear design in two to four weeks, the full programme is unlikely to be better. You own the verdict and the roadmap.

www.FuzzelogicSolutions.com | info@FuzzelogicSolutions.com | +44 (0)1624 618950

Zakir Hoosen, Director Suite 1B, 11 Circular Road, Douglas, Isle of Man IM1 1AF +44 (0)7624 482071 | +44 (0)1624 618950

Start with the assessment

Two to four weeks, fixed price, and you own the verdict and the roadmap whether or not we build any of it.

Get in touch

When you are ready to talk software, maintenance, or AI, call Fuzzelogic Solutions and ask for Zak.