GPM First
Chapter 6 of Business Leadership for IT Projects (978-1-4094-5690-2) by Gary Lloyd

The Business Case as a Management Tool


Rethinking the Role of the Business Case

Writing a business case is often viewed as a necessary evil, produced solely to get authorisation or funding for a project to proceed. Unless it is driven by some form of regulatory requirement, the financial case usually determines whether a project should be given the green light. Once the project is given the go-ahead, the business case is often filed away in a drawer and forgotten. This is a missed opportunity. Whatever the size of your organisation, a succinct, one- or two-page business case summary (such as the example in Figure 6.1 on the following page) can:

  1. act as a reference point that describes the essence of the project from a business perspective;

  2. be reviewed regularly, preferably monthly, to evaluate whether project is still viable and if it should continue;

  3. keep attention on those things, such as the key assumptions and risks, that will determine the project’s ability to deliver the vision.


For larger projects, when a business case is initially submitted for approval, this summary may need to be supplemented with additional material. That might include things such as a marketing plan, customer research, a business model, business process redesigns, detailed financial projections and a summary of the other options considered. The essence of the business case can, however, be summarised on one or two pages and this is what needs to be reviewed regularly. For smaller and medium-sized projects, the one or two pages may well suffice.

Figure 6.1 Business case summary



This chapter will describe each of the sections within the business case summary. But before that, I want to say a little about the cultural challenge of establishing a regular business case review. A regular review acknowledges that:

  • the business environment that gave rise to the business case may change;

  • the business case is based on assumptions that may turn out to be invalid;

  • the project may get blown sufficiently off-course such that it will no longer deliver the business case.


Most people will agree that if a project is no longer going to deliver its business case, it should be cancelled or, at least, undergo radical surgery; however, accepting that business cases are often inherently uncertain and in need of validation takes personal and organisational maturity. This is not to imply that organisations should recklessly take risks, but rather, that they should recognise and manage those risks, such that prompt action can be taken when necessary. Alas, in my experience, most organisations assume that the business case will be achieved unless something exceptional happens. Establishing a regular business case review therefore requires strong leadership.

Business Case Components


As discussed earlier in this book, a shared project vision is the foundation of a successful project. Keeping the vision visible, at the very start of the business case summary, reminds everyone of the project’s ‘true north’. In the regular business case review, it poses the following questions:

  • Is what we have done so far consistent with the vision?

  • Is what we have planned consistent with the vision?

  • Are we still on course to achieve the vision?

  • If the answers to any of these questions is ‘no’, then what should be done?


Financial Case

Why the Financial Case is Important

There are two types of organisation when it comes to the financial case for a project. The first type insists on a robust financial case that is scrutinised in detail by the finance department. Projects without a good financial case have a tough time getting approved, unless it is absolutely clear that there is some other legal or regulatory need.

The second type of organisation doesn’t bother too much with financial cases. Projects get sanctioned because someone in a position of power wants them done. There is sometimes a financial case, but it is usually superficial and cobbled together to satisfy the organisation’s internal process. There is, of course, a spectrum between these two extremes, but approaches do seem to be polarised.

Even if you are in the latter type of organisation, I would still encourage you to define a robust financial case for your project. First, you want to be sure that your project is adding value and, second, if you believe in your project, you want to be able to defend it in prioritisation debates or in the event of a change in management ethos.

I recall a project, in an organisation in which I worked, that was sponsored by a powerful Chief Information Officer (CIO). He had little time for those who complained about the lack of a business case for his pet project. The project had been going a year when he resigned to take up a more prestigious role in another company.

Within a week of taking over, the replacement CIO called the management team together and asked ‘where is the business case for this thing?’. A week later, the project was cancelled. There were 40 people working on the project, including two IT suppliers. Half of the staff on the permanent team were made redundant during the weeks that followed.

Format of the Financial Case

The best way of describing a financial case is as a Net Present Value (NPV). For those not familiar with the concept of an NPV, I have included a primer in Appendix C. In essence, an NPV aggregates future cash flows, of costs and benefits, and expresses them in today’s money as a single number. This number shows how much financial value is added or subtracted by the project. The financial case should reflect the total cost of ownership, including post-project costs such as operating and license costs, rather than just the project development cost.

