Chapter 11

Producing and Updating the Business Case

In This Chapter

Justifying the project with the Business Case

Driving PRINCE2 with the Business Case

Identifying benefits and planning benefits reviews

Making sure that the Business Case stays up to date

Projects aren’t about fun and the good of your health. They’re usually about delivering business benefit. Projects can be fun and even healthy, but those aren’t the drivers.

The Business Case is the main driver of PRINCE2 projects and just about everything else fits round it. The project has to be worth doing. The effort and cost you employ to do the project must result in something worthwhile. The media reports failed government projects (private companies often don’t get found out) with headlines such as ‘Government department spends £6 million in order to save £3 million’. In financial terms at least, clearly the project wasn’t worth it; its Business Case wasn’t valid.

The way that the PRINCE2 method builds in the creation and then update of the Business Case is neat and logical. If this isn’t quite the same as the way your organisation deals with the Business Case then you have two options. Either change the way you use PRINCE2 so that the method does fit, or change the way your organisation works to reflect the underpinning logic of the PRINCE2 approach.

For most people, the Business Case that the method sets down is already a straightforward and sensible way to show that you can justify the project and, at the end, that the project did indeed deliver the goods. As with the rest of PRINCE2, the underlying ideas in this part of the method are simple enough.

Understanding Two Key Documents

Two key documents are concerned with the business perspective in PRINCE2. The first is the Business Case itself that records the justification for the project and which usually includes the benefits that result from the project. The second document is the Benefits Review Plan, which sets down when benefits will be measured, how and by whom. That measurement is often at the end of the project or after it, but in some cases benefits may come on stream earlier and start to be delivered during the project itself. This chapter deals with the Business Case first then, towards the end of the chapter, the Benefits Review Plan.

Knowing Who’s Responsible for the Business Case

Most organisations are happy in the knowledge that the Business Case is the responsibility of the Project Manager. So here’s the bad news (for those organisations, anyway): The Project Manager doesn’t own the Business Case. She may do a lot of the work to construct the Business Case, but the responsibility lies with the Executive, the head of the Project Board who represents the business viewpoint on the project and, in the part concerning the identification and delivery of business benefits, the Senior User(s). These two board roles must make time available during Start Up, during Initiation and where necessary during stages and then at the end of stages, to get involved with the creation of the Business Case and the related plan for measuring benefits and then maintenance to keep them current.

Justifying the Project

The Business Case is pretty much about justifying the project. The focus in the PRINCE2 method is mostly on business benefits, but although that’s sensible you need to take a wider view. In certain circumstances you can justify running a project that has no business benefits at all. The PRINCE2 manual, in its 2009 edition, has finally acknowledged clearly that a project need not be benefits driven. It lists five areas of business objectives and includes those where the justification may not be benefits focused in the sense of measurable financial benefits. The areas are compulsory projects, not-for-profit projects, evolving projects, customer/supplier projects and multi-organisation projects.

One justification that the manual still doesn’t mention is ‘enabling’. Sometimes the project won’t deliver quantifiable business benefits itself, but it puts things in place that allow other projects to run and it’s those other projects that will deliver benefits. An example is infrastructure projects.

People who like to argue that all projects must have business benefits may say that the infrastructure project is really just the front end of a much bigger project of which the later parts will deliver the benefits. But why have all the unnecessary complexity and risk involved in combining all of the projects into a single huge and unwieldy one just to avoid using a justification of ‘enabling’? The infrastructure project may well be a self-contained, separately managed project, and all the better for that.

Compliance projects

Just to spell out the compliance justification a bit more, you may run a project because you’ve been told to. Things really can be that simple. As an example, think about legal requirements. Perhaps the government just announced that the tax rules are going to change . . . again. You need to run a project to amend your payment systems for your staff. This project doesn’t save you money and you don’t get better penetration into your market area; actually, you don’t get any benefits at all. Well, don’t run the project then. No, that’s not an option because you have no choice; the tax change is a legal requirement and you must do it.

