The Money Files

In his book Program Management (Gower, 2010), Michel Thiry looks at the elements that make up a business case for a program. In the first instance, you start off with a preliminary business case. A full business case can come later, when you have worked out whether there is enough justification to pursue the work. Here are the elements that he says are essential for that early business case.

Justification

Why are you doing this program? This should include a statement of the problem.

Objectives

As with a project business case, set out the objectives for the program. This should include the high level scope statement and something about the timescales for the program.

Classification

Depending on what system your Project Management office uses to classify programs of work, specify the classification or category of program. This could be something like ‘compliance’ or ‘continuous improvement’. I think that if you work in a small company you may not have enough programs running to bother to include this.

Strategic contribution

This is the section where Thiry says you should include the critical success factors. Specify how the program will contribute to strategy and deliver something to meet the critical success factors at a strategic level.

Achievability assessment

What a great section! Apparently, this is where you include a statement about whether the program can be achieved. He concludes that it is a subjective assessment at this point but that you can base whether or not it will be a success on some preset factors (which he does not specify). I think that if you have a belief that the program will not be a success there is not much point bothering to put together this business case at all. Who is going to report here that their program is never going to deliver anything and will be a total failure? Still, the concept is interesting, especially if this section is completed by someone independent.

Key deliverables

This section is self-explanatory. Include key deliverables and the associated milestones. You can also link deliverables to critical success factors or key performance indicators.

Risks

Include a short statement about the major risks and opportunities. He doesn’t talk about including mitigation plans but you could do this too if you already know what the approach would be.

Resource requirements

This is the section to list the types of resources you need. If there are any special skill sets required, note them here.

Impact on organisation

This is an interesting section – it should cover the impact of this program on any other organisational initiatives that are happening at the same time. I suppose you could call it ‘dependencies’. This is where you can note any resource conflicts too, but equally any advantages of running this program in parallel to other work.

Costs

Of course, every business case should include costs. If you put your document together in the order Thiry suggests, by the time your sponsor (or the group that decides on whether to approve your program) gets this far, they should be thoroughly convinced that this piece of work needs to happen.

Benefits realisation plan

How are you going to get any benefits from this program? Specify how any financial benefits will be achieved, when the company should expect to see them and who is responsible for them. (Ideally, they should know that they are going to be responsible for them prior to you submitting the document, in my opinion.) You should also specify any non-financial benefits and how they will be tracked.

All this adds up to just the preliminary business case – which implies that a full program business case would need a lot more detail. However, this should be enough to help senior managers make a decision about whether it is worth investigating this program further.

Have you ever prepared a business case for a program? What things did you include?

My new book, Shortcuts to Success: Project Management in the Real World (2^nd Edition) was published last month. It includes over 30 new case studies about project managers working on projects around the world. The idea was to share the good practices and mistakes that other people make, so that you get the benefit from their experience.

Fully revising the book for this edition meant that I had to drop some chapters and some case studies from the previous edition. It was hard to work out what to cut, and I ended up losing some case studies that I really liked. As a result, I thought I’d share this one about project budgeting with you.

It’s about creating a realistic, comprehensive budget, and it shows that the little things add up.

'Lives up to the 'real world' promise in its title, providing concise, practical advice for leaders of large projects, small projects, and everything between. The interwoven examples from actual projects illustrate clearly why the guidance provided here matters.'

Tom Kendrick, MBA, PMP, Project Management Director, UC Berkeley Extension, California

Brainstorming for a comprehensive project budget

‘I haven’t had much experience handling money, so doing my first project budget was really hard,’ says Emily Jones, a junior project manager in a small public relations consultancy.  The project was to revamp a room that had been used for storing spare furniture into a new area for holding workshops.  ‘My sponsor left me to it, so I had to work out the money I thought I’d need by myself.’ 

