CONTENTS OF THIS CHAPTER

This chapter covers the following topics:

• the purpose of a business case;
• the business case and the development lifecycle;
• checking feasibility;
• elements of a business case;
• identifying, evaluating and selecting options;
• principles of cost–benefit analysis;
• principles of risk and impact analysis;
• investment appraisal techniques;
• references and further reading.

THE PURPOSE OF A BUSINESS CASE

As Chapter 3 demonstrated, an IT system is not – or should not be – developed for its own sake but because an organisation has a business need that can be met through it. The organisation may wish to lower its operating costs, or improve the customer’s experience or it may need to comply with new legal or regulatory demands. Even with a project which seems, at first sight, mainly technical in nature, for example replacing an obsolete system with a more modern one, there is usually a business driver behind it, in this case to enable the organisation to continue functioning. A business case is an analysis of the justification for undertaking the project and it should be a major governing document throughout the project lifecycle.

THE BUSINESS CASE AND THE DEVELOPMENT LIFECYCLE

Figure 4.1 shows the typical lifecycle of an IT project, with a number of ‘gateways’ at which the business case should be reviewed.

Figure 4.1 The business case in the lifecycle of an IT project

A business case is usually first prepared after a feasibility study of the proposed IT project. This is designed to establish the outline costs and benefits expected from the project and it supports a decision on whether, on the face of it, the project is worthwhile. Usually, the project is authorised in principle but, specifically, the team is allowed to move on to more detailed analysis and specification of the requirements.

Assuming that the project seems worthwhile, the requirements are now captured and analysed and a detailed specification of requirements is produced. The business case should be revisited to check that the costs of the project – of which the team should now have a better idea – are still justified by the expected benefits, about which there should also be more information.

With the requirements fully defined, the project team now has two basic choices available to it (see Chapter 1) – either a solution is to be developed (in-house or using third-party suppliers) or a commercial off-the-shelf (COTS) package is to be procured. If the solution is to be developed, system designers now work out how it is to be created using the hardware and software available. As a result of this stage, there should now be a much better idea of the costs of completing the development and, hence, there is a need to revisit the business case again.

In the next stage, either the IT system is built, or it is purchased and, as necessary, customised to meet the users’ requirements. This stage also includes the sequence of tests (see Chapter 11) that are conducted to determine if the system has been built properly and is fit for purpose. The last thing to do is to put the system into live operation, but a further gateway has been shown here because – and especially if the development has taken a long time – we need to check that the business circumstances have not changed and assure ourselves that the system is still needed.

The final use of the business case occurs after the project has been completed. The project sponsor should initiate a benefits review to find out whether the hoped-for benefits have in fact been realised. There are two reasons for this. First, if some of the benefits have not been achieved, they may still be retrievable and the review should identify what further actions are needed to achieve them. Second, over time, the organisation gets better at deciding which benefits are, and which are not, achievable and so gets better at selecting which projects have the greatest chance of success.

The main lesson to take from Figure 4.1, however, is that the business case is not a do-it-and-forget-it document, created at the outset of the project and then never revisited. In fact, as the figure shows, the business case should be a governing document throughout the lifecycle of the project. In addition, if there is a significant change in the business environment – for example, a company is the subject of a takeover, or there is a change of government – the business case should be checked to ensure that the project is still viable in the changed circumstances the organisation now finds itself in.

FEASIBILITY CHECKING

As the name suggests, the point of carrying out a feasibility study is to assess whether the proposed systems development project is achievable given the business, technological and financial constraints within which it is to be undertaken. Even if the project seems justified at the feasibility stage, however, the circumstances of the organisation will change over time and so feasibility must be reassessed at each gateway or if some significant external or internal situation develops – a change in business strategy or a downturn in the economy for example.

Figure 4.2 highlights some of the business, technological and financial issues to be considered as part of the feasibility checking.

Figure 4.2 Aspects of feasibility

Incidentally, just because a problem is identified during feasibility checking, it does not automatically follow that the project should not go ahead. For example, if it were concluded that the organisation lacked the project management expertise to execute the project (an issue of competencies), this could be dealt with by hiring a top-grade project manager from the contract marketplace or using consultants to manage the project. However, both courses of action would raise the cost of the project and/or introduce additional risk and so must be taken into account in the impact and risk assessment (see later).

ELEMENTS OF A BUSINESS CASE

