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?