Jones set up a brainstorming session with her team and asked them to help her identify all the likely costs for the project.  ‘We came up with the obvious ones like staff salaries and buying the new office furniture really quickly,’ she says.  ‘Then I asked them to be more creative, and someone said “hiring a projector for the staff briefing.”  OK, so that might not sound really creative, but as our company projector had just broken, and we were scheduled to do a presentation on the project in three weeks at a briefing for all 45 staff, it was a cost I certainly hadn’t thought of.’ 

In fact, Jones hadn’t even known the company projector was broken.  The replacement was on order but not due to arrive for another five weeks.  Jones wanted her presentation at the company briefing to be professional and projector hire was not a great deal of money, so a member of the team was tasked with finding an estimate and the cost was added to the budget.  ‘On the subject of hire we also came up with hiring a van to take the old furniture to a charity warehouse.  We could have had the council take it away for free, but we decided we’d rather it went to a good cause, so that cost ended up in the budget too.’

Jones split the identified costs into groups.  ‘In the end we had a group of charges for manpower for our time and one part-time contractor, a group of charges for putting in a new telephone, the decorating costs and some miscellaneous things.  I added a contingency line of 15 per cent of the overall budget as I knew many of the costs were just estimates,’ Jones continues.  ‘I explained to my sponsor that this was for risk management and he cut it to 10 per cent.  I thought that was reasonable, and he approved the budget on that basis.’

***

Shortcuts to Success is now available and if you want to see a sample chapter you can read one online here. You can buy a copy at the BCS website (and BCS members get 20% off), or you can get it on Amazon.co.uk or Amazon.com.

(These are Amazon affiliate links.)

In this video I describe the key roles in project estimating.

On your project you will have a number of measures and metrics. Key performance indicators (KPIs), critical success factors (CSFs) or success criteria and benefits can all be measured, and you may have some other targets to achieve as well such as customer satisfaction measures.

So what makes a good metric?

According to John Seddon in Freedom from Command and Control: A better way to make the work work, there are 3 principles for making sure your metrics are robust and useful.

1. Does it help understanding?

Seddon believes that the test of a good measure is that it helps us understand and improve performance. If it doesn’t, there isn’t much point in gathering the data. Targets, for example, are measures that don’t help us understand performance. They are arbitrary figures, created perhaps on a whim. Worse, they can focus people on the wrong things, and not on how best to do the work.

Capability measures look at the system of work (in a systems thinking environment), so they encourage people to look at how things are done and therefore they help improve the work. They can be more motivating than arbitrary targets.

In a project setting, by this definition a target held by the Project Management Office of closing 10 projects each quarter is not a good metric. A measure of how long it takes to complete the testing phase is useful, as that gives you data you can compare across a number of projects. Then you can draw some conclusions as to why some projects have a longer testing phase than others and in turn this will help with your estimating.

2. Does it relate to purpose?

The second test of a good measure, according to Seddon, is that the measure must relate to “the purpose of an organisation from the customers’ point of view”. In other words, measures must relate to something that means something to someone.

In a project environment, the person who is likely to be deciding what is important is your main project stakeholder or sponsor. Whatever matters to them is the thing you should be focusing on. For a project manager, this could be the triple constraint in the form of the time-cost-quality triangle. Or you could be told that the response times on the new website you are building are the most important thing and the sponsor wants reports every month about how much you have been able to improve them by. A lot of project measurements don’t actually relate back to what internal and external customers care about, so it is worth looking at what your project is measuring and checking that you aren’t wasting your time.

For more about what customers care about and how you can identify what is important to them, my book, Customer-Centric Project Management, includes a couple of case studies and some templates.

3. Does it integrate with the work?

The third test of a good measure is that it is easy enough to record. If it doesn’t integrate with the way that the work is done, no one will collect the data. That’s true enough – I’m sure you have occasionally been asked to produce reports and have struggled to find a way to represent the data or even to find it, as it isn’t ‘natural’ to be capturing project information in that way.

Seddon also believes that metrics that look backwards aren’t much help. Making decisions based on data that was captured in the past isn’t a good way to plan work going forward. I don’t agree – in a project environment capturing lessons learned, time measures and data that will help future estimates is, in my opinion, a good use of time. But I do see what he means in a service environment. His book is aimed at people in a call centre-type service organisation or manufacturing, where knowing that last week you answered 30 calls an hour or built 60 widgets doesn’t give you an accurate prediction of what will happen this week.