Again, some people who argue that every project must have business benefits would say that the business benefit here is that the Chief Executive Officer (CEO) or General Manager stays out of prison, but that’s just silly, because this isn’t a business benefit in the way we normally think about them. You’re much better not to join in with such games and simply to state that the justification of the project is ‘compliance’.

Benefits-driven projects

Most projects do indeed deliver business benefit. That’s true even if the primary justification is something like ‘compliance’ – for more on this see the ‘Hybrid justifications’ section later in this chapter. Wherever possible you must be able to measure such benefits and the really bad news here is that you’re probably going to have to think quite hard about them.

Some people say that if you can’t measure something then it’s not a benefit. But that narrow approach can be dangerous and lead to you missing out an important part of the project justification.

The following sections cover the three types of benefit that your project can bring to your organisation.

Direct savings

Some benefits result in a cash saving. You can see the money sitting in an account somewhere at the end of the project or soon after. One example is swapping a machine that has a high maintenance cost with a new one that has a low maintenance cost. When the new machine is installed, the leftover money remains in the maintenance budget. That money is measurable, visible, and real, and you can draw it out and hold it in your hand – if the finance director allows you to. Talking of finance directors, this sort of benefit is of great interest to them.

Quantifiable benefits

Quantifiable benefits are those where you can’t draw out the money and hold it in your hand, but where the benefit is nevertheless measurable (ideally in monetary terms). The most obvious example is savings in staff time. For example, your organisation may be very concerned that your sales staff are having to spend too much time doing admin work and that this is reducing the time they have available to actually do the selling. Consequently a project is run to streamline the administration of the whole ordering system and one result is that it saves each salesperson an hour of admin work each day. That is a quantifiable benefit. You don’t want to make any of the salespeople redundant; you’re just pleased that they can spend more time selling, which is what you hired them to do. No direct saving is made, because the salary bill stays the same. But you can quantify the saving in hours, and you can also go on to state it in money terms by multiplying out the hours saved by the hourly pay rate of the sales staff. If you like, this is almost a measure of efficiency.

Non-quantifiable benefits

So now to the tricky one. Is something a benefit if you can’t put a value on it? Well, yes. But here you need to be especially careful not to fool yourself. Claiming lots of wonderful benefits is easy if you can’t measure them and no one can prove you wrong.

Suppose you work in a large organisation with a really old and dark reception area that’s really off-putting to the many visitors to your HQ. The visitors get a poor impression of your company even before they talk to your receptionist, and a worse one still as they sit in a chair and look around while waiting for someone to come and meet them. This image may be very significant. If you run a project to refurbish the reception area to make it bright, pleasant, and welcoming, you drastically affect a visitor’s first impression. How important is that impression and, if you do accept that it’s important, how does the positive impression benefit the business?

This is an area where it’s easy to bounce off at a superficial level and measure the wrong thing. For example, you may do a survey of customer impressions before and after. ‘Good morning, can I ask you what you think of our dull and dark reception area; please give a number on a scale of 1 to 10. Minus 5? Okay. Now, after the refurbishment, what do you think? You score it a 10? Great.’ The measurement shows that the new-look reception area positively impresses customers.

Your survey results may be good, albeit subjective, measurements, but they don’t measure the business benefit. How does that customer impression translate into lost business or increased business? That’s just about impossible to measure. Does that mean that you should leave the reception area cold, dark, and boring? No. You know that improving the area is worthwhile, but coming up with any meaningful measure of the business benefit is somewhere between hard and impossible. In such cases, instead of trying, you’re usually better classifying the benefit as important but non-quantifiable.

Hybrid justifications

Just because a project is a compliance one or an enabling one doesn’t mean that you don’t get any business benefits at all. Some may well exist. Or you may say that as you have to do this project anyway you can adjust it a bit, perhaps by extending the scope, so that it does offer some business benefit. Although the benefits resulting from this adjustment may not cover all the project cost, it may offset at least part of the cost. In this case the Business Case may remain focused on a compliance element, which is the main justification, but then you go on to list what benefits the project delivers alongside that compliance.

