BA Success Stories

The Situation

A regional building society with 340,000 members received a regulatory notice requiring it to implement enhanced anti-money laundering controls within eighteen months or face significant sanctions. The existing customer onboarding process was entirely paper-based, with identity verification conducted manually by branch staff using a checklist that hadn't been updated in seven years. The compliance team estimated that meeting the new requirements through the existing manual process would require hiring forty additional staff — a cost the organisation couldn't absorb.

The initial brief to the BA team was narrow: document the requirements for an automated identity verification system. Within two weeks of discovery work, however, the lead BA had reframed the opportunity entirely.

The Analysis That Changed Everything

During stakeholder interviews, the BA noticed a consistent pattern. Branch managers, compliance officers, and customer service representatives all described the same underlying problem from different angles: the organisation had no single reliable source of truth for customer information. Customer records existed in six different systems — mortgage platform, savings accounts, current accounts, insurance policies, online banking, and a legacy CRM — none of which communicated with the others. Regulatory compliance was one symptom of a deeper data architecture problem.

The BA constructed a current-state process map that made this fragmentation visible for the first time. When a customer opened a new savings account, staff manually re-entered information already held in three other systems, creating data entry errors, inconsistencies, and the identity verification gaps the regulator had flagged. The same customer might have different addresses recorded across different systems, different names formatted differently, different correspondence preferences that weren't synchronised. The map showed forty-seven manual data re-entry touchpoints across the customer lifecycle.

Presenting this analysis to the executive team, the BA made a case that addressing only the compliance requirement would be expensive, disruptive, and would leave the underlying problem unresolved — the organisation would face the same issues in the next regulatory review. A broader customer data platform programme would cost more upfront but solve the compliance issue, eliminate operational inefficiency, and create a foundation for digital services that members increasingly expected. The executives agreed to fund the expanded scope.

Navigating the Complexity

The programme that followed involved six systems, twelve business areas, four technology vendors, and a regulatory deadline. The BA team's most critical contribution was maintaining requirements traceability throughout eighteen months of development. Every requirement linked back to either a regulatory obligation, a measurable operational improvement, or a documented member experience gap. When scope pressures mounted — as they inevitably did — this traceability matrix gave the programme team a principled basis for prioritisation rather than defaulting to whoever argued most loudly.

A significant challenge emerged eight months in when data migration analysis revealed that the historical customer records contained systematic errors introduced by a data entry system retired in 2011. Approximately 23,000 customer records had address fields stored in non-standard formats that automated migration tools couldn't process reliably. The BA worked with data engineers to design a hybrid approach: automated processing for clean records, a targeted manual remediation programme for problematic records, and clear exception handling for the small percentage that couldn't be resolved before go-live. This pragmatic approach prevented a potential three-month delay.

The Outcomes

The programme delivered regulatory compliance on time and created outcomes the original brief hadn't anticipated. Member onboarding time dropped from an average of forty-seven minutes to eleven minutes. Staff freed from manual data re-entry were redeployed to member-facing roles, improving service quality without additional headcount. The single customer view enabled the society to identify members who would benefit from product recommendations, generating £2.3m in additional revenue in the first twelve months. Customer satisfaction scores for account opening increased from 67% to 84%.

The compliance issue that had triggered the programme was resolved with six weeks to spare. The regulatory follow-up inspection noted the society's approach as an example of proportionate and thoughtful compliance implementation — acknowledging not just that they'd met the letter of the requirement, but that they'd addressed the underlying risk properly.

The Situation

A large NHS Trust was failing its eighteen-week referral-to-treatment target in orthopaedics, with average waiting times reaching twenty-six weeks and a backlog of 4,200 patients. Several consultants had proposed solutions: one wanted a new patient administration system, another argued for outsourcing referral triage to a private provider, and the clinical director wanted to hire two additional consultant surgeons. The medical director commissioned a BA to analyse the problem before committing to any solution.

The Analysis

The BA spent three weeks in clinical observation — attending outpatient clinics, shadowing administrative staff, accompanying patients through diagnostic appointments, and reviewing referral data. This immersion revealed that the waiting time problem had multiple independent causes, none of which matched the proposed solutions.