Organisations vary widely in the way they like business cases to be presented. In some, huge documents of many hundreds of pages are required, whereas, in one major company, business cases had to be distilled into two sides of A4 paper (on the basis that senior managers do not have enough time to study anything larger). Whatever the format of the business case, however, the following list of contents is reasonably typical and the most of the sections are described in more detail later in this chapter.

Introduction

This should set the scene and explain what the business case is about.

Management summary

Aimed at senior management, this should summarise the nature of the problem, the options considered and the recommended course of action (with justification). In an ideal world, three paragraphs should suffice here (bearing in mind that senior managers are busy people) but, at any rate, the summary should make a persuasive case for the course of action recommended.

Background

If necessary, this should set out the business background to the proposed initiative and describe the problem that is to be solved or the opportunity to be seized.

Options

All the options considered should be described briefly, including what would happen if no action is taken, and the preferred option should be described in more detail.

Benefits

The benefits of the proposed initiative – both tangible and intangible (see later) – are described here.

Costs

Here, the short-term and longer-term costs of undertaking the project are described.

Impacts

Impacts are other things that senior management need to consider in reaching their decision on the project.

Risks

The possible risks of undertaking the project, together with actions to deal with those risks.

Investment appraisal

This contrasts the financial costs and benefits over time and assesses when, and by how much, the project pays for itself.

Conclusions and recommendations

Usually, the writers of the business case sum up the document and make recommendations to senior management, although sometimes no recommendation is made and managers are left to make their own decisions based on the evidence provided.

Appendices

To avoid making the body of the business case too large, detailed information – for example, technical details of the proposed solution – is often put in an appendix, where it is available for consultation if required.

IDENTIFYING, EVALUATING AND SELECTING OPTIONS

There are usually alternative courses of action that should be considered in a business case, including that of doing nothing at all. (In fact, the discussion of the ‘do nothing’ option can be very important in some technical projects where non-technical managers need to be made aware that they cannot continue with their existing arrangements, perhaps because a package or operating system is no longer supportable.)

The process for options selection is illustrated in Figure 4.3.

Figure 4.3 Option selection

In a little more detail, the stages in option selection are:

Identify possible options

All of the possibilities should be considered, including not doing anything at all. Sometimes, that might be a viable option and, in other cases, the reasons why it is not a good idea need to be explored. In principle, nothing should be excluded at this stage although, in practice, the range of practical options may be limited and thinking about ‘off-the-wall’ possibilities may prove to be a waste of time and effort.

Shortlist options

The initial ‘long list’ of options should now be whittled down to three or four reailstic possibilities including, as usual, that of doing nothing. The reason for this is that presenting more than a handful of options makes the business case hard to understand and confuses the important issues that require decisions.

Evaluate shortlist

The three or four realistic options should now be evaluated using the criteria of the feasibility assessment (see Figure 4.2). Ideally, only ‘ball-park’ costs and benefits should be assessed for the options that are not to be recommended, with a detailed treatment reserved for the preferred option. However, in some organisations, it is required to perform a thorough analysis of all the options for management’s consideration.

Take forward to business case

The assessed options, with more detail developed for the preferred one, are now taken into the business case.

COST–BENEFIT ANALYSIS

For the senior managers who will make a decision on the business case, this is probably one of its most important sections (apart from the investment appraisal discussed later). What, they will ask, are we going to pay to carry out this initiative and what benefits can we expect in return?

In fact, both costs and benefits are of one or either of the following natures:

Tangible

These are provable in advance, usually in financial terms: for example, the savings from de-commissioning an old system or reducing headcount in the organisation.

Intangible

These either cannot be proved in advance, because there is insufficient data to do so, or they are genuinely ‘soft’ benefits, which are inherently hard to assess: for example, ‘improved staff morale’.

Note that the issue with tangible versus intangible costs and benefits is not whether they can be measured as such, but whether they are reasonably provable in advance. For example, increased sales resulting from a new web-based shopping channel may or may not be tangible depending on whether or not there is credible market research data available.

In addition, there is a timing issue associated with both costs and benefits. They are either:

Immediate

These costs or benefits are incurred, or enjoyed, at the start of the project.

Longer-term

These costs or benefits become apparent later, sometimes over quite a long timescale.

The reality on many projects is that immediate, tangible costs – for example, of developing and implementing the new system – are stacked up against a mixture of immediate and longer-term, tangible and intangible benefits.

The four categories of costs and benefits are summarised in Figure 4.4.