Keeping It Current: A ‘Living Document’

A UK Government report, the McCartney Report, made a really valuable point about project Business Cases.

The business case needs to be seen as a living document that will run for the lifetime of the project, not just as a mechanism to obtain funding. It is only by using the case as a tool for monitoring progress that it is possible to make sure the intended benefits of the project or programme are realised.

The McCartney Report – Successful IT: Modernising Government in Action

For many people, the Business Case is indeed something that you do at the beginning of a project in order to secure the funds and then forget about. The McCartney report stressed the importance of keeping the Business Case up to date – using the really neat term ‘a living document’ – because the projection of benefits dropping or increasing may change the view of the project. Simply put, if the project claims to save £2.5 million a year and costs just £1 million to run, everyone may agree immediately to running it on the grounds that it’s justified on cost savings.

But suppose you find part way through the project that circumstances have changed and the project now costs £1.5 million and saves only £150,000 a year. If the main interest was savings, then almost certainly the correct decision is to stop the project. The up-to-date ‘living’ Business Case provides this essential ongoing management information.

The initial and usually very sketchy Business Case can be prepared even before PRINCE2 starts and in that case it comes into the method as part of the Project Mandate. The mandate is the ‘trigger’ that starts off Start Up. Often the organisation has some idea of why it wants to run a project and what the likely main benefits are. It may be wildly optimistic, but it’s a start. If the Business Case isn’t provided in the mandate, or it’s included but not in enough detail even for the sketchy or Outline Business Case then you work on it during Start Up. Please turn to Chapter 4 for much more on Start Up.

The manual identifies four steps which cover the development of the Business Case, then keeping it up to date. These are:

1. Develop: Getting the information together in the first place.

2. Verify: Checking at intervals to ensure that the Business Case is still valid and the project is still justified.

3. Maintain: Keeping the Business Case up to date with the latest information, such as project costs and benefits projections.

4. Confirm: Checking that the benefits have been forthcoming or are likely to be.

Getting Help When It Gets Complicated

People often think that getting help is admitting weakness. Within reasonable limits, I consider asking for help as a sign of strength and professionalism. So when you develop a Business Case, don’t hesitate to get help if things start to get complicated and you really need that help. Your organisation’s finance people may be a good first port of call and you can think of them as part of the team. But you may need to call in bigger guns still if the Business Case is on a large scale, such as in some government projects that require large amounts of public funds.

One police force was developing a Business Case for building a new headquarters, complete with radio transmitters and a control room. The project required private-sector funding as a partnership project. The work to develop the Business Case was so substantial that the force decided to make it a project in its own right: The force created a project to develop a Business Case for the HQ project. The justification for the Business Case project? I hope you got there before me – it was an enabling project. The project didn’t deliver any business benefit itself, but put the information in place that secured the funding to allow the HQ project to proceed, and in turn that delivered substantial business benefit.

Principle 1 – Continued business justification.

Dealing with Organisational Finance

Nearly every organisation is obsessed with controlling money. Finance people want to know exactly what everything will cost down to the last penny and they want to know that as soon as someone even breathes the word ‘project’. Actually, this is more than illogical and not aligned with sensible business practice. How can you possibly say how much a project will cost, with absolute precision and to ten decimal places, when you’re not even completely clear on what the project is yet?

PRINCE2 is much more sensible than that. When the idea is rough, so are the costings. As you do more work to plan the project out in Initiation, so you work through the costings in more detail and more accurately. What’s the point of putting together an extremely detailed Business Case with detailed costings based on guesswork and ignorance? And worse, you and I know that once someone puts forward detailed stuff, changing it is very hard. Somehow the budget becomes set in concrete no matter how much anyone says that the costings are estimates and subject to change after the more detailed planning work.

