It’s a great idea, but only if the Business Case stacks up
— says the future sponsor

If you’re lucky enough to hear this short, simple, yet formative sentence, congratulations, you’ve just volunteered yourself for some long days ahead. To most people, a Business Case can come across as daunting - the solution has never been implemented in the organisation, the approach to delivery is certainly an unknown, and having worked in the organisation for several years, you might conclude it would be ambitious to commit to delivering this side of the 22nd century.

So, can we take this seemingly complex task (building a Business Case), break it down into its component pieces and apply some logic to make life easier? Absolutely. This perspectives blog post will hopefully achieve this by explaining 5 fundamental areas to consider whilst planning the approach.

But first let’s understand the pre-requisites. To deliver a Business Case we need;

  • Agreement across the Business (including IT) that there is demand for an improved capability to solve a business challenge
  • A solution design
  • An agreed delivery approach – this final point will really get tested thoroughly throughout the formation of the business case.

5 Considerations of a Business Case

1. Know your output from the outset

Firstly, and most importantly, what is the Business Case going to look like? Complex solutions with many internal stakeholders and their accompanying Business Cases can take months to deliver (and approve) so the last thing we need is a lack of understanding of the end result. Key questions to consider at this stage are:

  • Does the organisation already have a template structure to producing a Business Case?
  • What is the detail required? Financial benefits & costs only, or delivery approach also, and if so, how detailed do we need to be?
  • When does the Business Case need to be presented?
  • Do we need to obtain approval of project resource before or after Business Case approval?
  • Is the output a single document or a presentation to a review panel?
  • Which stakeholders are involved in its approval and to what extent should we keep them informed over the next few weeks?
  • Are there approval thresholds which require varying stakeholder levels of approval?

Asking these questions of the project sponsor and the organisation’s Programme Quality Assurance (if it exists) before dedicating resource will certainly help set expectations across the parties as well as streamline the approach for the next few weeks.

2. List your components in a Business Case definitions glossary

To build a business case we need to understand every one of our inputs across Business, Technical Delivery and 3rd party services. Everything that carries a cost or delivers a benefit needs to be evaluated. For technology implementation projects, this exercise requires collaboration between IT, Finance, Business Users, and 3rd party services to ensure that nothing slips through the cracks - any stone unturned will be exposed either during the approval board, or worse, an unexpected cost is incurred during implementation – no one ever wants to volunteer to approach the board and ask for more money in 6 months’ time.

So, what inputs should we be considering at this stage? We could start by dissecting into the first two components; benefits and costs.

Depending on the solution being implemented, benefits can be very complex to calculate. A solution may bring numerous soft benefits to an organisation, e.g. increased collaboration between employees, and yet the ability to put a financial figure against this can be challenging. A lack of data around the current performance of a system can also make some benefits sound assumptive. This is where in-industry best practice and experience can be very valuable insight, so now could be a good time to reflect on how other perspectives can contribute to successful decision making.

For the more tangible benefits, the business first needs to agree the metrics to be measured. Do we expect to see an increase in customer transactions and if so, by how much? Will we witness a decrease in the volume of dropped baskets and if so, what is our expectation? It is also critical that we forecast when [in the future] these benefits will be realised – one, five, ten years ahead? Through articulating our current performance and realistically estimating the performance of an optimised solution, the integrity of our Business Case is improved.  

Costs are a rather different beast because for any agreed scope they are completely within our control to calculate accurately. We need to agree and understand all the cost components, e.g.  technical implementation resource, technical post-delivery support, technical hardware, technical software, business user resource profiling (during-project and post-project), 3rd party implementation services, 3rd party technical support contracts, Project Management and Business Analyst resource to name only a few.

The list of costs can be extensive so developing a cost definitions glossary will give us a clearer understanding of their calculation and reduce the risk of double counting. This can be distributed round the stakeholders and will be a vital asset in order to present confidently to the approval board.

3. B comes before C, Benefits before Costs

Benefits are independent of costs and therefore we should adopt an approach which allows us to calculate them independently. This will help us avoid the cost of our enhanced system influencing the methods and approaches we take to calculate our benefits. This could be achieved by Business representatives focussing on calculation of benefits whilst the Technical Delivery Team focus on cost subsequently bringing the two figures together at the end for analysis. If calculating benefits in isolation isn’t an option with the available resources, then documenting benefits in advance of costs is also a viable option.

4. Turn assumptions into formalities

A Business Case is backed up by financial figures and therefore needs to rely on solid figures wherever possible. During the first draft of a Business Case, assumptions should be logged and presented back to the Business, Solution Architects and IT implementation team as areas which need to be more firmly agreed. Although detailing an extensive list of assumptions demonstrates a clear thought process covering many facets, it doesn’t actually conclude decisions, actions and agreements. We need to challenge the assumptions and understand if any new agreements impact our project resource profiles, cost and benefit definitions, cost carriers or whether these assumptions even introduce new stakeholders to consider and bring on board.

5. Review, Review, Review

Now that we have completed our first draft of the Business Case; to the agreed output template, with all the right componentry, following a collaborative and agreed process, congratulations! - we are probably about half way there. The review cycles of a complex Business Case can take weeks. Hopefully, the above four steps have greatly reduced the number of questions and there are no surprised stakeholders asking questions but it should always be expected that efforts towards cost reduction are inevitable and we should plan accordingly for this – particularly if our final costs are not exceeded by our benefits. Furthermore, the organisation hopefully has a Market or Customer Strategy which we need to take into consideration. Do the solution architecture and benefits of our Business Case align with these strategies? The review process can be accelerated if different delivery options were identified throughout the compilation of the Business Case and can be called upon to reduce the effort required to investigate further during the review process. Additionally, for the Business Case reviews to be successful we need to understand if a reduction in scope, with the intention of reducing costs can have little/no effect on the benefits incurred – a bit like the 80/20 rule where we identify the optimal cost required to deliver the maximum return on investment

In the introduction to this article, we assumed that a Business Case was a daunting task because we didn’t understand where we should start in to order to get to where we want to end up. Is this assumption still correct, or is there now a glimmer of hope for your investment proposal going ahead?

If you still find the development of a Business Case a daunting task and want to discuss any aspect of your situation further, I would welcome any questions you have at andrew.pritchard@cometgc.com.


Andrew Pritchard

Consultant at Comet Global Consulting

Andrew is a Consultant within the Strategy and Insights practice at Comet. Inspired by an ambition to make operational activities slick by working smarter, he has been delivering new touchpoint capabilities at pace. Andrew arrived at Comet with a First Class Honours Degree in Logistics and a further 3 years of experience within Oil and Gas where he proactively managed global suppliers; driving streamlined internal and external operations through the promotion of intelligent use of Material Resource Planning systems. Now he’s taking on both consultative and project management roles within clients to compliment their marketing objectives.