Figure 4.4 Categories of costs and benefits

Although not exhaustive, the following are some of the costs and benefits that might arise in a typical IT development project:

Notice that, in these lists, costs tend to be tangible whereas benefits are often a mixture of the tangible and intangible. In some organisations, managers are reluctant to make a decision unless the balance of costs and benefits is clear – in other words, the tangible benefits must obviously outweigh the tangible costs. However, in reality, an intangible benefit – for example a more modern image for the organisation or better staff morale – may in the end prove to be more valuable than anything that can be easily proven in advance.

RISK ANALYSIS

No IT project is without risk and some are very risky indeed. If senior managers are to make an informed decision on a proposed investment, they need to be appraised of the principal risks and, more importantly, what can be done about them.

In practical terms, a full risk appraisal is often impossible at the business case stage, not least because the project has only been scoped and planned in outline. But the principal risks should be identified and discussed in the business case. There are actually two types of risk that the decision-makers are interested in:

Project risks

These are things that might delay or otherwise adversely affect the IT project itself, for example difficulties in pinning down the requirements or problems with the delivery of hardware.

Business risks

These are the knock-on effects on the business, for example of reputational damage caused by a botched switch to a new system.

In practice, of course, the two types of risk tend to shade into each other; for example, a lack of skill within the project team leading to a botched implementation.

Once the principal risks have been identified, they need to be assessed and the following should be documented about each one:

Description

A description of the situation or circumstances that might give rise to the risk. For example, in a commercial, off-the-shelf procurement ‘The risk is that the wrong package is selected for the organisation’s needs’.

Impact

A description of what would be the impact if the risk occurred. For example ‘Choosing the wrong package would mean that the organisation was unable to carry out some of its existing functions effectively and/or additional cost and delay would be expended in customising the package to meet the organisation’s real requirements’. Notice how, in this case, a single risk cause could give rise to more than one impact.

Scale of impact

An assessment of how badly the risk would affect the organisation if it occurred. Sometimes, mathematical scales are used here but, often, a simple scale of small, moderate or large (or even catastrophic, if appropriate) will suffice. If there is more than one possible impact associated with a risk, consideration should be given to documenting them separately. For example, the organisation being unable to carry out its functions effectively might be a large impact, but the need for additional customisation might only be moderate.

Probability of occurrence

The other side of the risk coin is how likely it is that this risk will occur. Again, a simple scale of high, medium or low is often enough. In our example, we might consider it of only medium likelihood that the risk will occur.

Avoidance actions

These are aimed at reducing the probability of occurrence. In our example, an obvious countermeasure is to make sure that a complete set of requirements is compiled before looking at possible packages and ensuring that a structured procurement process is followed.

Mitigation actions

These are aimed at reducing the scale of impact if the risk occurs and they are needed because (1) sometimes avoidance actions are not available and (2) in other situations they do not work. In our example, one mitigation action might be to ensure that sufficient contingency in time and money is available for additional customisation, should that be required. Another might be to get the package vendors to underwrite their solution so that they bear the costs if the package needs a lot of adaptation. This is actually a specific form of mitigation called ‘transference’, whereby the impact of the risk falls on someone else (insurance is another example of the same idea).

Owner

Finally, we need to document who would be responsible for managing the risk, and taking the required actions to avoid or mitigate it.

Armed with this information about the principal risks, senior management is now in the best position to make a good decision on whether to proceed with the investment or not.

IMPACT ANALYSIS

Impacts may incur costs, or incur risks, and so be discussed under those headings. But what we really mean here is things that the senior managers need to think about in making their decisions. For example, to make effective use of a new system, different people may be required in the organisation and that might entail adopting a different approach to recruitment. Or, if people are expected to exhibit new behaviours (perhaps because a lot of ‘back room’ work has been automated, thus freeing people for more customer-facing roles), different training and incentives may be required. Another impact that can be difficult for managers to take on board is if they themselves are going to have to adopt a different style of management; coaching and supporting instead of directing, for instance.

The point is that managers need to be made aware of these impacts so that they can consider how best to take them on board to make the project a success.

INVESTMENT APPRAISAL TECHNIQUES

Having identified where costs and benefits will arise from a proposed IT project, the last – but in many ways most important – thing to do is to put these together in the form of an investment appraisal. Essentially, what senior management want to know is how long it will take to recover the investment in the project (if, indeed, they can in purely financial terms).