Going with the organisational trend to provide detailed costings up front goes against the logic of PRINCE2. Instead of Start Up happening really quickly to sketch the project out, it becomes much more involved and everything begins to slow down. That’s because when you try to work out detailed costings this early, you’re doing Initiation-level work at Start Up. Do all you can to avoid getting bogged down in too much detail early on. Work hard to try to change any standard organisational approach that requires compiling detailed financial information in advance of the Initiation Stage of the project.

You normally run Start Up very rapidly in days or even hours, so make every effort to keep things that way. Don’t try to do full project planning and get drawn into the detailed costings and calculations, which in turn require detailed plans to provide source data.

Many organisations have well-established formats for how you must present financial cases to decision makers, such as committees. In one sense those formats aren’t a problem, but in another sense they can be because of overheads. Consider if you can combine the project needs (as represented by PRINCE2) with the organisational needs (as represented in the finance submission format). You may, for example, alter the content and layout of the Business Case so that you present the organisational items first, and the PRINCE2 elements that don’t appear in the organisational format second – or even as an appendix. In this way you can have one document that covers both requirements and save on overheads.

As with the timings, though, if you think that the PRINCE2 content is well suited to the project and is better than the organisational format, then you may suggest change (shock, horror) to bring the organisational standard into line with the method.

Writing a Business Case

The method sets down some clear headings for what the Business Case includes in a PRINCE2 project. As always, you may want to adjust these headings to meet particular organisational or project needs.

Executive summary

The executive summary is both a summary and a commentary that explains the balance of the Business Case. For example, you may conclude that although the measurable benefits are limited, the non-quantifiable benefits are extremely important and that you can justify the project largely on these.

The executive summary is useful to inform those reading the Business Case of key points and the overall balance of the case. But the presence of an ‘executive summary’ is also dangerous in that it can give an impression to Project Board members that they just need to skim read this section and not bother with the others. That is not so and board members must not only read the whole Business Case, they have a fundamental responsibility to ensure that it’s enough to justify the project.

Reasons

The reasons section says why you’re running the project (or planning to). This is where you may say that the project is compliance justified, for example. You can also include some background; for example, the project may be the fourth in a series of five projects to upgrade production line machinery as set down in the corporate five-year plan.

Business options

The options give some further background information to set the project in context. Several things may have been possible to satisfy a business need, but here you explain why this one was selected for the project.

Beware of people and guidance – including the PRINCE2 manual – that say that ‘doing nothing’ is always an option. Sometimes doing nothing simply isn’t an option, other than a very silly one. You have to do something. An example of this is an office move project where the lease on the current building is going to expire and you can’t renew it, so you have to move. Saying that one option is to do nothing and wait to be killed by falling brickwork as the machinery moves in to demolish the building is nonsense and a waste of effort in a Business Case.

Expected benefits

Here you list the benefits you expect from the project together with the anticipated level of benefit. And you say how you plan to measure each benefit at the end of the project or, if you can’t measure the benefit until some time after that, at a Benefits Review after the project. But remember that you may have some non-quantifiable benefits and by definition you can’t measure these in a meaningful way.

Although the Project Manager probably does a lot of the work in writing the Business Case, and the Executive ‘owns’ it and must make sure that the project is value for money, benefits are the domain of the Senior User(s) on the Project Board. In PRINCE2 it’s the Senior User role that must determine the likely benefit of the project, and then is responsible for delivering those benefits using the outputs of the project.

When setting down the benefits, it can be very helpful if you include an assessment of how reliable the benefits estimates are. The project may offer savings of £3 million and the Senior User and Project Manager are very sure of that; 99 per cent sure. Or it may offer savings of £5 million but you’re only 50 per cent confident that this estimate is correct because, by their nature, these particular savings are hard to predict.

Expected dis-benefits

Dis-benefits are a negative outcome of the project. An example might be that a project that results in making processes more efficient means that some staff will be made redundant. That’s a bad outcome for those staff in particular, but perhaps also for those remaining where well-established teams are broken up and there’s likely to be a negative impact on morale, which may result in even more staff loss and also a drop in performance.

