If you are currently building a business case and need a worked example to guide you through the structure, this article is written for exactly that moment. A good example of business case analysis does not just show you what sections to include; it shows you how the reasoning flows, where decisions get complicated, and how to make a coherent recommendation when the options are genuinely close. I have written and reviewed business cases across government, utilities, health, and enterprise environments over 25 years, and the ones that hold up under scrutiny follow a disciplined, repeatable structure. The walkthrough below reflects that.
If you are also looking for a reusable structure to work from, the Business Case Template: Structure, Examples and What Works article on this site covers the format in detail. What I want to do here is show you the analysis in motion, not just the skeleton.
The Scenario: A CRM Replacement Decision
I will use a composite scenario drawn from real engagements, with identifying details replaced. Organisation A is a mid-sized service organisation that has been experiencing declining customer satisfaction over two years. Internal surveys point to slow response times and fragmented customer data as the primary causes. The current system is a legacy on-premise platform that front-line staff find cumbersome and that the IT team can no longer support effectively. The organisation needs to decide whether to upgrade, replace, or outsource its customer relationship management capability.
This is a genuine decision with real cost, real risk, and real disagreement between stakeholders. That is what makes it a useful example.
Step 1: Define the Problem Clearly
Business case analysis starts with a sharp problem statement, not a solution. In this case, the problem is that customer satisfaction scores have fallen 18 percentage points over two years, directly linked to response time and data quality issues. The legacy system cannot integrate with newer service tools, and manual workarounds have increased handling time by an average of 11 minutes per interaction.
I always push hard on this step because sponsors frequently arrive with a solution already in mind. In this engagement, the executive sponsor arrived in the first meeting declaring that the organisation needed Salesforce. My job was to make sure the business case tested that assumption rather than simply justified it.
Step 2: Market and Strategic Context
A credible business case situates the decision in its external environment. Cloud-based CRM platforms have become the dominant model in this sector, offering faster deployment, lower infrastructure cost, and better integration with service automation tools. Comparable organisations had adopted modern CRM solutions and measurably improved customer satisfaction within 12 to 18 months of go-live. Staying with the current system was not a neutral choice; it was a decision to fall further behind.
Strategically, the replacement initiative aligned with three organisational priorities: improving customer experience, advancing digital maturity, and reducing operational cost. It also sat directly on the three-year IT transformation roadmap, which meant budget visibility was already partially established.
Step 3: Options Considered
Three options were assessed in full. A fourth option, building a custom in-house CRM, was discarded early after a scoping exercise showed it would require 18 months of development and $2.4 million in build cost before any functionality was available to users. Repurposing an existing ERP module was also rejected because it lacked core CRM functionality and would have required $800,000 in customisation with no vendor support pathway.
The three options taken forward were:
- Option A: Upgrade the existing system. Extend the life of the current platform through a vendor-supported upgrade, improving performance without replacing the architecture.
- Option B: Implement a new cloud-based CRM. Replace the existing system with a modern SaaS CRM platform, fully integrated with the current Microsoft 365 environment and service automation tools.
- Option C: Outsource CRM services. Contract a third-party managed service provider to deliver CRM capability, removing the need for internal infrastructure management.
Step 4: Cost and Benefit Comparison
The table below summarises the financial and strategic comparison across the three options over a five-year horizon.
| Criteria | Option A: Upgrade | Option B: New Cloud CRM | Option C: Outsource |
|---|---|---|---|
| Estimated 5-year cost | $1.1 million | $1.8 million | $2.3 million |
| Expected satisfaction improvement | Low (5 to 8%) | High (18 to 25%) | Medium (10 to 14%) |
| Integration with existing tools | Partial | Full | Limited |
| Scalability for future growth | Low | High | Medium |
| Internal change complexity | Low | High | Medium |
| Regulatory compliance readiness | Partial | Full | Dependent on vendor |
| Recommended | No | Yes | No |
Option B costs more upfront but delivers the strongest return, the best integration capability, and the only path to full regulatory compliance without dependency on a third party. Option A looked attractive on cost alone, but the upgrade would extend the life of an architecture the vendor had already signalled it was winding down support for. Option C transferred operational risk without eliminating it.
Step 5: Stakeholder Impact Analysis and Where It Got Complicated
This is where the example of business case analysis becomes genuinely instructive, because the analysis did not run smoothly.
I identified four primary stakeholder groups and mapped their position using a stakeholder analysis approach before the business case was drafted.
- Customer service team. Major process change and retraining required. High engagement throughout system selection and testing was essential to avoid resistance at go-live.
- IT department. Responsible for integration, data migration, and ongoing support. Consulted from the outset on technical feasibility and architecture fit.
- Customers. Would experience faster and more consistent service, but needed proactive communication to manage expectations during the transition period.
- Executive leadership. Primarily interested in reporting visibility and cost justification. Required monthly governance updates rather than detailed involvement.
The friction came from the IT department. Halfway through the business case development, the IT lead formally objected to Option B on the grounds that the proposed cloud platform would not integrate cleanly with a legacy authentication system the organisation was not yet ready to retire. This was a legitimate technical constraint that had not surfaced in initial scoping conversations.
Rather than burying the objection, I brought it into the business case explicitly. We revised the cost model to include an identity management middleware layer at an additional $95,000, and the IT lead confirmed in writing that this resolved the integration concern. The recommendation remained Option B, but the business case was now honest about the full cost and the dependency. The sponsor was initially frustrated that the cost had increased, but accepted the revision once I walked through what would have happened had we discovered the gap post-contract. That conversation matters. A business case that papers over known constraints does not survive contact with implementation.
Step 6: Risk Assessment
Every option carried risk. For Option B, the key risks were implementation complexity, data migration quality, and user adoption. Each was assessed for likelihood and impact, with mitigation strategies attached. The data migration risk was rated high, given that the legacy system held seven years of customer interaction data in a non-standard format. The mitigation was a dedicated data cleansing workstream prior to migration, estimated at $45,000 and eight weeks of effort.
Risk assessment in a business case is not a formality. I have seen projects approved on the basis of business cases that listed risks without mitigation costs, then watched those same projects absorb those costs unplanned six months later. If a risk has a mitigation, include the cost. If it does not, say so and explain why the organisation should accept it.
Step 7: Assumptions, Dependencies, and Compliance
The business case explicitly stated the assumptions it rested on: that the chosen vendor’s pricing would remain stable for the contract period, that internal IT resources would be available to support the integration workstream, and that the data cleansing workstream would be completed before migration commenced. Each assumption was owned by a named role.
On compliance, the replacement system was required to meet data protection obligations applicable to customer personal information, including storage location, access controls, and audit logging. This was a non-negotiable filter applied to all shortlisted vendors before the options were formally assessed. Compliance considerations of this kind belong in the business case, not in a separate technical document that decision-makers may never read. For a deeper look at how to document solution-level constraints like these, the article on Solution Assessment Criteria: How to Develop a Recommendation for the Implementation of a System is worth reading alongside this one.
Step 8: The Recommendation and What Comes After
The recommendation was Option B: implement a new cloud-based CRM system. The total five-year cost including the middleware addition was $1.895 million, against a projected benefit of $3.2 million in operational efficiency gains and reduced customer churn over the same period. The net benefit position was positive, the strategic alignment was strong, and the risks were documented with credible mitigations.
The business case also included a benefit realisation plan with named owners, measurement points at six and twelve months post go-live, and a post-implementation review scheduled for eighteen months. A governance structure was defined, with a steering committee meeting monthly and a business case owner accountable for tracking benefit delivery. These sections are not decorative. They are what distinguishes a business case that drives action from one that sits in a shared drive.
Writing a strong business case is one of the most consequential analytical tasks in the BA role, and the quality of the example of business case analysis you produce reflects directly on your credibility as an analyst. The moment the IT objection surfaced in this engagement, the instinct might have been to minimise it or defer it to implementation. Choosing instead to resolve it inside the business case, at the cost of a revised figure and an uncomfortable sponsor conversation, produced a document that could actually be trusted. That trust is what gets business cases approved and, more importantly, what gets them implemented.
Frequently asked questions
What should a business case analysis include?
A business case analysis should include a clear problem statement, market and strategic context, a shortlist of options with costs and benefits compared, a risk assessment with mitigations, stakeholder impact analysis, compliance considerations, and a clear recommendation with a benefit realisation plan. Each section should be linked to evidence rather than assertion. The document should be readable by a decision-maker who was not involved in the analysis.
What is the difference between a business case and a business case analysis?
A business case is the document that presents the justification for a decision. Business case analysis is the structured process of developing and evaluating that document, including gathering data, assessing options, engaging stakeholders, and testing assumptions. In practice, the two terms are often used interchangeably, but the analysis is the work that makes the business case credible.
How long should a business case analysis take to produce?
The time required depends on the size and complexity of the initiative. A straightforward technology replacement decision might take two to four weeks of analytical effort. A major capital investment or organisational change programme could take two to three months. Cutting the timeline usually means skipping stakeholder engagement or risk assessment, which are the steps most likely to surface problems before they become expensive.
What is an example of a business case analysis in practice?
A practical example is an organisation evaluating whether to upgrade an existing CRM system, replace it with a cloud-based platform, or outsource the function entirely. The analysis compares costs, benefits, integration capability, risk, and strategic fit across all options, then makes a documented recommendation with a benefit realisation plan attached. The worked example in this article follows exactly that structure, including a stakeholder objection that required the cost model to be revised mid-analysis.
What makes a business case analysis fail?
Business case analyses most commonly fail when they are written to justify a decision that has already been made rather than to test it, when risks are listed without mitigation costs, or when stakeholder concerns are deferred to implementation rather than resolved during analysis. A business case that a decision-maker cannot trust will not be approved, and one that papers over constraints will not survive implementation.
Try Ash, Your Virtual BA
If you are working through a business case right now and need support structuring your options, sharpening your cost-benefit reasoning, or drafting the recommendation section, Ash can help you move faster and with more confidence. Ash is built specifically for BA work, which means it understands the difference between a problem statement and a solution statement, and it will push back on vague assumptions the same way a senior BA would. Try Ash Virtual BA and get your business case analysis moving today.
Further reading
- Business Analysis Case Study Examples and Solutions | In the life of a BA | IIBA
- Business Case for Business Analysis
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.