It’s usual to show three scenarios: best, worst and target case. Often, however, this is a perfunctory exercise, similar to coming up with a mandated set of three options for the solution. It’s a shame when this is the case because scenarios present an opportunity to link the financial scenarios to project uncertainty, as expressed in the project’s assumptions and risks.

The scenarios should use combinations of more than one variable, not just a shortfall in revenue or cost savings. So, for example, a scenario might combine cost overrun, schedule overrun, underachievement of cost savings and the need to spend money on risk mitigation or contingency. This is best done not by merely tweaking numbers up or down, but by sitting down with the team to think about ‘what will we do if this or that happens … what is the impact and how will we respond … and then what could happen?’ – realistic, thought-through scenarios.

I like to include the worst-case scenario on the business case summary as this is the minimum that the project needs to achieve to be viable. I don’t usually include the best-case scenario because it doesn’t really add any value to decisions that might have to be made about the course of the project.

The Project Cost Conundrum

Stressing the importance of the financial case might seem to be at odds with my assertion in earlier chapters that estimates of the total project cost are more often wrong than right. So how does one deal with this conundrum? The best approach, as I alluded to at the start of this chapter, is to accept that the cost estimate is uncertain and will change as the project progresses. In place of false certainty about the cost, take a realistic risk management approach.

At the outset of the project, set a budget constraint for project cost and use this value in the initial NPV calculation. Then, if you follow a strategy of regular value delivery, you will start to get a handle on the IT supplier’s productivity by comparing estimated and actual costs for each successive delivery of value. This enables you and your supplier to refine the overall cost estimate and revise the NPV calculation. In this way, the financial case is alive and subject to scrutiny throughout the life of the project rather than being unrealistically set in stone.

Performance Criteria

The performance criteria were described in the previous chapter. In business case summary format, suggested above, I have limited the number of performance criteria to three. Those listed are meant to represent the key criteria that drive the business case and might include things like the following:

  • Achieve x number of customers purchasing through mobile apps.

  • Achieve x per cent repeat purchases from customers who have bought once in stores.

  • Errors per thousand business accounts opened to be no more than y per cent.

  • y per cent of customers say they would recommend product z to friends.


If your list seems too long, try arranging them into a hierarchy that allows them to be summarised. For example:

  • The number of children under the age of five who die because of contaminated drinking water to be less than z per cent of the population for the target area.

    •     – the proportion of drinking needs satisfied by rainwater harvesting:

      •  rainfall harvested in centimetres;

      •  weekly water consumption in litres;

      •  water lost through evaporation in centimetres.


    •     – the number of families using the container effectively:

      •    the number of storage containers delivered;

      •    the number of families within two hours’ walk of the distribution point;

      •    the proportion of families who collect a container from distribution point;

      •    the number of families still using the container after six months.




As I mentioned in the previous chapter, you can, if you prefer, describe the performance criteria in terms of benefits, sometimes described as non-financial benefits. To some, this will seem to be more natural terminology for a business case. I have no issue with flipping terminology as long as ‘non-financial benefits’ are quantified in the same rigorous way as performance criteria. Unless you can measure whether something is achieved, it is unlikely to get done. If you are not sure how to do this, go back and take a look at the section on performance criteria in Chapter 5.

Even though you have expressed the performance criteria, or non-financial benefits, as an item that is distinct from the financial benefits, you should still make every effort to express the impact of achieving the performance criteria in financial terms and include it in your NPV. For example, if a particular performance criterion will reduce the number of errors, try to estimate the cost per error and thus the financial saving. If the performance criterion is about disease prevention, try to find out whether there are costs, such as the cost of treatment, that would be avoided through early screening.

Figure 6.2 Hierarchy of performance criteria



Key Assumptions

In previous chapters I talked about the need to identify assumptions upon which the business case depends; keeping them visible in the business case summary helps to ensure that they are regularly revisited. This point is so important that I want to reinforce it with another example.

Let’s assume that you are responsible for a project for an insurance company whose goal is to reduce the number of errors made when keying in paper-based claims. To turn this into a financial benefit, you need to know how many fewer errors are likely to be made as a consequence of the project. You also need to know the cost of making an error. Each of these represents an assumption. At the very start of the project, these types of assumptions may be no more than educated guesses, indicating whether the idea is worth pursuing. As we progress through the project, you should be seeking to validate these assumptions.

