Chapter 19
Ten Tips for a Good Business Case
In This Chapter
Checking that you can measure benefits
Keeping the Business Case up to date
Considering the Business Case during stages and Issue handling
The Business Case is the most important element of a PRINCE2 project. It’s the justification – the reason you do the project. You don’t run projects for fun, though they may be fun. You run projects to deliver a business benefit or meet a business imperative. Although some projects have complicated Business Cases and developing them involves huge amounts of work, most are much simpler. Here are ten pointers to help you produce a good Business Case, and then keep it up to date.
Measuring Benefits – Wherever You Can
Wherever possible, you need to be able to measure business benefits so that you can show that they were achieved. Sometimes measuring is hard and it takes a lot of thinking to work out how to do it, but as far as possible have measures, even if it is only for part of the benefit. Beware of ‘non-quantifiable’ benefits because, although sometimes real and valid, they’re by definition not measurable and you can easily fool yourself that the project is delivering more than it really is; more of that later in these tips.
Benefits can come on stream at different points, not just after the project. Particularly where things are being taken into operational use during the project, benefits may start to be seen during the project as well. Think carefully about this because even if only some benefits can be measured during the project, it gives everyone an indication of whether the project is headed for success or, for example, that the benefits projections were wildly optimistic. Chapter 11 gives you more on planning benefits reviews during the project, at the end of the project and after the project where benefits won’t be clearly visible until sometime after the project has closed down. Chapter 11 also has full details on the Business Case itself.
Be careful also to isolate benefits correctly, so that you can genuinely attribute them to the project. It’s easy to make the mistake of bouncing off too quickly and coming up with benefits measures that aren’t precise enough and which get contaminated by other factors. For example, an increase in sales of 20 per cent may sound like a good benefit. But if sales do go up by 20 per cent, how can you be sure that this is just down to the project? Perhaps sales have risen for other reasons that aren’t connected with the project at all. Perhaps the market has grown by 25 per cent and the project actually worked to reduce sales!
When orking the Business Case into full detail in Project Initiation state clearly against each benefit how you plan to measure it. Then, in the Benefits Review Plan, you set down when the checks will be made and who is to make them. Chapter 11 has more on avoiding benefits contamination.
If the project is claiming a percentage change as a benefit – such as increasing the speed of fulfilling orders by 10 per cent or reducing the time needed for particular business processes by 5 per cent – don’t forget to take baseline measures at the start of the project if you don’t know the current stats. That way you can show the change after the new procedures are up and running.
Understanding that Some Projects Don’t Have Benefits
Just occasionally you have a good reason to run a project that has no business benefits in the normal way in which that term is understood, or for which realising benefits is secondary to the main purpose. Here are three instances of when this may happen:
Compliance projects: Sometimes you have to run a project, whether it has benefits or not. The justification is ‘we’ve been told to’. Perhaps you received an instruction from headquarters that all divisions have to do this, or perhaps it’s a legal requirement. The justification for the project is ‘compliance’. The project may have some benefits as well, but you run it even if it hasn’t got any benefits at all because you have to.
A senior officer in a UK police force was very worried about the Business Case for one of his projects, because he couldn’t see any benefits and didn’t know what to write. When asked why the project was being planned, he replied that the Home Secretary (the government minister responsible for UK police forces) had written to all chief constables in all UK police forces asking (which means telling) them to run a project to implement a particular change. The justification or Business Case was therefore very simple: Why are we running this project in the police force? Because we have no choice; the Home Office told us to.
Enabling projects: Sometimes a project may not deliver any benefit, or any significant benefit, but you still run it because it allows one or more other projects to run that do deliver benefits. The justification for the project is therefore ‘enabling’. That’s a perfectly valid reason.
Non-quantifiable benefits: Benefits are normally measurable, but an exception exists. Some genuine benefits of a project simply cannot be measured, or at least can’t be measured meaningfully. They can be very powerful though, so need to be included in the Business Case. An example is with quality and company image. Perhaps you have a project to boost the customer’s perception of your company. You can measure that a bit, but how the improved perception then affects order levels is much harder to measure. But if perception problems are losing business, not to address your company image may end up with the loss of the whole company. Similarly, quality can be hard to measure sometimes.
In such cases clearly state that the primary justification is, for example, compliance and although there may be some benefits also, these are secondary and the project is needed whether the benefits are delivered or not. You can use the Executive Summary section of the Business Case to spell that out.
Reviewing the Business Case Regularly
The Business Case is a vital and ‘living’ document in PRINCE2. Keep it up to date throughout the project. Don’t just use the Business Case as a mechanism to get funding at the start, and then file it away and forget it. If the Business Case deteriorates you may need to stop the project – quickly. You can’t make decisions on the ongoing viability of the project, such as at the End Stage, unless you have current information to hand.
As a minimum, update the Business Case just before the end of each stage, so that you have it ready for the Project Board to check at the End Stage Assessment, their end of stage meeting. Chapter 6 covers the End Stage update of the Business Case.
Being Prudent (1)
Being prudent or conservative is a principle of accounting, and it holds true in project Business Cases too. Be careful not to be over-optimistic with benefits projections when you’re doing Start Up and Initiation so that you don’t start a project that really shouldn’t be started. That won’t help the business, and may stop another project which actually would have been more beneficial.
Being Prudent (2)
Another reason to be prudent about benefits is so you don’t undermine the success of a project. If you promise unrealistically high benefits and then fail to deliver them, the project can end on a sour note and the organisation may well see the project as a failure. But if you’re prudent and keep your estimates of benefits conservative, then when the project delivers, or even slightly exceeds, the promised benefits, the organisation sees the project (and you) as a success.
Owning the Business Case
The Executive must own the Business Case and not delegate this to the Project Manager. The Executive represents the business viewpoint for the project and delivering value for money. The Senior User(s) specify what benefits they can deliver from the project, and must then deliver them, so they have an important input into the Business Case as well. In line with the role of the Project Board as a whole, the Senior User(s) and Executive must realise that they’re responsible for the project overall, including the Business Case, even though the Project Manager may do a lot of the spade work for them.
Aligning the Business Case with Corporate Requirements
Many organisations have internal procedures for applying for funding, and have documents that you must prepare in a set way. Don’t make work for yourself by producing a Business Case according to the PRINCE2 list of contents, and then having to do the work all over again to re-format it and adjust the information to meet your organisation’s needs for finance submissions.
Instead, work out a format that serves both purposes in one hit. If the PRINCE2 Business Case includes elements that are useful to the project but aren’t necessary for the corporate application, put these elements in a separate section and don’t submit that section as part of the corporate procedure.
Change PRINCE2 where you need so that it fits your organisation.
Standing Firm on the Figures
Many organisations ask for huge financial detail as soon as anyone even murmurs something about a potential project. Try not to get sucked into this and end up doing a full Business Case in Start Up. Start Up is supposed to go fast and the Business Case at that point is just a ball-park outline. Please see Chapter 4 for full detail on Start Up, including the Outline Business Case.
If you give in to organisational pressure to produce detailed costings at that early point, you end up doing Initiation in Start Up and it all takes far too long. Instead, try to explain the PRINCE2 approach to your finance people and get them to see that you’re not ignoring the detailed financial work, but that you’re doing it as part of the planning when all the necessary detail from the Project Plan is to hand.
Updating the Business Case During Stages
PRINCE2 focuses on updating the Business Case at the end of each stage. But don’t simply do that and forget all about the Business Case during each stage.
In the regular review of the stage to check progress you need to check the benefit projections from time to time as well. If new information comes to light as part of the stage work that affects the benefit levels, it may have a knock-on effect on the viability of the whole project and you may need to warn the Project Board.
The Project Board may require a warning on benefits projection and set a tolerance level for benefits. So if the projections go outside the band they’ve specified, the Project Manager must warn the board immediately that the stage is in ‘benefits exception’. You can find more information in Chapter 17 on tolerances and exception handling.
Thinking ‘Business Case’ in Issue Handling
When dealing with a project Issue (something anyone brings to the Project Manager’s attention, such as a problem), don’t forget to look at any implications for the Business Case or benefits projections. For example, if the project is to put on a sports event and the problem is that you can’t obtain clothing in the right colour, this may affect sponsorship if it’s the main sponsor’s corporate colour. Please see Chapter 16 for more on Change Control and how to handle Project Issues.
The PRINCE2 method suggests that you consult Business Assurance to help check out this side of the Issue impact analysis, but everyone involved needs to have the Business Case continually in mind, not least the Project Manager.