The Money Files

In their book, Project Management Workflow, Dan Epstein and Rich Maltzman describe the different kinds of costs that make up the whole cost of a project. The 5 costs they cover are:

1. Direct cost
2. Indirect cost
3. Fixed cost
4. Variable cost
5. Sunk cost

Let's look at each of these in turn.

Direct cost

Direct costs are those directly linked to doing the work of the project. For example, this could include hiring specialised contractors, buying software licences or commissioning your new building.

Indirect cost

These costs are not specifically linked to your project but are the cost of doing business overall. Examples are heating, lighting, office space rental (unless your project gets its own offices hired specially), stocking the communal coffee machine and so on.

Fixed cost

Fixed costs are everything that is a one-off charge. These fees are not linked to how long your project goes on for. So if you need to pay for one-time advertising to secure a specialist software engineer, or you are paying for a day of Agile consultancy to help you start the project up the best way, those are fixed costs.

Variable cost

These are the opposite of fixed costs - charges that change with the length of your project. It's more expensive to pay staff salaries over a 12 month project than a 6 month one. Machine hire over 8 weeks is more than for 3 weeks. You get the picture.

Sunk cost

These are costs that have already been incurred. They could be made up of any of the types of cost above but the point is that they have happened. The money has gone. These costs are often forgotten in business cases, but they are essential to know about. Having said that, stop/continue decisions are often (wrongly) based on sunk costs. If you have spent £1m, spending another £200k to deliver something that the company doesn't want is just wasting another £200k. Epstein and Maltzman write:

"Sunk cost is a loss which should not play any part in determining the future of the project." Unfortunately, project sponsors and other senior executives (and even project managers) often value completion over usefulness and it does take courage to suggest to your sponsor that you stop a project that has already seen significant investment.

What other examples of these types of costs do you have on your projects? And have you ever taken the hit and stopped a project after incurring significant cost? Let us know in the comments.

Earlier this month I looked at what Michel Thiry says is important for a preliminary program business case, according to his book, Program Management (Gower, 2010). Today I want to look at the things you would include in a full program business case.

Let’s say that your preliminary business case has been approved by the powers that be. Now you have to put together a full business case for the program. This may be subject to further approval. Here is what he says needs to be included in the document at this stage.

Stakeholder analysis

Carry out a full stakeholder analysis and include it in the document. You should also put in a stakeholder engagement plan – this shows how you will work with and communicate with all the different stakeholders that have been identified as part of the analysis. What’s different about a program business case is that this piece of stakeholder work should also include which benefits relate to which stakeholders. In other words, who is gaining what from the program. Your program marketing strategy can also go in here, although Thiry says that at this point it only needs to be a high level marketing plan.

Scope

Review the scope again and make sure that the final version is accurately reflected in this document.

Budget

Your preliminary business case would have included some costs, but this is the place to document the program’s baseline budget. You should also specify where the money is coming from. If you can’t plan the budget for the whole program, do it in stages and only include the detail for the first stage.

Organisational structure

By this point you should have some idea of who you need on the team, so this is the place to put in an organisational chart. Thiry recommends showing the decision makers and communication channels here too. This is also a good place to list the roles and responsibilities of the people involved in the program. You can link this to show who is responsible for benefits and delivering to the critical success factors or key performance indicators.

Dependencies

Document all the links to other programs, projects within programs, other business activities, and (although Thiry doesn’t specify it) things happening outside the company such as regulatory changes.

Transition plan

This is specific to a program as you probably wouldn’t need one of these on a project. This specifies the work required to properly integrate the outcomes of the projects into the program and embed the new capabilities in the business.

Roadmap

This is a fancy word for timescales. This should show when the benefits are likely to be achieved and the key program milestones, taking into account when resources are available.

Governance

Write down the governance structures that the program will abide by. This could include reporting schedules, dates for audits, approach for peer reviews and what criteria will be used to assess whether the program is performing effectively. Change management also fits in here. I would have thought that you could simply reference existing company change management processes but if you have to put together something specific for this program, this is the section to spell it out.

Task list

Here is where you list the activities and projects that make up the work to do for the next stage. It doesn’t matter if you can’t predict all the projects and tasks required going forward, but you should at least know what’s coming up in the next stage. Thiry says this is the point where you identify (and, I suppose, seek approval for) the projects that make up that stage and prepare the relevant project charters.

That’s it. That still seems quite a lot, but if you don’t know all this information, then you can’t really move forward effectively with the program. It seems to me that this gives you more than just the business justification – in effect, it also covers a lot of what you would expect at charter stage, if we compare this to managing projects.

Have you ever worked on a program? What documentation was in place before it started or moved to the next stage?

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.)