Initially, you might undertake some sampling to find out the current error rate. You might then follow the life of a sample of transactions, identifying the cost components of making an error, such as dealing with the customer and correcting the information supplied. You could go even further and investigate the impact of errors on customer satisfaction and the consequent impact on customer retention and thus revenue. These would be further assumptions that you could seek to validate. For now, let’s keep it simple and restrict ourselves to two assumptions: errors and their direct cost.

Note that at this point in the project, we have yet to contemplate any solutions. Our next step could be to define a performance criterion that we want to achieve. Say we want to reduce the number of errors from X to Y, thereby saving our organisation £Z. Let’s say that the project team considers a range of options and settles on a solution to use optical character recognition in order to capture the information from the forms. The cost of the new solution is estimated and provides a positive NPV over a five-year timeframe. The business case is proposed and accepted.

At this point, the following key assumptions are in play:

  1. The reduction in the volume of errors.

  2. The cost per error.

  3. The volume of paper-based claims.


However, let’s say that because of customer complaints, non-IT initiatives are being pursued to reduce the extent of the problem. These include a redesign of the paper form and customers being offered a discount on future premiums if claims are made online. In addition, prompted by the project’s analysis of the cost of errors, a local initiative changes the back-office business process to make it more efficient.

Although these initiatives might be taken into account in the business case, if they are more successful than anticipated, the viability of the business case might be affected. If we monitor the key assumptions regularly, over time, we can evaluate whether the project still delivers value. If we do not monitor the assumptions regularly, the project is likely to carry on regardless.

You might think that it would be obvious to review the impact of the complementary non-IT changes. In large organisations, however, local frontline initiatives can easily become detached from big head office IT initiatives. Sometimes, head office will keep an eye on the impact of the local initiatives for the first month, but will lose interest unless the immediate impact is high. The snowball effect that occurs as frontline changes are refined can easily be overlooked.

Key Risks

As with the list of assumptions, this section should list the key risks that could make or break the project. If you followed the advice in the previous chapter, you should simply be able to list the top risks here so that they are visible and regularly monitored.

As stated in the previous chapter, assumptions can always be expressed as risks. But simply rewording the assumptions already listed in the business case summary as risks is a waste of time. Make completion of the business case a thinking exercise, not a form-filling exercise. If you have thought hard about risks, you should be able to list some top risks that are distinct from the assumptions.

Key Constraints

Like the previous sections on assumptions and risks, constraints should be things that are critical for the project. These are the constraints that the project has to observe in order to remain viable. They are the ones that, if broken, should prompt a serious review of the business case and whether the project should continue.

Two of the key constraints that are listed should be the budget available and when the solution is needed, along with any intermediate value delivery dates.

Outside Scope

One of the biggest complaints that I hear about IT projects is that the project didn’t deliver what people thought it would. A friend of mine who acts as an expert witness in legal disputes about IT projects tells me that project scope is one of the most frequent causes of disputes.

The most effective way of clarifying what is within scope is to list those business outcomes that are not within the scope. This is because people will often assume that their own desires will be met by the project’s vision. You could, as some projects do, make a long list of what is within and outside scope. However, busy people are unlikely to read these types of lists and are more likely to jump to conclusions in terms of what is in scope, without much investigation.1

Listing what is outside scope in terms of business outcomes, rather than long lists of features, engages people at the level of the vision and is succinct enough to be visible in the business case summary. Let’s say, for example, that your project’s vision is to allow people to make small value payments to shopkeepers using mobile phones. You might state ‘payments between individuals is outside scope’. It’s a simple short statement that engages thinking at the vision level.

Roles and Responsibilities

Project Sponsor

I recommend naming the sponsor in the business case summary so that everyone knows who it is. Sometimes the role will change hands during a project, so naming the sponsor also ensures that everyone knows who is currently fulfilling the role, rather than who was in the role at the beginning of the project.

Project Manager

The identity of the project manager is not always obvious to the stakeholders. And, just like the sponsor, the person fulfilling the role may change, so it is good to keep the name visible.

I recall being asked to review a project by one of its senior stakeholders. About halfway through my first Steering Group meeting, I passed a note to my client. My note prompted him to ask ‘so who is in overall charge of this project?’. A couple of names were volunteered, but it turned out that they were only responsible for certain aspects of the project. The truth was that there was no-one in overall charge of the project.