Don’t confuse a dis-benefit with a statement of what will happen if the project doesn’t go ahead. The dis-benefit is a disadvantage of running the project, in at least one person’s eyes – not a statement of the negative consequences if you don’t run the project.

Timescale

Timescale is second of two key factors that form the primary concern of many corporate managers. The first factor is cost, but if the cost doesn’t sound too bad, their next question is almost always, ‘When can we have it?’ The timescale is likely to be a ballpark estimate in Start Up and gets more and more precise as you discover exactly what the project involves. As better and more precise information becomes available through the project, you update the ‘timescale’ section of the Business Case.

Costs

Like the timescale, the costs are a ballpark figure at Start Up that becomes more precise after you do project planning in the Initiation Stage, and then even more exact as you do more work in project stages and update the Business Case in the light of better and better information. With most projects, the time when you know exactly how much the project costs is when it has just finished, but sometimes not even then.

Investment appraisal

This section of the Business Case locks back into earlier sections of ‘Expected benefits’ and ‘Costs’, using techniques such as discounted cash flow (DCF), which show the benefits, costs, and future benefits at today’s values. Check out the sidebar ‘A bit more about discounted cash flow’ for more on DCF.

Investment appraisal is about money – costs and benefits that you can quantify in financial terms. This may be only part of the story, because of non-quantifiable benefits and things such as the demand on scarce staff resources, which an appraisal just showing hourly rates doesn’t adequately reflect. Although investment appraisal techniques are valuable, they’re limited.

PRINCE2 doesn’t cover investment appraisal techniques, but you can find plenty of information on the Internet or in techniques publications like Inspirandum’s Project Techniques Toolbox.

Major risks

The risks section summarises all the risks in the project. Arguably, you may find it better to focus this section on summarising risks that may affect the Business Case, because from Start Up onwards every time you update the Business Case and present it to help with decision making you also update the Risk Register. But if the Business Case is to be circulated outside the project (perhaps to corporate managers) and without other project documentation such as the Risk Register then this section can be particularly helpful.

Setting down best case and worst case

Sometimes you just don’t know exactly what the benefits may be because they depend on so many factors. In this situation you can put forward a best case, a worst case, and a most likely case. This is known as ‘three point estimating’. Some prefer to use the average (the mean) rather than the most likely value (the mode) as the middle figure.

Being sensitive

One other approach PRINCE2 mentions is Sensitivity Analysis. Sensitivity Analysis refers to ‘what if’ scenarios and you may find it worth doing this for some of your projects. An example is with currency exchange rates. If project costs are being incurred in one currency and benefits realised in another, then exchange rates will affect the payback. You can perform ‘what if’ calculations to see how sensitive the costs and benefits are to exchange rate fluctuations and the point at which rate changes would start to impact on the project enough to make it non-viable.

Checking If a Benefit Really Is a Benefit

You have to be able to measure benefits, unless you’ve already identified them as non-quantifiable. At Benefit Reviews, you check the benefits to ensure that the project delivered what you expected, or more, or less. If the benefits are significantly more or less than target you also need to ask why.

A lot of misunderstanding surrounds identifying benefits and a quick look on the Internet reveals some quite strange Business Cases. I use a simple question to help check whether a benefit really is a benefit. If you can answer that question, the benefit is probably a good one; if you can’t, it probably isn’t. The question is simply: So what?

The new computer system will have an integrated database. So what? Well, it just will and that’s good, isn’t it, because all the best systems these days have integrated databases? This doesn’t sound like a business benefit, at least not yet, because you have no proper answer to the question ‘So what?’. This is actually a real example from a ‘techie’ Business Case. Business Cases written by technical specialists can sometimes focus on technical features rather than business benefits. These ‘techie’ Business Cases can be rather amusing sometimes, but I move on quickly in case you’re a techie (not to be confused with Trekkie but, surprisingly often, people are both).