Referral data analysis showed that 34% of referrals to orthopaedics were for conditions that NICE guidelines indicated should be managed in primary care. These weren't complex cases being inappropriately referred — they were straightforward conditions that GPs were referring on because they lacked confidence in managing them without specialist support. The consultant proposing a new patient administration system hadn't considered this; better software would process inappropriate referrals more efficiently but wouldn't reduce them.

Clinic observation identified a different problem: appointment slot utilisation was running at 71%, with the gap caused by patients not attending appointments they'd accepted. Analysis of cancellation and non-attendance patterns showed that patients booked more than twelve weeks in advance had a non-attendance rate nearly four times higher than those booked within four weeks. The long waiting times were partly self-reinforcing — patients booked far in advance often either recovered, sought private treatment, or simply forgot.

A third issue emerged from following the post-appointment pathway. Patients requiring surgery waited an average of fourteen weeks between their initial consultant appointment and their surgery date, primarily because the process for surgical booking required three separate administrative steps across two different teams, each of which had its own queue. The current-state process map showed this as a critical path issue that added weeks to the patient journey without any clinical justification.

The Solution Design

Based on this analysis, the BA recommended three targeted interventions that addressed actual root causes rather than symptoms. First, a GP education programme supporting primary care physicians in managing common orthopaedic conditions, with clear referral criteria and advice-and-guidance access to specialist opinion without full referral — projecting a 28% reduction in referral volume. Second, a patient confirmation system requiring patients to confirm attendance four weeks before appointments, with rapid rebooking of released slots — projecting a 15% improvement in slot utilisation. Third, a streamlined surgical booking process consolidating three steps into one, with clear accountability for each stage — projecting a six-week reduction in the post-consultation waiting period.

Critically, none of the three originally proposed solutions — new software, outsourcing, or additional consultants — were included in the recommendations. The BA presented this directly to the medical director and the proposing consultants, acknowledging that the recommendations differed from their instincts but showing precisely why the evidence supported different interventions. This conversation required significant diplomatic skill as well as analytical confidence.

The Outcomes

Eighteen months after implementation, the Trust's orthopaedic waiting time had reduced from twenty-six weeks to fourteen weeks, with continued improvement projected to bring it within the eighteen-week target within a further six months. The backlog had reduced from 4,200 to 1,800 patients. Total programme cost was £340,000 — substantially less than the £2.1m estimated cost of hiring two additional consultant surgeons, whose capacity would not have addressed the underlying bottlenecks the analysis identified.

The programme became a reference case within the NHS region for evidence-based pathway redesign, and the BA involved was subsequently seconded to support similar analysis in two other specialties showing comparable waiting time challenges.

The Situation

A mid-sized clothing retailer with 85 stores and a growing online presence had built its digital channels entirely separately from its physical stores. The website ran on a different inventory system than the stores, meaning items shown as available online might be out of stock in the nearest store — and vice versa. Customers who wanted to return online purchases to stores discovered staff couldn't process the transaction. Loyalty points earned in stores didn't apply to online purchases.

The CEO had announced a public commitment to full omnichannel capability within eighteen months, energised by a competitor's successful launch of click-and-collect. Three separate technology projects had been initiated by different business units — e-commerce, stores operations, and IT — each attacking part of the problem independently. The BA was brought in when it became clear the three projects were heading in incompatible directions.

The Analysis That Identified the Real Risk

Initial stakeholder mapping revealed a problem more serious than technical incompatibility: the three project teams held fundamentally different models of what "omnichannel" meant for this retailer. The e-commerce team understood it as extending online capabilities into stores — customers should be able to order from the full online catalogue via in-store devices. Stores operations understood it as giving stores the ability to fulfil online orders — using store stock to reduce delivery times and costs. IT understood it as a single integrated platform replacing both existing systems.

Each model had merit, but they implied different data architectures, different technology investments, and different operating model changes. Without alignment on the target model, the three teams were building components that couldn't connect. The BA facilitated a structured workshop series with the three project teams and executive sponsors, using customer journey mapping as the common language. Rather than debating technology architecture, the teams mapped the experience they wanted customers to have across twelve different shopping scenarios — browsing online and buying in store, returning online purchases anywhere, checking stock availability before visiting, and so on — then worked backwards to what each scenario required of the underlying systems.

This approach achieved alignment that technical architecture discussions hadn't managed in three months. Once teams agreed on what customers should be able to do, the technology requirements became substantially less contentious.

Managing Change Alongside Requirements

