The Money Files

Are you struggling to keep your project finances on track? With stakeholders coming up with ‘critical’ amendments to the scope and more and more pressure on resources I wouldn’t be surprised if you, like many other project managers, were finding it difficult to stay within budget.

Here are 5 ways that you can try to keep your project budget on target, but be warned, they aren’t easy!

1. Say no

Yes, the first and simplest way to keep your project on budget is to just say no. Say no to cuts in your budget when senior executives want to make savings across the board. Say no to giving up project team members to other projects if that will make yours take longer and cost more because you’ll have to hire an expensive contractor. Say no to making costly changes.

As you’ll probably have realised, you need to have some significant influence in the business to be able to make these kind of statements, as most of the time it is your sponsor who is the decision maker and you are there to implement their decisions. So you may find that they only thing you can do is recommend that the sponsor says no. Try it – you never know what might happen!

2. Change the scope

You could recommend that the scope be slimmed down. Projects often go over budget because they try to achieve too much in one go. An alternative is to introduce phases. Suggest to your sponsor that Phase 1 delivers the basics (cheaply) and then alternative funding is secured for future developments.

The downside of this approach is that sometimes the future funding is never forthcoming and you end up with the basics, permanently.

There could be little areas of scope that you could negotiate excluding with your stakeholders. In exchange for ensuring the project meets budget they could be willing to forgo some additional bells and whistles. Ask them. They might agree with you.

3. Focus on the right changes

Change on a project is inevitable and it’s very likely that your project will see a lot of it. Unfortunately, changes can be costly. So focus on doing the right changes – the ones that will help you meet the stated strategic objectives of the project. If it’s a change that will make the product blue instead of green and it’s for internal company use only, talk to your stakeholders. Explain the additional time and cost involved in making the change and encourage them to stick to blue.

4. Avoid gold-plating

Is your team doing additional work that they really shouldn’t be? This is gold-plating. It’s when the project team add in new features because they can and because they think the customer will appreciate them. In many cases, the customer does appreciate them, because they’ve got a whole lot of extra features for free!

Don’t let your team gold-plate your deliverables. Stay on top of the scope and ensure they are only doing what they have been instructed to do. Anything else needs to be put forward as a change request and approved through the normal channels.

5. Cut quality

This is going to be an unpopular one, but it is something that you can do to save cash. Say your project is to set up a facility to make bricks and the bricks need to be of a certain standard. If you currently quality check 15% of all bricks to ensure they meet the standards, could you cut that to 10%? Lowering the rate for inspection would help save time and money, and unless your customer has specified that you must inspect 15% of the bricks before they will accept the facility, then you could make that change and still stay within your contracted terms.

Alternatively, say you are creating a new website. Customers enter their data and get a quote back for your services. If the response times for getting the quote could be increased, you’ll most likely save development time and perhaps even money on computer kit with faster processing power.

Have a look at your project and see if and where you could make some small changes to quality to save money, without compromising the overall integrity of the project.

That’s 5 ways to keep your budget under control, but I’m sure there are plenty of others. What techniques do you use to make sure your project comes in at its budgeted cost?

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?