It is always worth making clear who is in charge in the one-page business case summary.

Key Stakeholders

Managing stakeholders throughout the life of a project is absolutely vital for success. Even well-run projects that have identified and engaged with key stakeholders at the beginning can lose sight of who they are and their needs as the project progresses. Having them named on the business case summary ensures that they are always in mind. Of course, you cannot name every single stakeholder, but you should, at least, list those we described in Chapter 3 as having a high degree of both power and interest.

My preference is to name individuals, together with their roles, wherever possible. Effective stakeholder management depends on building relationships between people, not between roles. Always specifying named individuals is a reminder of this. In addition, it helps to identify when changes of responsibility occur and communicates those changes with the other stakeholders.

Business Case Red Flags

By the time you complete your business case summary, there is a risk that you will be in love with your project, or at least very fond of it. It will have a good NPV, it will deliver great performance and although one or two key risks are highlighted, you were smart enough to spot them and devise credible mitigation and contingency plans. Not only that, but you have crafted your business case summary to sit perfectly on a single page – it looks good.

Now is the time to slow down your thinking and look at your business case objectively. Unfortunately, as Daniel Kaheman tells us,2 it is difficult for us to spot our own mistakes. A solution is therefore to enlist independent reviewers who have three qualities:

  1. They must be independent of you and the project.

  2. Your must respect their judgement.

  3. They must be honest.


The last of these is the toughest to achieve. In the main, if you respect someone’s judgement, you will like them and this will be reciprocated. The corollary is that people who like you will not want to hurt your feelings and will, as a consequence, soften their blows, despite any entreaty to be brutally honest. They know that what you really want to hear is that the business case is great, with perhaps one or two relatively minor things that need to be addressed.

Assuming you choose a reviewer, or better still more than one reviewer, that you like, you can help them remain objective by providing a simple checklist of business case weaknesses to look out for. As an aside, in his book The Checklist Manifesto,3 Atul Gawande calls on his experience as a surgeon and as an advisor to the World Health Organization to describe the literally life-saving power of simple checklists – not long bureaucratic checklists in the hands of dummies, but succinct checklists in the hands of experts. ‘They provide a kind of cognitive net’, writes Gawade. ‘They catch mental flaws inherent in all of us – flaws of memory and attention and thoroughness’.

My suggestion to you is that you write your own checklist before you write the business case. This will have the effect of pre-arming you against those mental flaws of memory, attention and thoroughness. To help you on your way, below are some common red flags that I look for in business cases.


Business Case Checklist 

  • Is the vision clear?

  • Is the scope unambiguous?

  • Have the key stakeholders been identified and engaged?

  • How was the cost saving or increased revenue calculated and tested?

  • Is the worst-case scenario really the worst case in terms of project cost, operating costs and cost savings/revenue?

  • Does the project cost include contingency for change and for maturing risks?

  • What is the change budget?

  • What is the risk budget?

  • Does the project cost include all of the non-IT costs, such as training, premises and staffing?

  • Does the NPV include all operating costs, such as licensing, infrastructure and staffing?

  • Is the discount (or hurdle) rate visible and does it reflect the risk of the project?

  • What are the comparators that were used to calculate the discount rate?

  • Is the time horizon used to calculate the NPV realistic?

  • Are the performance criteria realistic?

  • Are they wishful thinking or based on something concrete?

  • What key risks are missing?

  • What key assumptions are missing?


Key Points from this Chapter

  • The essence of a business case can be summarised in one or two pages.

  • Describe what is out of scope in terms of business outcomes.

  • The business case should be reviewed regularly, preferably monthly.

  • Business cases are often inherently uncertain and need validation.

  • A regular business case review acknowledges that circumstances and assumptions may change.

  • Regularly reviewing whether a project should continue will be a cultural shift for many organisations.


What if Your Project is Already Well Under Way? 

Whatever stage you are at, you can always create a business case summary and add it to the monthly review process. If you don’t have a monthly review, the business case summary can be created and used to drive that review.

Most likely, you will find that the exercise of constructing the business case summary will highlight areas that have not been well defined or, perhaps, have not been considered at all. Thus, writing the business case summary will effectively be a review of what the project is seeking to achieve and whether it is on course, something that is worth doing at any stage of a project.


Submit your own content for publication

Submit content