In saying that the integrated database is not a benefit, I slipped in the words ‘at least not yet’. It could be that this is a benefit after all, but the author of the Business Case hasn’t gone deep enough. If you tell me that because the database is integrated you input data only once, not five times into five separate systems, I may start to get interested. If you go on from that and say it saves 300 administrator hours per month at a particular hourly rate, then I may be even more impressed and say that you have indeed identified a benefit. The icing on the cake is when you then set down exactly how you can measure that benefit to demonstrate the saving at the end of the project. Now I’m positively drooling, particularly if I happen to be a corporate manager concerned about departmental efficiency and overheads.

Being Sure That You Can Deliver

If you’re taking the Senior User role on the Project Board, when you claim that there’ll be a particular benefit you need to be sure that you really can deliver it. If you can’t be sure of delivery, then include very clear warnings to say why you may not be able to – in other words, spell out the risks.

One organisation moved its headquarters out of a city. Part of the Business Case was that the old HQ was in a prime location and would raise more money than the new, out-of-town HQ would cost. Tempting indeed, and common indeed. However, nobody wanted to buy the old HQ building, which was in a shopping area and not a business area. The building remained empty for over three years before the organisation finally found a buyer. In the meantime, the organisation incurred all the costs of the new HQ and the move.

Not claiming benefits that don’t exist

Just because you can measure something doesn’t mean that it’s a benefit. You need to be really sure that you can deliver that benefit at the end of the project and, with the exception of ‘non-quantifiables’, can provide a meaningful and relevant measure.

A department was running a project that would considerably reduce the paper storage requirements for their business area. Part of their allocated space was a very large basement room in a large and prestigious building. The project team realised that the department would no longer need the room, and the team went to the accommodation department and found the value per square metre of the building per year. They measured the room and multiplied the area by the value per square metre and claimed the resulting sum on a discounted cash flow as a recurring annual saving. Because the room was large and the building prestigious, the saving was huge. But the project team failed to realise that if this large basement room was currently full of paper, but was then going to lie empty, there was no actual saving at all. It would only be a saving if the room could be used for something else that otherwise would have incurred expense. But the team had not identified any such use because other departments didn’t want any extra space in the basement.

Being prudent

Management accountants have a principle of being prudent or conservative. They aim to slightly understate, not overstate, because that’s safer. This holds very true for project Business Cases and for two important reasons.

First, if you overstate the benefits at the start, organisational managers or the Project Board may approve the project when they really shouldn’t. Those authorising it make a judgement on faulty information. The knock-on effect may be that by authorising this project another project gets delayed, and that other project really should have gone ahead because it would have given more benefits more rapidly.

The second reason to be prudent relates to the perception of failure. If you claim massive benefits which then don’t materialise, organisational managers consider the project to be a failure. If you promise less but actually deliver a bit more, then everyone sees the project as a success.

Avoiding benefits contamination

A further problem with benefits realisation is the isolation of benefits. The best way to describe this is to use a real-life example.

To be a member of a particular internationally respected professional organisation you need to pass exams, join, and then maintain that membership from year to year. The membership fees pay for the running of the organisation. Fairly standard stuff then.

Now, the organisation has competitors in this professional field and it wants a growing membership so that it can resource more things and stay healthy. So it decides to run a project to increase membership. The big question is: How can you tell whether the project is successful?

Say the membership goes up by 5 per cent over the period of the project. But perhaps the competitive organisations’ membership also increases by 5 per cent over the same period and those organisations don’t run any projects at all; it’s just natural growth in the particular professional area. Or perhaps competitors’ memberships go up by 10 per cent without them doing anything, so it seems that the recruitment project is working against the organisation and is putting people off joining rather than attracting them.

