Did You Make This Mistake with Your Business Case?

Business Case-789088-edited.jpeg

When you’re seeking internal buy-in from your company’s executives for a specific piece of software, one of the first things you’re going to have to do present a business case. And whether you’re a veteran business case writer or still a rookie, developing a well-researched, fully-fledged business case is a mammoth undertaking.

You pour your heart, soul and absolutely everything else into your business case, highlighting the virtues and benefits of a new software system that you know will improve your organisation across the board. You’ve zeroed in on a problem, defined a solution, and studied how implementation could work without a hitch.

And yet, despite your hard work, internal buy-in is not forthcoming. Now what?

A solid business case structure follows a fairly standard template in which you first offer an executive summary – an easily accessible, high-concept statement of why you’re bringing this to the attention of senior executives. You follow this by:

  • Defining both the problem and your proposed solution
  • Focusing on your solution, offering greater insight into why and how it will eliminate the problems your company faces
  • Presenting a full cost-benefit analysis of the proposed new system – arguably the most important section (see below for a starting point)

Demonstrating return on investment in a business caseIn essence, like a good movie, a business case follows a three-act structure; a narrative that takes readers on a journey from Set-up (‘We have a problem’) to Confrontation (‘We must resolve that problem’) to Resolution (‘Our problem is now resolved’).

Of course, it’s a little more detailed than that, so it’s well worth reading our comprehensive, easy-to-follow Build a Business Case for Software Guide here.

But let’s say you’ve done all of that, and you’re still receiving knock-backs. It’s never going to be easy championing a system if your organisation faces budget constraints, so your business case should address this head on – there is, after all, a firm argument against purchasing the first or cheapest system you find since functionality is key for training companies, and not all systems are created equal.

However, there could be something else going on here. A mistake that, rather than aiding your argument, can derail your business case in a matter of seconds:

You just weren’t honest enough.

Let's Get Critical

It’s OK, you didn’t do it deliberately; you were trying to present your training admin solution in the best possible light – but that’s the problem. You’ve presented a glowing testament but, purposefully or otherwise, you’ve neglected to confront any flaws or potential pitfalls with the new system.

It’s time to get critical. Incredibly critical.

Like, rip-your-business-case-to-shreds critical.

I know, you’ve worked incredibly hard on this technological hagiography that shows exactly how and why your chosen system will reduce training admin time/offer easy online course booking/turn everyone into Superman/all of the above.

Now tear it apart.

Because that’s precisely what your audience will be doing, picking holes in the project to really test its worth. By not actively confronting those issues, you’re inadvertently causing a mental stumbling block that will trip up listeners.

It’s a lot like that scene in Never Say Never Again, as James Bond rides a horse off a cliff – a moment later, we cut to a shot of the horse bobbing along quite happily in the water. Without that shot, the audience starts fidgeting, wondering if the horse is OK. It trips them up. It stops them focusing on what’s actually important for the film’s duration. The exact same psychological trick is at play when seeking internal buy-in, in which you confront possible objections or misconceptions before they can be formally raised, in order to focus your audience’s minds and a present a far more persuasive case.

So, it’s time to launch a sound counterpoint. Just like in article or essay-writing, this is the moment where you actively engage with opposing views related to your argument. Imagine your worst enemy is sitting in front of you, what flaws would they focus on to prove that your chosen system is, at face-value, imperfect?

When concentrating on possible concerns, you’ll want to do the following:

  • Summarise potential problems prior to implementation
  • Highlight how these may affect business operations
  • Showcase plans for addressing these problems, if you have any (and, you should)

You can list these concerns under ‘Project Constraints’, which typically comes around two-thirds of the way into your proposal. Continuing the film references, at the end of the second act of a movie, the lead character must ‘die’ – figuratively, literally, both – in order to be reborn more powerful in the resurgent third act. That’s what your ‘Project Constraints’ section is. You’ve got to ‘kill’ your proposal, so that it becomes stronger by the time the credits roll on your business case.

To that end, you’ll want to go one step further, twisting the knife on your precious proposal: You need to highlight those current issues, while advising that, since this is early days, your list of problems may grow once implementation is underway. Yep, this is just the beginning…

Stronger Business Case, Stronger Business

I know what you’re thinking: ‘If I demolish my own arguments, won’t that cause greater harm to my overall case.’

Well, yes. And no. You’re going to have to be overly critical – and if that shows up a major weakness in your business case, then it’s not a project worth taking forward in its current state. It’s better to know that now, than one month into a hastily arranged implementation.

When placed in this position yet convinced of your new system’s merits, it’s tempting to sugar-coat counterpoints or produce feeble counterarguments to bolster your goals. However, these hold more power to damage your proposal than an objective counterpoint will, since they typically come across as lazy and poorly researched, and you’re still leaving yourself wide open to criticism. More to the point, it’s impossible to remove all uncertainty surrounding any large-scale project, and suggesting otherwise via a weak counterpoint will appear shallow and false. The purpose of this type of risk analysis, after all, is to test the fences, as it were; measuring potential drawbacks and minimising future difficulties.

Start with the sort of issues that will occupy the minds of senior execs, such as implementation timetables, customer support options and total cost of investment relative to projected ROI. Counterpoints can focus on a broad range of issues; it covers everything from concept to completion, from showing why the project may not prove unsuccessful to highlighting any business risks if the project is approved and implemented. Confront the risks, look at other solutions to see if they better fit your business issues (and if not, why not?).

Balance each perceived con with a persuasive pro. ‘I’m a reasonable training professional,’ is the underlying theme here, ‘I’ve considered that, and this is why it’s not a concern…’ This, then, is the moment where you can offer a firm rebuttal to each counterpoint, using data, research and good old-fashioned experience to explain why your solution is the solution. If you can find no genuine pros – or, at least, are unable to identify ways to mitigate risk – then you’ve just discovered why your chosen solution is gaining zero traction.

Ultimately, only through fair and impassive objectivity will you deliver a strong and convincing business case, and gain that all-important senior-level buy-in.

Learn more about completing a compelling business case by downloading our Building a Business Case guide. 

Building a Winning Business Case

You should also read:

3 Common Misconceptions About New Business Systems

Why Software Implementation Fails – and How to Ensure Your Success 

The Ultimate Software Debate: To Build Or To Buy