How to write a business case for business transformation.
Part 2 of The Business Transformation Series
Writing an article on business cases is a risky business. It can be a very dry and uninspiring subject. But getting your business case right is fundamental to success, so I’ve made every effort to make this as interesting as possible!
But before I get going, if you are keen to read the first article in the practical business transformation series – Part 1: Getting Started – you’ll find it here: How to successfully launch your business transformation
Now, let’s dive straight into the exciting subject of business cases, with my top five practical lessons:
Lesson #1 – Start ASAP!
The most important lesson I’ve learnt about developing the business case for any project, change or transformation programme is ….
It is never too soon to start!
The moment you kick off the work to identify and address your key issues or business challenges you should start thinking about the opportunities for your organisation to make financial and qualitative improvements. And, most importantly, start working out how these financial improvements will help you to pay for the investment you’ll need to make.
Lesson #2 Financial benefits rule OK!
While qualitative benefits are important – such as improved customer satisfaction, higher staff morale, better quality service, and so forth – they must be in addition to, not instead of, the financial benefits. Any business change or transformation you undertake will cost money.
Nothing in life is free, so you ought to be identifying at least enough financial benefits to balance the costs of the change and ideally to exceed them.
And whenever we help a client to develop a business case for a performance improvement or a business transformation programme, we’ll always ensure that, at a bare minimum, you’ll save enough to cover our fees. You can thus be confident that your spend on external consultancy is at least cost neutral or better.
In the private sector, targeting a positive net present value (NPV) for any project would typically be mandatory. In the public sector, you might find situations where a change or transformation is required simply because of a legislative change or a political imperative.
However, even if this is the case, I would still advise you to develop a financial business case. It is always a good discipline to know the costs and benefits of any undertaking. And, if you face problems, delays, or other issues during delivery, it is best to be able to manage the financial impacts against a solid baseline.
The UK public sector has a clearly defined business case approach called the UK Treasury Five Case Model, which covers the strategic, economic, commercial, financial and management cases. I’ll pick this up again later in the article when I talk about the key stages in the life-cycle of a business case.
Lesson #3 Break it down and roll it up!
Let us assume that you are working your way through a High Spot Review process, or equivalent, to get your change or transformation programme off the ground. As you identify, assimilate and consolidate the issues to be addressed, you’ll also start to develop a view of how these issues should be grouped together to be tackled as integrated work streams or projects. You’ll also be developing at least a rough idea of the order in which you should deliver these items of work.
As you do this, you should always try to identify the specific costs and benefits for each work stream or project, rather than being tempted just to create an overall set of cost benefit figures. Each work stream should stand on its own merits. Why? Well, for example, you don’t know at this stage whether the sponsor, steering board or senior management will approve all the work or just parts of it.
Having developed the breakdown of the costs and benefits by work stream you should also make sure you create a simplified summary roll-up of the figures to present to your steering board, sponsor or other senior management panel.
Lesson #4 Get your bean counter on board early!
I’d also recommend getting a financial team member on board from the outset of the high spot review or issue gathering stage. Or, if not straight away, then at least as soon as possible after starting. You should select someone who is a genuine finance professional, with the right financial qualifications, skills, experience, attitude and availability. And ideally, someone who has a strong reputation with your finance director. And by the way, unless you know them well and can get away with it, don’t call them a “bean counter”!
As soon as they are on board, you should ask your financial specialist to start developing the structure of the financial business case. Preferably they should begin with a format, or ideally an existing template, that is already recognised as the standard for your organisation for equivalent investment projects.
Lesson #5 Get your coding and categories closely coordinated!
One of the big practical lessons I’ve learnt, from bitter experience, is that it is much easier to start with a template and structure that is directly aligned with existing financial policies, terminology and coding, than to use one that is even slightly different.
You certainly ought to track your actual costs and benefits as the project or programme progresses, and it is so much easier to identify cost and benefit items directly from your actual financial figures rather than having to create some form of “translation process”, which is bound to be inefficient and prone to human error!
If your current organisation really does not have an existing business case template, then either use one that you’ve applied successfully in other organisations or do some research on the internet to find a suitable template.
Here endeth the top 5 lessons!
Moving on to Benefits and Costs
In the next part of this article I’ll talk about the two sides of the financial equation – benefits and costs. And I’ve deliberately started with benefits as that should always be the priority.
I’ll then go on to discuss the key stages of the business case life-cycle. I close the article with some key points on the important people – the “key stakeholders” – who need to be involved at these various stages in the business case life cycle.
In the course of your issue gathering stage, or high spot review, or strategy project – or whatever has been the trigger point for your change project – you should be aiming to define your vision for the future and set the scope of your changes. For example, will they affect the whole organisation, or just one department, or just one function, product or service?
This definition of organisational scope will also help you set the boundaries for your financial benefits. For example, if you’re going to deliver 5% cost reductions for your Procurement spend, and if the Procurement department currently spends £50 million per annum, then that is your boundary, i.e. your target cost reductions are 5% x £50m per annum = £2.5m. Note: you might sometimes hear the term “addressable spend” used to describe this £50m boundary.
As you can see, this is not rocket science. Indeed, this shows that it is usually fairly straightforward to set these initial financial boundaries for your project. You’ll therefore very quickly be able to determine whether you have a viable business case or not. For example, if you need to spend £5m to deliver those cost savings in the Procurement department, then your project will pay for itself in two years. Please note that I’ve deliberately simplified the valuation of these benefits and costs by using “today’s” prices. Your financial specialist will ensure you apply the correct treatment to your costs and benefits using approved internal rates of return (RoR), in order to give you a proper NPV for your project or programme.
If you’d like more details on how to identify your issues and set the vision and scope for your change project, see part one of our business transformation series:
If possible, you should also do some research to understand what, if any, cost benefit benchmarks exist within your market sector. For example, what have other equivalent organisations achieved under similar conditions? Lower savings of only 2%, or perhaps higher savings of 10%? If you work in one division of a larger organisation – UK based or global – you could also enquire with other colleagues to understand what cost savings they’ve achieved under similar project conditions.
We have a lot of practical experience in defining and successfully delivering financial benefits across a range of sectors. If you’d like an initial discussion on what should be possible in your sector, please get in touch for a free consultation, without any obligation.
We also have a range of research and benchmarking tools that we can deploy to your specific opportunities. As an example, you can use our IT Health Check tool to assess your current IT costs and complexity against industry standards and benchmarks.
As you start to pull together your figures for the overall addressable budget and your top down estimate of what cost savings you could achieve, you should also do some initial bottom-up estimates of where and how you could make savings. These might include, for example: staff reductions, reduced recruitment; reducing usage of office, factory or other facility space; reduced IT spend; reducing supply chain spend – assemblies, components, raw materials; and so forth.
I’ve focused so far on cost saving opportunities but you should also consider opportunities for increasing revenue or income. This won’t, of course, apply if your change or improvement is to internal departments, such as procurement or the IT department. And it is less likely to be applicable to a public sector organisation. But it certainly could be relevant if your transformation scope includes the whole of your organisation or a division, and particularly where there could be new sales opportunities. Such opportunities might include identifying new products or services, refining existing products or services, increasing sales volumes whilst keeping unit costs unchanged, increasing prices for higher quality products, and so on.
While I’ve highlighted in Lesson #2 above that “Financial benefits rule OK!”, it is nevertheless very sensible to consider and document qualitative benefits. Typical qualitative benefits could include: improved customer satisfaction, improved employee motivation, increased competitiveness, lower rework, higher quality, improved brand image, and the list goes on…
Although it is often difficult to put a quantifiable figure against such benefits (hence, their name!), these qualitative benefits can be vitally important for gaining the commitment of key people to your transformation programme, including senior management, your customers and staff. Also, with some effort, you can usually find a way to measure some of these so-called “qualitative” benefits. For example, you can measure customer or employee satisfaction through satisfaction surveys. You can measure your competitiveness by monitoring your win rate and other typical sales pipeline statistics, and so on.
In parallel with identifying the potential financial benefits, you must also think about the likely areas of spend required to achieve the changes or address the business issues you’ve identified.
For example, you will almost certainly need to allocate some skilled people to your programme and probably to specific work streams or projects. They may be existing staff who transfer to your programme, which means there will be no net impact on your organisation’s overall costs. However, you should nevertheless recognise the “opportunity cost” of using these resources on your internal project. This is especially true if they are people who would normally have a direct influence on your revenue or income, such as skilled resources usually charged out to customers, or staff directly engaged in producing or delivering your products and services.
If you need to design and implement organisation changes or new processes, you may need to bring in external expertise, at a cost. If you need new or improved IT infrastructure or applications, new facilities or office infrastructure, again you’ll also need to estimate these costs.
Another important perspective to consider, as you analyse and estimate your programme or project costs, is whether each cost item can be considered as a capital investment or an operating cost. These are often referred to as CAPEX versus OPEX in the private sector, or Capital versus Revenue in the public sector. Once again, your financial specialist should be able to advise you on this point, ideally in consultation with your finance director.
I have seen several instances where a sensible treatment of key costs as a capital investment rather than an operating cost has made the difference to whether a particular change programme is financially viable or not.
Another very important element in your cost estimating is to define and develop your approach to building in contingency. Some of the more sophisticated organisations will do this based on a full risk analysis of the programme – for example using Monte Carlo simulations. If you’re interested in more details on a risk-based approach to contingency please contact us. Alternatively, and particularly at the initial stages of the business case development, you could consider simply applying a flat percentage, in line with custom and practice in your organisation. As you’ll see later in this article I give some rules of thumb for what that percentage should be.
Stages of the Business Case
In this part of the article I talk about the four key stages that you should expect to take your business case through:
- High-Level Business Case
- Detailed Business Case
- Managing the Business Case
- Closing the Business Case
High-Level Business Case
The first stage is to generate a High-Level Business Case (HLBC). The HLBC would typically be one of the key outputs of your strategy setting, issue gathering, or high spot review activity. At this stage, your business case does not need a lot of detail. You at least need an estimate of the total costs and the target total financial benefits from the proposed project or programme, plus outline timescales.
I also recommend that you define these as ranges, for example: “The transformation is likely to cost £2m to £2.5m phased over 1 – 2 years, and is aiming to generate an average of £600k savings per annum over the next five years”. The HLBC should also include statements describing the targeted qualitative benefits and, ideally, set out any key implications of not making the changes – i.e. to avoid the “do nothing” option being selected by default.
The HLBC does not need to be much more than a page or two of figures plus supporting text. However, it is also important to collect all detailed information and assumptions that you’ve used to develop your high-level figures. You can capture these as appendices to your main HLBC document.
Your aim with the HLBC is to have a solid enough case to gain approval from senior management, your sponsor or your steering board, to progress to the next stage of work. This next stage should ideally include kicking off some low-cost “quick wins” to build momentum and demonstrate success, whilst in parallel developing the Detailed Business Case.
Building on my earlier reference to the public sector, the High-Level Business case is roughly equivalent to completing the Strategic Outline Case (SOC) AND the Outline Business Case (OBC).
Detailed Business Case
The second stage – Detailed Business Case (DBC) – is probably the most important. By the end of this stage you’ll need a fully documented financial business case, set out using approved templates and formats that are acceptable to the finance director and senior management.
See Lesson #5 above: Get your coding and categories closely coordinated! This should include the standard approach and value your organisation uses for internal rate of return (IRR) and should be structured to generate an NPV figure. Always remember that, particularly in the private sector, at least one senior person in the organisation is bound to take a cold, hard look at the NPV and may reject your case if the figure is less than the standard target. All organisations always have competing initiatives seeking investment from the limited funds available.
As mentioned earlier, it is also very important to include a contingency line as part of the business case – either one overall figure or broken down by project or work stream. In my experience, almost all projects face unplanned costs, or important scope increases, or other unexpected impacts during their life-cycle so the more contingency you can plan in, the better.
At this early stage, I would suggest trying to secure at least 30% contingency if possible, providing this still gives you a credible NPV. If your initial contingency ends up anywhere lower than 5% I think you should worry. This amount of contingency could be used up very quickly! It is much harder, later in the lifetime of the project, to go back to senior management and ask for more contingency. Conversely, it is always a good feeling if you can release unused contingency towards the end of the project and thereby deliver a higher NPV than planned.
As mentioned previously you can take a more sophisticated risk-based approach to contingency, developing an assessment of the likely cost and probability of individual risks occurring. You can then use this, with other statistical techniques, to generate your contingency figure. Please contact me if you’d like to discuss in more detail.
The other crucial thing to get right at the DBC stage is to be absolutely clear on who is going to be responsible for actually realising these financial benefits. For example, if your change project is to make improvements to the Procurement Department, you MUST ensure that the head of that department owns the realisation of the benefits. This highlights how important it is to get such stakeholders involved and bought into the programme from the outset.
Essentially, when you take your Detailed Business Case to senior management for their approval, ideally to sign it, at least in ink if not blood(!), you need, for example, the Procurement Director to be in the room. And he or she should be able to look the sponsor in the eye and firmly state that they support and approve the business case and will be responsible for achieving the benefits.
Furthermore, if you have a multi-workstream business case, I recommend that each work stream has a benefits realisation owner within the business who is ideally on the management board or at least a senior manager who owns the cost and/or profit centres where the benefits will be realised. And you should also ensure that the overall programme sponsor has the ultimate accountability for delivering the programme benefits.
I have a very vivid personal memory of a very tough business case review session. The Managing Director was initially very sceptical about the whole approach – having been ‘burnt’ in the past by failed transformation initiatives and wasting money on the “wrong” type of external support. However, at this sticky point in the review session, he looked each of his functional directors in the eye and saw that they were personally committed to achieving the financial benefits. This tipped the balance and he approved the business case.
The DBC stage is complete when you have presented the case to senior management, sponsor or steering board and they have signed it off. This will also be the kick-off in earnest of your change project or transformation programme. Note: In the next article in the practical business transformation series I’ll be talking about how you should build on your initial, embryonic team, to develop the full team required to deliver the changes.
Building on my earlier reference to the public sector, the Detailed Business Case is equivalent to the Full Business Case (FBC).
Managing the business case
The next stage of the business case continues for as long as your project or programme is up and running, and before close down. There are many points of detail that you need to cover during this stage – too many for this single article – and, as you know, I don’t want to make this dull or uninspiring! I have therefore summarised the key points I would focus on based on my experience, as follows.
Hold regular reviews of the business case. The ideal period is probably quarterly. Monthly is too much and yearly is not enough. But this is a rule of thumb that you might want to break under certain situations, e.g. if the project will be completed in only a few months.
Capture and report actuals against the business case. The ideal period is monthly, or even weekly if your organisation operates its financial cycle at that rate. It is very important to report not just costs but benefits too. You may not be expecting benefits to start accruing for several months, but it is important to put the basis of measurement and reporting in place right from the start.
Managing the contingency pot. On each formal review of the business case, you should expect that one or more of the work streams may have developed a need to use some of the contingency. You should make sure you use a rigorous, but light-touch, process to capture the justification for using the contingency, make sure it is challenged constructively, and then ensure it is signed off by the relevant authority.
Handling scope changes. You need to be very rigorous at both the programme and individual work stream level to ensure the tight control of scope. There is always a terrible temptation to try to deliver more features or functions than you originally planned, and to “hope” that the work can be done within existing budget or that the programme-level contingency will cover it. You must avoid this temptation and ensure that all material scope changes are managed sensibly, including estimated impacts to the costs and benefits of the work stream. And the resulting business case impacts must be properly reviewed and approved, or rejected, by the appropriately authorised person.
Closing the Business Case
The final stage of the business case is closure. There is a tendency for organisations just to close down a programme or project but not really formally review and close the business case. I think this is short-sighted as it will mean you’ll miss an opportunity to learn some of the most important lessons from the transformation programme. Once again there are, in practice, a lot of detailed points you should think about for this stage – too many to cover in full here – but given the importance of closure I have at least highlighted what I believe are the crucial ones:
Review the case as you close down each work stream. Don’t just wait until the very end of the programme. You should have the discipline to ensure that each work stream, for which you have a business case, is closed down properly. In particular, it is almost invariably the case that some actual costs will have been missed, or coded to the wrong account, or one of your suppliers has been late in invoicing. Make sure you clean all of these points up, certainly before the work stream manager rolls off onto another busy job!
Review at the end of the programme. Once the last work stream is complete, and you have closed down that part of the business case, you should then pull all the work stream costs and benefits together, check them for accuracy, review with the programme team and then take the overall picture to the final steering board meeting. I think it is then a very good discipline to compare the actual costs and benefits you have achieved, and the projected NPV, against your original business case. Have you achieved better or worse? What could you have done differently? What are the lessons you can take into the next business case? How could you manage your contingency better? And so on.
Hand over to “business as usual” monitoring. The worst thing that can happen with a transformation programme is when the work is completed, the programme team disbands…. but the business changes you’ve made do not stick in the long term. But one key thing you can do to prevent this is to ensure that the monitoring and reporting of benefits, against clear targets, is continued by the relevant team as a business as usual (BAU) activity. Building on my earlier example, this would mean that the Procurement Director is empowered and incentivised to measure and report the improvements to the procurement function for at least the next full financial year.
And now, last but not least….
Your business case will only be effective if you get the right people properly involved in its development and management, at the right stages in your change project or transformation life-cycle. My top recommendations based on practical experience are:
From the outset – your High-Level Business Case stage – ensure you have at least the following key business case roles and responsibilities in place:
The Sponsor – the senior, influential person in your organisation, ideally on the management board, who is personally responsible for leading and driving the change programme. She or he must have ultimate ownership of, and accountability for, the business case throughout its lifecycle.
The Financial Lead – the so-called “bean counter” or financial specialist I mentioned very early in this article. You need to bring them onto your team at the very earliest opportunity and ensure they have the skills, competence and attitude to really own the development and maintenance of the financial business case. They are your financial spreadsheet wizard!
The Programme Director/Manager – the person who will drive the scoping, planning, managing, monitoring and delivering the outcomes of the programme. She or he is the person who will drive, coordinate, and perhaps sometimes cajole and coerce(!), your organisation into providing the key financial information you need – both costs and benefits – from the outset and throughout the life-cycle of the programme.
From the Detailed Business Case stage onwards, you should make sure that you put in place the following additional key business case roles and responsibilities:
The Business Benefit Owners – the key, senior people from the business, who will ideally also be steering board members. They have the responsibility to realise the financial benefits delivered by the programme. They are the line managers or directors who own the relevant P&Ls or profit/cost centres where the benefits will actually “hit the top and bottom lines”, as they say!
The Work Stream or Project Managers – the key managers, who report to the Programme Director/Manager, and are each responsible for one or more of the projects that form a discrete component of the overall programme business case. They need to own their part of the business case as soon as they come on board. They are the people who will manage and report the costs and benefits of their projects, supported by the wider finance team (see next role definition below).
They must be held accountable for the costs of the work – measured against the baseline business case – managing project level contingency, forecasting and managing variances and so on. They are also responsible for ensuring the outputs of their work streams will “release” the relevant benefits to be “realised” by the business.
If you’re particularly interested in understanding more about “released” and “realised” benefits, please get in touch for a more in-depth discussion.
The Finance Team – the wider set of key people in the finance team who will need to support the key business case stakeholders described above. For example, you’re likely to need input from the relevant individual cost and project accountants within each of the business areas impacted by the programme. And you’ll need them at various stages. For example, at the start of the business case: identifying current costs; helping to identify potential cost saving opportunities and so forth. During the management of the business case: capturing and reporting actual costs; identifying, tracking, monitoring actual benefits to the business. And at closure: ensuring that all residual costs have been captured, old purchase orders closed down, invoices paid, and a multitude of other important financial housekeeping chores!
As I said at the start, getting the business case right is fundamental to the success of any major change or transformation programme. There’s a lot of detailed things you need to get right – impossible to cover in one article – particularly if you wish to avoid boring your audience! I’ve aimed to highlight the key practical lessons I’ve learnt so far…. but I should emphasise that it is an ongoing learning process.
If I had to boil all of this down to the top four points to remember, they would be:
- Start the business case development as early as possible
- Get financial expertise and experience on board from the start
- Ensure you establish real ownership of the business benefits by the business
- Be disciplined about tightly monitoring and managing the business case throughout the programme and all the way to the very end when you close it down.
I hope my advice and experience have helped you to think about your own situation and to focus on how you should put an effective business case in place to underpin your change or transformation initiative.
If you’d like to see other articles in the practical business transformation series, please subscribe via the form on the left. Or to use me as a sounding board for your embryonic transformation programme, please get in touch to set up a free, no obligation, consultation call.
And finally, please look out for the next article in the practical business transformation series: How to build the right team to deliver.