Now suppose that the competitors’ memberships don’t increase at all, but instead go down by 1 per cent, whereas our organisation’s membership grows by 5 per cent. Is the project a success? Well, possibly, but perhaps people are joining for other reasons. Perhaps the organisation was involved in a court case where someone showed that she acted correctly and was supported by the professional organisation and so won the legal case. Other professionals saw the reports and many decided that they’d been meaning to join one of the organisations, and now this one has caught their eye because it helped so much in the court case. They’re joining because of the newspaper headlines and not because of the project at all.

Contamination of benefits can be a tough area to deal with. You need to select benefits measures that isolate benefits from non-project factors and prove that they relate directly to the project. Depending on the benefit, isolating it may be relatively easy or may require significant thought and effort.

Taking the example of the professional organisation, the project staff have to think how to show that the membership growth is due to the project and not to other factors. A common and extremely simple method is to ask new members why they’re joining. If the selected option is one of those that relate to the project, then the link is proven. Well, actually a small problem still remains, but that’s enough to give you the idea.

Actually Measuring Benefits Delivery

The Business Case itself includes information on the benefits and how they’ll be measured. But you also need a plan to show when benefits will come on stream, when they can be measured – which could be a while after they’ve come on stream – and who is to do the measuring. If you think that you’re going to need some sort of Benefits Review Plan, then you’ll be delighted to know that PRINCE2 has exactly that.

Measuring during the project, at the end of the project and after the project

PRINCE2 now recognises (at last!) that benefits can sometimes come on-stream during the project. It is not uncommon in business projects, for example, for project deliverables to be taken into operational use right through the project, not just in one ‘big bang’ at the end. If things are starting to be used during the project, then clearly benefits may start to be seen during the project as well.

You can often measure some benefits at the end of the project when major deliverables are taken into operational use. But for others, there’ll be a gap between delivery and benefits measurement.

Seeing the gap between delivery and benefits

When you think about benefits and measurement, you need to think carefully about the nature of the project, the deliverables and the benefits themselves. Some benefits materialise very quickly in a way that can be accurately measured and reported. Some take a while to settle down so that you can give a realistic picture of the level of benefit actually achieved.

An example of quick measurement is with the replacement of an old, obsolete machine on the production line with a new one. The old one is expensive in terms of weekly maintenance but the new one has a long maintenance cycle and not only goes longer between maintenance checks, but the work is less expensive. As soon as the new machine is installed, you’ll get the maintenance savings because the weekly checks can be stopped.

Immediate savings on a production line machine is very different to implementing a new and quite complicated business procedure. Although the new business procedure is more streamlined than the old way of doing things, it will nevertheless take staff a while to get familiar with it. You can’t measure time savings the moment that the new procedure is launched because staff are still learning about it and are going slower than usual. It’s only when they’ve got used to it and are working at a more normal speed that you can take a meaningful measure of the time savings.

That potential gap exists, whether you’re measuring benefits during the project or after it. It’s quite common, for example, to have a review some six months after the end of a project when the dust has settled, things have stabilised and benefits measurement can consequently be more accurate.

Understanding the responsibilities

Quite a few people, potentially, can be involved with measuring benefits, but the responsibility for specifying them in the first place and actually delivering the business benefit lies with the Senior User(s) on the Project Board. It’s the Executive who has the primary responsibility for making sure that the Business Case is sound and that the project is worthwhile, but it’s the Senior User(s) place to specify the benefits that they can deliver if the project goes ahead. Then everyone watches with interest to see the Senior User come up with the goods after the project has delivered! If you’re a Senior User you may like to flip back to the section earlier in this chapter on ‘Being prudent’ and read it again – slowly!

You may well involve other people in measuring benefits though, even people outside the project. For example, finance staff often have a valuable role in helping measure financial savings.

As you can see from the panel, the Benefits Review Plan content is obvious enough but, as always, adjust it if you need to.

For Benefits Reviews to be done during the project and at the end of it, don’t forget to put the activities and resource on your Project and Stage Plans. For any review(s) after the project, don’t forget to pass the actions back into the organisation at the end of the project as follow-on action recommendations.