The Money Files

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.

One of the things that project managers get involved with from time to time is preparing business cases. Even if you don’t have to write the business case from scratch, there is a possibility that you will be asked to put some of the data together, or to review the final version. And, of course, at the end of the project you’ll have to go back and compare the project results to what the business case said, so it is a useful document to understand. You can keep a copy with your project files.

Here is some more information about this important project document.

Why bother with a business case?

There are three main reasons why you should make sure that your project has a business case (even if it isn’t written by you). They are:

1. To identify the business need (problem) for the project and fully describe it
2. To justify why it is worth spending the money and time on this problem
3. To provide enough information about costs and benefits to allow the work to be prioritised along with everything else that the team or company is doing.

Essentially, a business case answers the following questions:

What? What are we doing? What problem are we trying to solve?

Why? Why is this a particular issue right now? Why should we bother working on it?

How? How will we fix the problem? How will the work be carried out?

Who reads the business case?

It’s important to think through who is the target audience for a business case if you are writing one or providing information to go into one. The business case will end up being used by a number of different people or groups, so it should include information at different levels to suit their varying needs.

Think about who will read it:

• The project manager and project team will read it in order to find out what they are expected to do. It will provide key information to help with project planning such as when the benefits are expected to be realised, any fixed dates etc. It can also be used in project communication such as sharing the vision with others.
• The senior management team at the company or in that department will read it. They will be using it to help prioritise the work and to check that it fits with the current strategy. The project sponsor may fall into this group. They may be influential in deciding whether or not the project should be approved, but equally they may just be reacting to the third audience….
• The decision makers. This could be a strategy group, the board of directors, a Portfolio director or some other group that gets together to discuss upcoming projects and makes a final decision about whether something should go ahead.
• Future project team members may read the document if they go back through historical records because they are working on something similar. They will need the document to be well-written and clear because they won’t have the immediate business context that goes with it and all the day-to-day information that you have now.

What format does the business case take?

Typically project business cases are documents. Even today, when so much of our project work is done online and via a range of different tools that support project planning and document sharing, the business case is still a document that is formally put together in its own right, outside any project collaboration software. You can still upload the business case to your document store, if the project goes ahead, but at this point you are probably looking at putting together a document.

The document is likely to include links to or an embedded spreadsheet, or this could be included as an appendix. The spreadsheet elements cover things like more detailed assessments of costs and benefits, and maybe a resource plan. You could also include screenshots from project planning software if your business case includes high level milestones or any scheduling information. This can be useful so that decision makers can see the overall length of time that the project is planned to run for, and make their decision based on how long resources will be occupied working on the project.

Next time I’ll be looking at the major elements that go in to the document itself. In the meantime, who reads the business cases on your projects? Let us know in the comments.

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