How many of your project measurements meet Seddon’s 3 criteria? And if they don’t adhere to these principles, are you happy about why not?

Last time I looked at some of the basic features of the project business case – the key document that sets out what the project is going to achieve, how the work will be done, and most importantly, why this is a problem that needs to be solved right now. I covered the purpose of a business case, who is likely to be reading it, and the general format. Today I want to look at what different sections go into the document to make up the full business case.

These aren’t in any particular order, and you can arrange the segments as you like, perhaps according to whatever template is used as standard by your Project Management Office. However, if you are going to use an executive summary, that has to come at the beginning, so let’s look at that part first.

Executive Summary

Normally, you write the executive summary last. It is a short statement, normally no longer than a page, that sets out a summary of the whole document. It is for people who don’t have time to read the whole thing, but it is also useful for everyone. You get a complete flavour for what the document will be about and how the project is likely to unfold, and then you can read the detail on the subsequent pages.

Because it is a summary of the detail of the document, that’s the reason we write it last. You need to know what goes in to the rest of the document before you can summarise it here!

Statement of need or problem

Early on in the business case you should set out what the problem is that this project will address. After all, readers will quickly want to know more about the issues faced by the company and how this project will fix them. Mention the current situation, if this project relates to improving a particular system or process. Figures and other types of data, such as customer surveys, can also be useful for making the point that there is a real issue that needs addressing. If you can, link the problem back to strategic objectives or key performance indicators for the company, maybe referring to elements of the balanced scorecard.

The important thing in this section is to remember that it will be business people who are reading it, not technical staff or project managers. Try to avoid jargon and make sure that you set out the problem and solution clearly.

Options

A business case should look at all the potential ways to remedy this problem before making a recommendation on the best one, so include a section where you spell out the different options. By this point you’ll already have a view on which solution you will be recommending, so don’t spend too much time describing options that have been rejected and why they are no good. However, you should mention them, so that the readers know the thought process that you went through to identify the best way forward.

Remember that there is always an option to do nothing, so you should also include this as a comparison to the proactive options.

Recommendation

In this section, spend more time explaining your proposed solution. You do have more space to go into detail, but again remember to keep it all in business language avoiding jargon where you can and being really clear about how this particular solution will help solve the problem.

This section is something that you could refer to later when putting together your project initiation document or charter, so it can also include a summary of costs and benefits, key milestone dates and who will be required to work on the project. If you don’t know names at this point, make a note of the key skills or job titles required.

Costs

Every business case needs a section on costs as this is one of the main ways that people make decisions about what projects to do and how to prioritise them. Costs cover a number of different areas so consider these:

• Capital costs
• Resource costs
• Running costs for maintenance
• Decommissioning costs if you are switching off another system
• Training costs and other HR-related costs such as redundancy payments
• Consultancy or third-party fees
• Licence fees
• Implementation costs

You can probably think of some others yourself.

Benefits

The flip side of costs is benefits, and your business case should make it clear what benefits will be achieved by working on this project. Benefits could include things like increase in customers, revenue, staff morale, or avoiding costs, or ensuring the company remains compliant with current legislation.

Risk

This section covers positive and negative risk and you would want to include some detail about what mitigation plans would need to be put in place to manage the risk if the project was approved. You can group risks into categories if that makes it easier to present the information to the readers. Your Project Management Office may already have a standard set of categories, but if not you could consider things like technical risk, business risk, and any dependencies on other areas or projects, as these could also be risks.

Those are the main considerations to look into when producing your business case, although there are no hard and fast rules and it is best to include more information (as long as it is clear and concise) than less. This gives people the information they need to be able to make an informed decision about whether to progress with the project.

About the author: Elizabeth Harrin is Director of a project management communications firm, The Otobos Group. Find her on Google+ and Facebook.