If you are sitting in front of a half-built business case right now, wondering how to move from a list of options to a credible, evidence-based recommendation, this article is for you. Business case analysis is not an academic exercise. It is the practical work of defining what problem you are solving, comparing realistic options, quantifying what each one costs and delivers, and presenting a case that decision-makers will actually act on. I have built business cases across government, utilities, health, and enterprise environments over 25 years, and the ones that failed were not missing data. They were missing structure and honest treatment of the hard bits.
The steps below follow the sequence I use on live projects. I will use a worked example throughout: an HRMS selection for a mid-sized organisation I will call Organisation A, where the business case analysis ran into significant resistance from the IT director before it was resolved. If you are working on a business case template and need to understand how to populate each section with real analysis, this walkthrough will give you that.
Step 1: Define the Problem Precisely
The most common mistake I see in early-career BA work is starting the analysis before the problem is properly defined. Organisation A’s HR team described their issue as “the system is outdated.” That framing is not enough to build a case on. When I pushed further, the actual problems were specific: payroll runs were taking two days longer than industry benchmarks due to manual reconciliation steps, employee records were duplicated across three separate spreadsheets maintained by different teams, and the recruitment module had not been updated in four years and could not integrate with the job boards the business was using.
A precise problem statement gives you two things. First, it sets the baseline you will measure improvement against. Second, it limits scope creep by making clear what the analysis is and is not trying to solve. In this case, the defined problem was: the existing HR system cannot support the organisation’s current operational scale, resulting in measurable inefficiency in payroll processing, data integrity failures, and an inability to attract candidates through modern recruitment channels.
Step 2: Establish the Success Criteria Before You Evaluate Anything
Before looking at a single vendor or option, I work with stakeholders to agree on what success looks like. This step protects the integrity of the analysis. If you let the options shape the criteria, you end up reverse-engineering a justification rather than conducting genuine analysis.
For Organisation A, the success criteria were agreed with the HR director and the CFO before any vendor was named:
- Reduction in payroll processing time: The new solution had to cut the two-day overrun to same-day completion within six months of go-live.
- Single source of truth for employee records: All employee data had to be held in one system with no manual synchronisation between spreadsheets.
- Integration with current recruitment platforms: The system had to connect to at least the three job boards the business used most frequently.
- User satisfaction improvement: HR staff satisfaction with system usability, measured by a post-implementation survey, had to improve by at least 30% against the baseline score.
- Reporting capability: Line managers needed self-service access to headcount and absence data without submitting requests to HR.
Agreeing these criteria upfront also meant that when pushback came later, I had a documented baseline to refer back to. That became important.
Step 3: Identify and Analyse the Alternatives
A business case analysis with only one option is not an analysis. It is a pitch. You need at least two realistic alternatives, and often three. For Organisation A, the three options were: do nothing and maintain the existing system with manual workarounds, upgrade the existing system with additional modules from the incumbent vendor, or replace the system entirely with a modern HRMS platform.
I assessed each option against the agreed success criteria and looked at vendor capability, implementation complexity, and the realistic effort required from the organisation’s own IT and HR teams. The upgrade option, which the IT director initially favoured strongly, emerged as problematic. The incumbent vendor confirmed in writing that the integration with modern recruitment platforms was not on their product roadmap for the next 18 months, and the payroll reconciliation issue required custom development at an additional cost of $47,000 with no performance guarantee.
This is where the friction hit. The IT director pushed back hard on the replacement option, citing implementation risk and the disruption of migrating six years of employee data. His concern was legitimate. I did not dismiss it. Instead, I documented it as a risk in the analysis and commissioned a data migration scoping exercise from one of the shortlisted vendors so we had an actual estimate rather than a fear. That changed the conversation.
Step 4: Quantify Costs and Benefits for Each Option
This is the section that carries the most weight with finance leads and senior executives. Vague benefit statements like “improved efficiency” will not survive scrutiny. Every benefit needs to be tied to a measurable outcome and, where possible, a dollar value.
| Cost / Benefit Item | Upgrade Existing System | Replace with New HRMS |
|---|---|---|
| Implementation cost | $62,000 | $95,000 |
| Custom development (payroll fix) | $47,000 | $0 (native feature) |
| Annual licence and support | $28,000 | $34,000 |
| Training cost (Year 1) | $8,000 | $14,000 |
| Total Year 1 cost | $145,000 | $143,000 |
| Estimated annual saving (payroll efficiency) | $18,000 | $41,000 |
| Estimated annual saving (reduced manual reconciliation) | $6,000 | $22,000 |
| Recruitment channel integration benefit | Not achievable within 18 months | Available at go-live |
| Payback period | 4.8 years (estimated) | 2.3 years (estimated) |
The numbers told a clear story. The upgrade option looked cheaper at first glance but the custom development cost and the inability to solve the recruitment integration problem within a useful timeframe made it the weaker choice financially as well as operationally. Presenting this comparison in a table format rather than in prose was deliberate. Decision-makers can scan it. They can challenge individual lines. That transparency builds trust in the analysis.
For guidance on how to connect this cost-benefit work to the wider solution evaluation process, the article on solution assessment criteria covers how to structure the recommendation section of your business case once the numbers are in place.
Step 5: Present the Recommendation With Evidence
The recommendation is not the end of the analysis. It is the point where the analysis has to be defended. When I presented the findings to the executive team at Organisation A, the IT director raised his data migration concern again, this time in front of the CFO and HR director. I had anticipated this and included the vendor’s scoping estimate in the appendix: the migration was quoted at $12,000 and four weeks of elapsed time, with the vendor taking contractual responsibility for data integrity. That evidence neutralised the objection without dismissing it.
The recommendation was to implement the new HRMS. The case was grounded in the agreed success criteria, the cost comparison, the benefit projections, and a documented risk register that included the IT director’s concerns alongside mitigations. The executive team approved it within two weeks of the presentation.
Step 6: Track Outcomes Against the Business Case
A business case analysis that stops at the decision has missed its last and most valuable step. I worked with the HR director to define the KPIs we would track post-implementation, mapped directly back to the success criteria agreed at step two. These included payroll run completion time measured weekly for the first three months, a data integrity audit at 30 and 90 days post-migration, and a user satisfaction survey at 60 days.
At 90 days, payroll was completing same-day in all but two instances, both of which were traced to a configuration issue in the leave accrual module that the vendor resolved in week eight. The user satisfaction score improved by 44%, above the 30% target. The data integrity audit found three duplicate records from the legacy system, all resolved manually within a day. The business case held up. That does not always happen, and when it does not, the tracking data tells you what to revisit.
This outcome tracking discipline connects directly to the broader practice of business process analysis, where measuring post-change performance against a pre-change baseline is what separates genuine improvement from optimism.
What Makes a Business Case Analysis Credible
After doing this work across dozens of projects, the difference between a business case that gets approved and one that gets sent back for more work usually comes down to three things. First, the problem definition is specific enough that you can measure whether you have solved it. Second, the cost and benefit figures are sourced and documented, not estimated from intuition. Third, the risks are named and addressed rather than minimised or ignored. If the IT director’s concern about data migration had been brushed aside rather than costed and responded to, the recommendation would have lost credibility at the executive presentation. Treating friction as part of the analysis rather than an obstacle to it is what makes the work trustworthy.
Frequently asked questions
What is business case analysis?
Business case analysis is the structured process of defining a problem, comparing realistic options, and quantifying the costs, benefits, and risks of each option to support a justified organisational decision. It produces a recommendation grounded in evidence rather than preference. The output is typically a business case document presented to decision-makers or a governance board.
What are the steps in a business case analysis?
The core steps are: define the problem precisely, establish success criteria before evaluating options, identify and compare realistic alternatives, quantify costs and benefits for each option, present a justified recommendation, and track outcomes against the original projections. Skipping the problem definition or success criteria steps is the most common cause of weak business cases. Each step builds directly on the one before it.
How do you quantify benefits in a business case?
Each benefit needs to be tied to a measurable outcome and, where possible, expressed as a dollar value or time saving that can be verified after implementation. For example, a reduction in payroll processing time can be calculated by multiplying hours saved per run by the hourly cost of the staff involved. Vague benefit statements like ‘improved efficiency’ will not survive scrutiny from finance leads or executives.
What is the difference between a business case and a business case analysis?
A business case is the document that presents the recommendation to decision-makers. Business case analysis is the analytical process that generates the content of that document, including the option comparison, cost-benefit modelling, and risk assessment. You need to complete the analysis before you can write a credible business case.
How do you handle stakeholder pushback during a business case analysis?
Document the concern formally rather than dismissing it, and address it with evidence. If a stakeholder objects to a proposed option on the grounds of risk, commission a scoping exercise or request vendor confirmation so you have actual data rather than competing opinions. Treating pushback as part of the analysis rather than an obstacle to it strengthens the credibility of the final recommendation.
Try Ash, Your Virtual BA
If you are working through a business case analysis right now and need help structuring the options comparison, drafting the cost-benefit section, or framing the recommendation for an executive audience, Ash can guide you through it step by step. Ash is built specifically for BA work, so it understands the difference between a genuine analysis and a dressed-up justification, and it will ask you the right questions to make your business case credible. Try Ash Virtual BA and get your business case moving today.
Further reading
- 3 tips for writing better business cases as a business analysis professional | IIBA®
- Business Analysis Technique: Business Case – Insight 1
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.