Building the business case for Halo ITSM — and proving it delivered

For most experienced IT leaders, the technical evaluation of an ITSM platform is the more manageable challenge. Vendors publish capability documentation. Analysts produce comparative assessments. The question of which platform fits the organisation's requirements is answerable with sufficient diligence.

The harder question is how to make that case compellingly to the people who control the budget and carry accountability for organisational outcomes — and then, once the project is done, how to prove that the investment delivered what it promised.

This guide covers both. Most internal business cases address the first and ignore the second. The ones that build lasting organisational confidence do both.

Know your audience before you write a word

A business case written to satisfy one stakeholder at the expense of the others will consistently produce partial support at best. Before any section is drafted, be precise about who must be persuaded and what actually drives their assessment.

The strongest cases make the core argument accessible to all of these stakeholders while providing the depth each needs to evaluate with confidence. Write for the room, not just the person holding the budget.

Start with the problem, not the platform

The most predictable failure mode in technology business cases is leading with the solution — the platform, its capabilities, its commercial terms — before establishing that the current state is genuinely untenable.

Senior decision-makers who have not experienced the daily limitations of the incumbent system do not share the intuition of those who have. They are assessing a request to invest significantly and absorb material organisational disruption. If the business case does not establish, with specificity, that the cost of the status quo exceeds the cost of change, it is asking for approval without a compelling reason to grant it.

Build the current-state analysis on three categories of evidence:

• Operational dataManual process volumes that a new platform would automate, time lost to workarounds, error rates caused by tooling limitations, SLAs constrained by system capability rather than team performance.
• Financial dataThe direct cost of the incumbent platform plus the indirect cost of the inefficiencies and workarounds it generates. Both are usually underrepresented in approval requests.
• Specific operational consequencesNot "the system creates inefficiency" — but "the monthly billing reconciliation requires three people half a day because the platform cannot produce the output finance needs." Specificity is credibility. Generalised claims are routinely discounted.

The cost of doing nothing

Decision-makers are not choosing between spending and not spending. They are choosing between two cost structures. A business case that quantifies the investment required without quantifying the cost of inaction presents a fundamentally incomplete picture.

Frame three categories of inaction cost explicitly. Direct operational costs — the time absorbed by manual processes that automation would eliminate, rework generated by data quality limitations, support overhead from process gaps. Strategic costs — capability constraints that limit what the organisation can achieve: if ITSM tooling inadequacies prevent the visibility and governance leadership requires, that is a real cost even when it does not appear in an operating budget. Risk costs — compliance exposure in regulated environments, the operational risk created by aging systems, and integration limitations that increasingly constrain the broader technology architecture.

The longer the decision is deferred, the more embedded the workarounds become and the harder change gets. That compounding effect is worth naming.

Building the return on investment case

The financial case for an ITSM investment typically rests on three value pillars, each requiring a different analytical approach.

Total cost of ownership — present it before they ask

Experienced executives know headline licence costs are rarely the full picture. A business case that does not include a credible total cost of ownership will have that gap exposed in the approval process, which is a less favourable position than presenting it proactively.

A complete picture includes platform licensing, implementation costs (configuration, data, integration, and any external implementation partner engagement), training and change management investment — which is consistently under-budgeted and consistently consequential for adoption outcomes — and ongoing operational costs including platform administration and the organisational cost of managing updates. Presenting this comprehensively, even where the total is larger than the headline implies, signals the rigour that distinguishes a business case that earns trust from one that creates scepticism.

The implementation plan

Approvers are not just weighing cost against benefit. They are weighing confidence in delivery. A business case that treats the investment case in detail but gives one paragraph to the programme plan signals that delivery has not been thought through seriously.

Include a realistic timeline with clear phases and honest dependencies. State internal resource requirements plainly — this is frequently where business cases mislead, because the project needs IT bandwidth that is already fully committed. Be explicit about what is handled internally and what requires external support, and why. A plan that acknowledges constraints is more credible than one that pretends they do not exist.

Adoption — the section most business cases skip

Every experienced executive who has overseen a technology implementation understands, at some level, that the risk is not whether the system will function. It is whether the organisation will use it in the way the investment assumed.

A business case that does not address this directly leaves the most important question in every approver's mind unanswered. Describe the change management investment: how users will be engaged before go-live, how training is designed for different groups, what good adoption looks like and how it will be measured, and what the intervention plan is if utilisation is below threshold in specific teams.

This section also serves a second strategic purpose beyond satisfying approvers. It initiates the organisational conversation about adoption governance that needs to happen before the project begins — not after go-live, when the options for influence are considerably narrower.

The recommendation

The business case should conclude with a specific, unambiguous recommendation: this platform, this implementation approach, this timeline, at this total cost, delivering these defined outcomes. Not a presentation of options. Not an invitation to further deliberation. A recommendation, with the confidence that the supporting analysis warrants.

A sensitivity analysis covering the two or three scenarios most likely to affect the return — slower adoption, extended implementation timeline, lower-than-projected efficiency realization — demonstrates that projections are grounded in realistic assumptions. Showing you have stress-tested the base case is more persuasive than presenting only the base case.

Measuring ROI post go-live — closing the loop

Most internal business cases are written to secure approval and then filed. The organisations that build lasting confidence in their technology investments — and make every future case easier to approve — are the ones that close the loop: measuring whether the investment delivered what it promised, and reporting the results.

This requires four things to be in place before the project begins, not retrospectively.

• Capture baseline before you startYou cannot measure improvement without knowing where you began. Capture current-state metrics during the business case phase — process volumes, time expenditures, error rates, SLA performance. If you wait until after go-live, the baseline is gone.
• Align metrics to the commitments madeIf the business case claimed a specific number of hours recovered from automation, measure that. If it committed to SLA improvement, track it. If approval was granted based on a cost avoidance figure, report against it. The metrics that matter are the ones that were promised.
• Build a measurement cadence30 and 60 days post go-live for operational adoption. 90 days for process efficiency. Six months for cost impact. Twelve months for the full financial case. Each review is a checkpoint, not a judgement — the point is to identify gaps early enough to address them.
• Assign ownershipSomeone needs to own the measurement and report the results — to the same stakeholders who approved the business case. A programme that goes quiet after go-live creates scepticism about the next request, regardless of the actual outcome.

The most strategically valuable thing a well-constructed business case accomplishes is not securing budget approval, though it must do that. It is generating the organisational clarity and executive commitment that a complex implementation requires before the first workstream begins. And the most valuable thing the post-go-live review accomplishes is not validating a decision that has already been made. It is building the institutional confidence that makes the next case — for the next phase, the next capability, the next team — materially easier to approve.

What happens when the business case works

When Halo ITSM is embedded and delivering — SLAs improving, the team working from a single system, the ROI visible in the data — the natural question is what comes next. The same logic that justified the ITSM investment applies across the organisation.

HR, Facilities, Finance, and Legal teams are running processes on email, spreadsheets, and shared drives that Halo can replace. The business case infrastructure you have built — the cost of inaction framing, the ROI model, the adoption governance — transfers directly. You have already demonstrated to the organisation that a technology investment can be proposed rigorously, delivered properly, and measured honestly. That credibility is worth more than any individual feature of any platform.