The omnichannel programme required store staff to develop new capabilities alongside new technology. Store associates would need to process returns from online purchases, access customer purchase history across channels, and explain click-and-collect processes to customers — all skills that required training and changed job expectations. The BA identified early that the change management workstream was under-resourced relative to its importance and advocated successfully for dedicated change management support.

Working with the change team, the BA developed a store readiness assessment that evaluated each store's preparedness across technology, process, and people dimensions. This revealed that six stores had connectivity infrastructure insufficient for the new systems — a discovery that would have emerged expensively mid-rollout if not identified through systematic assessment. It also showed that the highest-volume stores, which were piloting the new capabilities first, had the lowest staff readiness scores, requiring additional training investment before the pilot launched.

The Outcomes

The omnichannel programme launched on schedule across all 85 stores, with click-and-collect available from day one. Six months post-launch, online revenue had grown 34% year-on-year as the enhanced customer experience drove conversion. Average order value for customers using both channels was 28% higher than single-channel customers, confirming the commercial case. Returns costs reduced by £1.2m annually as online returns processed in-store cost significantly less than postal returns. Customer satisfaction scores reached their highest recorded level.

Perhaps more importantly, the three technology projects that had been heading in incompatible directions were consolidated into a single coherent programme, eliminating approximately £800,000 in duplicated investment the fragmented approach would have generated.

The Situation

A local authority was migrating from an end-of-life housing benefits administration system to a modern cloud platform. The existing system had been in use for fourteen years, processed £47m in benefit payments annually, and was supported by just two contractors who held the institutional knowledge of its numerous customisations. The system vendor had announced end-of-support in twelve months. The stakes for getting the migration right were unusually high: errors in benefit processing affected residents who depended on the payments to meet housing costs.

The Complexity of Accumulated Rules

Initial discovery work identified what the BA described as "rule archaeology" — the need to uncover not just documented system behaviour but the accumulated policy decisions, legal interpretations, and edge case handling embedded in fourteen years of customisation. The system contained 340 business rules, of which only 187 had any documentation. The remaining 153 rules existed only as code, their purpose and policy basis unknown.

The BA developed a systematic approach to rule documentation that combined code analysis, staff interviews, and case review. For each undocumented rule, the team identified benefit claims that had triggered the rule, then interviewed the advisors who had processed those claims to reconstruct the policy decision the rule was implementing. This work took ten weeks but produced a complete policy and rules register that the authority had never previously possessed — a document of value independent of the migration.

The process also revealed three rules that were implementing policy positions the authority had formally changed but that the system had never been updated to reflect. These rules had been generating incorrect payment calculations for residents in specific circumstances for an indeterminate period. The BA escalated this finding immediately, and the authority undertook a case review that identified 47 residents who had been underpaid, triggering remediation payments. The migration project had inadvertently corrected a longstanding injustice.

Testing With Real Stakes

Testing strategy for the migration required particular care given the consequences of errors. The BA worked with QA engineers to develop a test strategy that used anonymised versions of real historical claims rather than synthetic test data. This approach, more complex to execute than standard testing, ensured that the test scenarios reflected actual claim complexity rather than idealised cases that passed easily but didn't represent reality.

Parallel running — processing claims simultaneously through both old and new systems before switching over — identified twelve calculation discrepancies. Nine were bugs in the new system's implementation of migrated rules. Two were cases where the old system had been applying rules incorrectly that the new system was applying correctly. One reflected a genuine ambiguity in policy guidance that required a formal policy decision before either system's approach could be validated as correct. This systematic comparison provided the evidence base for sign-off that the new system was calculating benefits accurately before any residents were affected.

The Outcomes

The migration completed four weeks before the end-of-support deadline, processing its first live claim without incident. The twelve months following migration saw a 23% reduction in benefit processing time, a 41% reduction in calculation error rates compared to the legacy system's final operating period, and a 67% reduction in appeals upheld against the authority's decisions. Staff reported that the new system's transparency — showing calculation steps rather than just results — made it significantly easier to explain decisions to residents and to identify and correct errors when they occurred.

The policy and rules register produced during discovery became a reference document for the authority's housing benefits team, cited in subsequent policy decisions as evidence of how the authority had historically interpreted ambiguous guidance. The BA received commendation from the authority's chief executive for the professionalism and thoroughness of the analytical work that underpinned a migration with zero resident impact.