Whilst understanding the daily rhythm of business analysis provides valuable context, nothing illustrates the profession's true nature quite like examining real projects from initiation through delivery. The projects detailed in this section represent actual business analysis work, though details have been anonymised to protect client confidentiality. Each project demonstrates how BAs apply their skills to solve genuine business problems, navigate organisational complexities, and deliver measurable value. These case studies reveal both the structured methodologies and the adaptive problem-solving that characterise effective business analysis in practice.
A major retail bank operating across the United Kingdom had built its mortgage processing system in the early nineteen-nineties using proprietary mainframe technology. By twenty-twenty-three, this legacy system presented multiple critical problems. Processing times had increased to an average of eighteen days for mortgage approvals, compared to competitors completing the same process in seven to ten days. The technology stack required increasingly scarce mainframe expertise, with three of the bank's five mainframe developers approaching retirement. Integration with modern digital channels proved nearly impossible, forcing customers to complete paper applications despite the bank's digital transformation strategy. Regulatory reporting required extensive manual intervention, creating compliance risks and consuming significant analyst time.
The bank's executive team approved a three-year programme to replace the legacy mortgage system with a modern, cloud-based platform that would integrate seamlessly with the bank's digital channels, reduce processing times, improve customer experience, and position the organisation for future innovation. The programme budget exceeded twenty million pounds, making it the bank's largest technology investment of the decade. The business analysis challenge involved not just documenting requirements for the new system, but also understanding decades of embedded business logic, navigating complex stakeholder dynamics across multiple business units, and ensuring continuity of critical business operations throughout the transition.
The project began with a three-month discovery phase where a team of four business analysts, led by a senior BA with financial services domain expertise, worked to understand both the current state and the future requirements. This discovery work revealed that the apparent simplicity of "replace the mortgage system" masked extraordinary complexity. The legacy system actually comprised seventeen interconnected applications, each handling specific aspects of the mortgage lifecycle. Business rules that should have existed in documentation lived only in the minds of long-tenured staff or buried in thirty-year-old COBOL code. Different regions of the bank had developed their own variations of the mortgage process, creating eight distinct workflows that the new system somehow needed to accommodate or consolidate.
The BA team employed multiple elicitation techniques during discovery. They conducted forty-seven stakeholder interviews across mortgage processing, underwriting, customer service, compliance, technology, and senior management. These interviews revealed not just functional requirements but also the political landscape, where the London head office, regional processing centres, and branch networks all had different priorities and concerns about the replacement programme. The team facilitated twelve process mapping workshops, each focused on a specific aspect of mortgage processing. These workshops used BPMN notation to document current workflows, revealing inefficiencies that had accumulated over decades but also uncovered business logic that proved essential for regulatory compliance.
The data analysis component of discovery proved equally revealing. The BA team worked with data architects to analyse five years of transaction history from the legacy system, revealing patterns in application volumes, processing times, exception handling, and customer behaviour. This analysis showed that whilst the average processing time stood at eighteen days, median processing time was just eleven days—meaning a small number of complex cases skewed the average dramatically. Further investigation revealed that twenty-three per cent of applications required manual intervention due to incomplete data, system limitations, or exceptional circumstances. These findings significantly influenced solution requirements, suggesting that improving data quality and exception handling might deliver faster benefits than simply replacing the technology.
The discovery phase produced several critical deliverables that would guide the entire programme. A current state assessment documented the seventeen interconnected applications, their business functions, integration points, and dependencies. Eight regional process models captured how different parts of the organisation actually processed mortgages, revealing commonalities and variations. A stakeholder analysis mapped fifty-seven key stakeholders across six interest groups, assessing their influence, concerns, and communication preferences. A requirements catalogue organised into ten business capability areas provided an initial structure for the detailed requirements work that would follow. Perhaps most valuably, a risks and issues register identified twenty-three significant concerns ranging from data migration challenges to organisational change resistance, allowing the programme team to develop mitigation strategies proactively.
Following discovery, the BA team entered a six-month requirements analysis phase where they translated business needs into detailed specifications that would guide solution design and development. This phase required constant navigation between competing demands. Business stakeholders wanted the new system to replicate all current functionality whilst adding new digital capabilities. Technology architects advocated for a complete process redesign that would leverage modern architectural patterns. Compliance officers demanded extensive audit trails and controls that added complexity. Budget constraints meant not everything could be delivered in the initial release, requiring difficult prioritisation decisions.
The requirements analysis employed a structured approach aligned with BABOK knowledge areas. The team created forty-three high-level business requirements that described what the new system needed to achieve from a business perspective. These ranged from "the system shall support end-to-end digital mortgage applications" to "the system shall reduce average processing time to under ten days" to "the system shall provide real-time status visibility to customers and branches." Each business requirement traced to specific business objectives and success metrics, ensuring clear line of sight between solution capabilities and organisational value.
These high-level business requirements decomposed into three hundred eighty-seven detailed functional requirements. The BA team organised these requirements using a capability-based structure that aligned with the bank's enterprise architecture. Major capability areas included Application Management (capturing and managing mortgage application data), Risk Assessment and Underwriting (automated and manual decision-making), Document Management (collecting, verifying, and storing required documentation), Workflow and Case Management (routing applications through appropriate processing steps), Integration Services (connecting to credit bureaus, property valuation services, and internal systems), Reporting and Analytics (providing operational insight and regulatory reporting), and Customer Communication (providing status updates and requesting additional information).
Each functional requirement followed a structured template that included a unique identifier, description, business rationale, acceptance criteria, priority classification, and associated business requirement reference. This structure enabled requirements traceability whilst ensuring each requirement remained clear and testable. For example, a requirement in the Application Management capability read: "The system shall validate mortgage application data against business rules in real-time, providing immediate feedback to applicants about any missing or invalid information. Business rationale: Early validation prevents incomplete applications from entering the processing queue, reducing manual intervention and accelerating processing time. Acceptance criteria: All mandatory fields must be validated before submission is permitted; validation rules must be configurable without code changes; error messages must clearly indicate what correction is needed; validation response time must not exceed two seconds."
Non-functional requirements received equal attention, recognising that system performance, security, reliability, and usability would determine real-world success as much as functional capabilities. The BA team collaborated with technical architects to define requirements covering response time performance, system availability targets, data security and privacy controls, scalability parameters, regulatory compliance requirements, accessibility standards, and disaster recovery objectives. These non-functional requirements often required negotiation between ideal states and practical constraints. For example, the initial business request for "99.99% system availability" would have required infrastructure investment far exceeding budget, leading to a negotiated target of "99.9% availability during business hours with scheduled maintenance windows outside peak times." This pragmatic approach balanced business needs against cost realities.
Prioritisation emerged as one of the most challenging aspects of requirements analysis. The BA team employed the MoSCoW method, categorising requirements as Must Have (essential for initial release), Should Have (important but not critical for launch), Could Have (desirable if resources permit), and Won't Have (explicitly deferred to future releases). This categorisation involved extensive stakeholder consultation, as different groups had different priorities. Processing centre managers classified efficiency features as Must Have, whilst branch networks prioritised customer-facing capabilities, and compliance officers demanded that audit and control features receive highest priority.
The prioritisation process surfaced conflicts that required senior leadership adjudication. When the business stakeholders demanded a fully mobile-optimised application experience as Must Have whilst the technical team assessed this as a four-month additional effort that would delay the entire programme, the BA team prepared a decision paper that outlined the trade-offs, quantified the impacts, and presented options for executive consideration. This decision support role—helping leaders make informed choices about scope, cost, and timeline trade-offs—represented crucial BA value beyond simple requirements documentation.
The solution design phase overlapped significantly with requirements analysis, as the BA team worked with solution architects, UX designers, and development leads to determine how the new system would actually work. This phase required translating business requirements into implementation specifications detailed enough to guide development whilst remaining flexible enough to accommodate technical decisions that emerged during build.
The design work employed multiple techniques appropriate to different aspects of the solution. For process design, the BA team created twenty-six to-be process models using BPMN notation. These models showed how mortgage applications would flow through the new system, which steps would be automated versus requiring human decision-making, how exceptions would be handled, and where integration with external systems would occur. These process models became essential communication tools, helping business stakeholders understand how their work would change whilst giving developers clear specifications for workflow implementation.
For data design, the BA team collaborated with data architects to create a conceptual data model showing the key business entities and their relationships. This model identified entities like Applicant, Property, Mortgage Product, Application, Document, Decision, and Offer, showing how they related to each other and what information each entity needed to capture. The BA team then detailed the attributes for each entity, specifying data types, validation rules, mandatory versus optional fields, and business definitions. This data model served as the foundation for the technical team's database design whilst ensuring business concepts were correctly represented in the system.
User interface design required particularly close collaboration between BAs and UX specialists. The BA team created user stories describing desired functionality from different user perspectives. For example, "As a mortgage applicant, I need to save my application progress at any time so that I can complete it across multiple sessions without losing information." These user stories then informed the UX team's wireframe and prototype development. The BAs reviewed these designs to ensure they aligned with business requirements, providing feedback when proposed interfaces didn't support required functionality or when design decisions had business process implications. This iterative collaboration between business analysis and user experience design ensured the solution remained both technically feasible and genuinely usable.
Integration requirements demanded particular analytical rigour. The new mortgage system needed to integrate with seventeen existing bank systems plus six external services. The BA team documented each integration point, specifying what data needed to be exchanged, in what format, at what frequency, with what error handling, and with what security controls. This integration specification work revealed several cases where the new system's data needs couldn't be met by existing systems without modification, requiring careful negotiation about which systems would change and who would fund those changes. These cross-system dependencies represented one of the programme's highest risks, as delays in one integration could cascade across the entire implementation schedule.
During the eighteen-month implementation phase, the BA team's role shifted from requirements definition to requirements clarification, change management, and ensuring that what was being built remained aligned with what was needed. This phase demonstrated that requirements work doesn't end when development begins—rather, BAs continue adding value throughout implementation by bridging the gap between documented requirements and emerging development realities.
The implementation followed an agile approach with two-week sprints, though the overall programme maintained waterfall governance due to regulatory and organisational constraints. The BA team embedded members with each of three development squads, providing daily clarification on requirements, reviewing completed work against acceptance criteria, and identifying gaps between what was built and what was needed. This close collaboration prevented the common problem where developers build to their interpretation of requirements, only discovering late in testing that their understanding differed from business intent.
Change requests emerged continuously as stakeholders saw working software and refined their understanding of needs, as technical teams discovered requirement ambiguities, and as external factors like regulatory changes affected scope. The BA team managed a formal change control process, assessing each proposed change for impact on scope, cost, timeline, and existing requirements. They prepared impact analyses that helped programme leadership make informed decisions about which changes to accept, which to defer, and which to reject. This discipline prevented scope creep whilst ensuring legitimate changes received appropriate consideration.
Testing represented another critical BA contribution during implementation. The BA team created detailed test scenarios based on requirements, working with the quality assurance team to ensure test coverage matched business need. They participated actively in user acceptance testing, observing how business users interacted with the system, noting where the solution didn't meet expectations, and determining whether gaps represented requirements issues, build issues, or training needs. This testing involvement ensured that discovered defects received appropriate priority and that ambiguous test failures were investigated thoroughly rather than dismissed as user error.
The BA team also supported organisational change management, recognising that technology implementation alone wouldn't deliver benefits without corresponding process and behavioural changes. They worked with change managers to develop training materials, create job aids, and document new procedures. They participated in training sessions to answer business process questions and ensure training accurately reflected how the system should be used. They helped business areas prepare for cutover, identifying what needed to happen before go-live and what support would be required during the transition period. This holistic view of implementation—technology, process, people, and change—reflected mature business analysis that recognises solutions extend beyond software.
The new mortgage system launched using a phased deployment approach, beginning with a single regional processing centre as a pilot before rolling out nationally. This approach allowed the programme team to identify and resolve issues in a controlled environment before wider implementation. The BA team played crucial roles throughout deployment, providing on-site support at go-live locations, monitoring system performance and user feedback, and rapidly addressing issues that emerged.
Post-implementation support revealed both successes and challenges. The system delivered immediate benefits in several areas. Average processing time for straightforward applications fell to nine days within the first month, meeting the target of under ten days. Customer satisfaction scores increased by twelve points as applicants appreciated digital application capability and real-time status updates. Staff productivity improved as automated risk assessment reduced routine underwriting work by thirty-five per cent, allowing underwriters to focus on complex cases requiring expert judgement. Technical benefits also emerged, with system reliability exceeding targets at 99.94% availability and integration with digital channels enabling the bank to launch new mortgage products in days rather than months.
However, challenges also emerged. Complex applications involving multiple applicants, unusual property types, or non-standard employment situations still required significant manual intervention, with processing times averaging twenty-one days for these cases. Staff in regional processing centres struggled with the new system's different workflow, leading to initial productivity declines of fifteen to twenty per cent. Integration with one external property valuation service proved unreliable, requiring a backup manual process. Data migration from the legacy system revealed quality issues, with eight per cent of historical records containing errors or inconsistencies that required cleanup.
The BA team played a crucial role in addressing these post-implementation challenges. They worked with business operations to identify root causes of processing delays for complex cases, discovering that the business rules engine needed refinement to better handle edge cases. They collaborated with the training team to develop additional support materials addressing specific pain points regional staff experienced. They documented integration reliability issues and worked with technical teams to implement monitoring and automatic failover mechanisms. They prioritised data quality improvements and supported data remediation efforts. This continuing engagement ensured that identified issues received appropriate attention and resolution rather than being dismissed as teething problems.
Six months after final rollout, the BA team conducted a formal benefits realisation review, comparing actual outcomes against original business case projections. This review found that the programme had delivered seventy-three per cent of projected benefits in the first six months, with full benefits realisation expected by month twelve as staff productivity returned to baseline levels and system optimisations addressed remaining pain points. The review also identified unanticipated benefits, including reduced compliance risk due to improved audit trails, increased staff satisfaction with modern tools replacing legacy systems, and enhanced ability to introduce new mortgage products quickly. These findings validated the business case whilst providing transparency about where expectations hadn't been fully met and what additional work remained to realise full programme value.
This major system replacement project illustrated several important principles about business analysis in large-scale transformation programmes. The discovery phase's depth proved essential, revealing complexities that would have derailed the programme if discovered mid-development. The structured requirements process, whilst demanding significant time and effort, provided the foundation for coordinated development across multiple teams and vendors. The BA team's continued engagement during implementation prevented the common problem where requirements are "thrown over the wall" to developers, then BAs disengage until testing begins. The phased deployment approach allowed course correction before full rollout, reducing risk and improving final outcomes.
The project also revealed areas where the BA approach could have been more effective. Earlier and deeper engagement with regional processing centres might have surfaced workflow concerns before design was finalised. More extensive prototyping of complex application scenarios would have identified business rule refinements needed before development. Greater emphasis on data quality assessment during discovery would have allowed data remediation to begin earlier. These reflections informed how the BA team approached subsequent projects, demonstrating the learning and continuous improvement that characterises mature business analysis practice.
Move from project walkthroughs to a deep look at sector-specific BA practice across financial services, healthcare, retail, and more.