During Analysis
A conflicting requirement caught in a workshop costs a conversation and a decision. Relative cost: 1×.
Digital transformation at a financial services firm: how comprehensive stakeholder alignment through structured workshops identified conflicting requirements early, preventing costly downstream changes in a major CRM implementation programme.
A mid-sized financial services firm — roughly 2,400 employees across retail banking, wealth management, and commercial lending — had committed to replacing three ageing customer systems with a single cloud CRM. The board had approved a £6.4M budget and an eighteen-month timeline. By the time we were brought in, the programme was four weeks from signing the implementation statement of work, and every business unit was confident their requirements were "obvious".
They were not obvious. They were contradictory. Retail banking wanted a streamlined contact record optimised for high call volumes. Wealth management needed deep relationship hierarchies linking individuals, trusts, and corporate entities. Commercial lending wanted the CRM to act as a lightweight credit-decisioning hub. Each unit had described its needs in isolation, and the proposed configuration could not satisfy all three without significant custom development that nobody had scoped.
The original cost of those undiscovered conflicts, had they surfaced during build or — worse — after go-live, was conservatively estimated at £2M in rework, re-licensing, and delayed benefits realisation.
Requirements conflicts are cheapest to fix before a line of configuration is written. The further they travel down the delivery pipeline, the more they cost to unwind — because every downstream decision is built on the flawed assumption.
A conflicting requirement caught in a workshop costs a conversation and a decision. Relative cost: 1×.
The same conflict caught mid-configuration means reworking data models, integrations, and test scripts. Relative cost: 10–20×.
Discovered in production it means migrations, retraining, regulatory exposure, and lost trust. Relative cost: 50–100×.
This firm was about to skip elicitation almost entirely, because three confident business units mistook internal clarity for cross-functional agreement. That is the most common and most dangerous failure mode in transformation work: every stakeholder is right within their own boundary, and nobody owns the seams between them.
We paused the statement of work — the single most contentious decision of the engagement — and ran a focused elicitation programme designed to surface conflict deliberately rather than discover it accidentally.
Before any requirements were discussed, we mapped who actually touched the customer record across all three units, and the end-to-end journeys they served. This established a shared vocabulary — a "customer" meant three different things, and naming that gap took the heat out of later disagreements.
Rather than interviewing units separately, we put all three in one room with their requirements on the wall simultaneously. Within two hours, eleven hard conflicts were visible — the contact-record model, the relationship hierarchy, and the credit-decision data being the three most material.
Each conflict was framed as an explicit decision with options, costs, and owners. We used MoSCoW prioritisation and a weighted scoring model so that "we'd like that" was separated from "we cannot operate without that". Three requirements were de-scoped on the spot once their true cost was visible.
We replayed the agreed configuration back as user-journey walkthroughs, not documents. Stakeholders signed off against scenarios they recognised, which is far more reliable than signing off a 90-page requirements specification nobody reads.
This was not a tidy success. Two things nearly derailed it, and they are worth more than the wins.
The pause was politically toxic. Delaying the statement of work by three weeks read, to a nervous sponsor, like the programme slipping before it had started. We only held the line by reframing the workshops as de-risking the £6.4M already committed rather than as additional delay. Quantifying the avoided rework — even as a rough estimate — was what kept the room engaged.
The wealth-management hierarchy was underestimated. Even after the workshops, we initially scoped the entity-relationship model too simply. It was only during validation walkthroughs that a trust-accounting edge case surfaced. Catching it there still cost roughly £40K to re-model — a reminder that even good elicitation is iterative, not a single clean pass.
Learning happens more through near-misses than through smooth executions. The trust-accounting gap is the detail this team still references years later.
The programme delivered on its revised timeline — the three weeks were absorbed by efficiencies elsewhere because the build phase ran with far fewer change requests. Post-implementation, the change-request log carried 60% fewer requirements-related items than the firm's previous comparable programme. The CRM went live across all three units within the original eighteen-month envelope.
Seven techniques for running the kind of high-stakes elicitation sessions described here when stakeholders are remote.
Read Article →The elicitation and prioritisation techniques that underpin this case study, mapped to BABOK knowledge areas.
Read Article →Download the elicitation, prioritisation, and stakeholder-mapping templates used in engagements like this one.
Browse Templates →Practical, anonymised case studies and techniques you can apply on your next programme — delivered to your inbox.