The Money Files

When Lotterywest, Western Australia’s state lottery, embarked on a large rebranding exercise, project manager and head of the shopfit team Keith O’Shea, an Australian project manager with 20 years experience in various industries including construction, manufacturing and computing,knew that the stakeholders would be key to the success of the project.  His main group of stakeholders were the retailers who would be adopting the new aqua and yellow brand.  To keep them engaged for the duration, O’Shea and his project team looked at what would interest those involved and realized that they wanted a few straightforward things:  help to cover the costs of the rebranding, help with marketing and to be regularly informed of what was going on. 

‘We had to be especially thoughtful in how we motivated retailers to move to the new brand,’ O’Shea explains.  ‘It was the outlets themselves who had to find the money to pay for the change.’ 

Lotterywest responded to these needs by putting several strategies in place.  The company organized interest-free loans which were made available to all the 484 lottery outlets.  Lotterywest and their advertising agency also ensured that all television and newspaper adverts featured the new brand, even before the first shopfit had been completed.  This was done to enforce the new image in the public domain, and help convince retailers to move towards it.  To help the retailers along, the project team produced a makeover ‘kit’ that was made available to the rural and remote shops.  O’Shea travelled the country running workshops to engage the store managers and staff with the new image.  The project team also organized a celebration for the 100th store to take up the new brand, and the ensuing party was covered in the internal magazine, which dedicated a page of each bi-monthly edition to news about the project.  None of these things were a huge overhead for O’Shea’s team, but all were essential in keeping the project moving along. 

‘We held a public briefing for industry, people like designers and shopfitters, to engage them in the “selling process”,’ O’Shea adds.  ‘This proved to be amazingly successful as they became the main drivers in the initial uptake.  It also made the retailers aware that the changes were happening for real and happening now.’

He took it upon himself to ensure he was in regular contact with all stakeholders.  ‘I phoned them all regularly,’ says O’Shea.  ‘The team and I visited the outlets in person explaining how easy it would be to comply with the new branding and doing some communication management – dispelling any myths that were in circulation,’ he explains. ‘We had a really good response to this approach as the shopfits were being completed at the rate of four per week and the newly branded shops were reporting extra sales.’

‘I have likened the possible stalling of our project to the stalling of a jumbo jet, very difficult to kickstart,’ concludes O’Shea.  ‘We knew we had to keep up the pace firstly to get it all done, but secondly to carry the staff along with us.’

Would your stakeholders be motivated by money? Would an interest-free loan work for them, or help with the cost of adopting your project deliverables or staff overtime? If so, think about how you will build this into your project budget – and how you are going to convince your sponsor that it will be money worth spent. It could be worth getting some input from stakeholders in the form of ‘testimonials’ so that you have a bank of responses and data (maybe even through doing a questionnaire) to make your case.

If you can’t offer money, what is the closest that you can get? This could be support through using project team members as additional resources or something else that you could deliver within your budget which would add value and improve your chances of project success.

This case study first appeared in Project Management in the Real World (1^st edition) by Elizabeth Harrin, BCS Books (2006). It was replaced with another one in the 2^nd edition but I thought it was still worth sharing with you here.

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?