Preparing investment appraisals is, of course, the speciality of management accountants but others involved in IT projects – business analysts, developers, project managers – should at least have an understanding of the principles involved, and these are covered here.

The simplest way of presenting the investment appraisal is as a payback or break-even calculation, and an example is shown in Table 4.1.

Table 4.1 shows a typical IT project, where £250,000 is to be spent on new hardware and software in the initial year of the project (which accountants refer to as ‘Year 0’), with a further £50,000 being spent each year on hardware maintenance and software support. The benefits expected to flow from this are savings of £60,000 per year in staff costs and increased sales estimated at £80,000 per year.

We can see from Table 4.1 that payback/break-even occurs in Year 4, when the cumulative benefits finally exceed the cumulative costs.

Table 4.1 Example of a payback calculation

The virtue of a payback calculation is that it is relatively straightforward and easily understood by non-accountants. However, from an accountant’s perspective it suffers from a major deficiency, which is that it does not take into account what is referred to as the ‘time value for money’.

The principle here is that, over time, an organisation has to pay for the money it uses. If its main source of finance is bank loans, it has to pay interest on them or, if it is funded by shares (equity) the investors expect to receive dividends on their investments. The cost of meeting this interest or these dividends must be added to the face value of any money used in a project. For example, if I borrow £100 for one year at ten per cent interest, I need to find £110 in a year’s time to pay back the loan. Or, to put it another way, if I received £100 in a year’s time, it is only worth £100/1.1 or £90.91 at today’s value of money.

A method that takes into account the time value of money is called discounted cash flow (DCF) and this method applied to our example IT project is illustrated in Table 4.2.

In Table 4.2, we have worked out how much money flows in or out as a result of our project in each year and we have shown these as the ‘net cash flow’. We now adjust these cash flows by a discount factor based on the chosen interest rate, in this case ten per cent again. (The factors can be found in textbooks on management accounting or are built-in as functions in spreadsheets such as Microsoft® Excel.) The net cash flow of - £300,000 in Year 0 is given its full value as it represents money spent today. But the apparent + £90,000 in Year 1 has been adjusted to be worth only + £81,810 and this is referred to its discounted cash flow or present value. The + £90,000 received in Year 2 is worth even less, + £74,340 and so on until the end of the evaluation period in Year 4. If we now add up all these present values we get a net present value (NPV) for the project of – £14,790.

Table 4.2 Example of a discounted cash flow or net present value calculation

So, whereas the payback calculation suggests that our project would pay back by £60,000 at the end of Year 4, using DCF/NPV to take into account the time value of money shows that it does not pay for itself over that period.

There is a third method used to present an investment appraisal and this is to work out the internal rate of return (IRR) of the project. The IRR is the interest rate that would have to be used in a DCF/NPV calculation to end up with a net present value of zero at the end of the assessment period and, unfortunately, there is no formula to work it out! One can either set up a spreadsheet and try various rates by trial and error until the correct one is arrived at, or Excel has a very handy algorithm built in that can work it out for us (again, using approximation). In the case of our example project, it turns out to be about 7.71 per cent and, in effect, provides a simulation of the return on investment from the project. This can then be compared with other projects that are competing for the same funding. So if, for example, two other projects offered IRRs respectively of five per cent and six per cent, this project would be a better investment. In addition, whatever the IRR turns out to be, it should be greater than the cost of capital used in the project – in other words than the interest or dividends the organisation expects to pay out.

To summarise, then, there are three commonly-used ways of presenting an investment appraisal:

Payback or break-even

Simple and straightforward and, in times of low interest rates, provides a good assessment of the proposed project. But, it does not take account of the ‘time value of money’.

Discounted cash flow or net present value

Takes account of the time value of money and adjusts future cash flows to factor in the cost of the capital used to finance the project. However, working out the correct discount rate to use is tricky and involves some subjective judgements on the part of management accountants, particularly for a long-timescale project.

Internal rate of return

Gives a single headline number that represents the return on investment and should be compared with the organisation’s cost of capital. But it does not take account of the sheer size of a project.

FURTHER READING

Blackstaff, M. (2012) Finance for IT decision makers: a practical handbook (3rd edition). BCS, Swindon.

Gambles, I. (2009) Making the business case. Gower, London.

Ward, J. and Daniel, E. (2006) Benefits management: delivering value from IS and IT investments. Wiley, Chichester.