The Money Files

Video transcript, for those of you who prefer reading:

Hello.

My name is Elizabeth Harrin from the Gantthead blog, The Money Files and today I want to talk about cost breakdown structure. You have probably heard about work breakdown structure and product breakdown structure before but I wonder if you have heard of cost breakdown structure. Effectively it looks very similar to a work breakdown structure and you need a work breakdown structure to start with.

Take your WBS, your work breakdown structure and add to each task your estimate of how much you think that task will cost to complete. Effectively, if you add on the values for each of those project tasks you’ll be able to work out at any level exactly how much the project will cost overall. The great thing about this is that you can add up the costs in chunks so you could create an overall cost for a work package or for a particular level of task.

The good thing about that is that you can then use that to help influence your scope. For example, if your scope needs to be cut because you don’t have enough money to complete everything in time you could look at your overall work breakdown structure with the costs, your cost breakdown structure, and look at what you could potentially lose.

Equally if you are including a change to the scope of your project you can look at what elements of costs would need to be changed as a result of adding something new on to the cost breakdown structure.

You might be thinking that all sounds great but how do you add contingency to a breakdown structure that is constructed in that way?

You’ve actually got a couple of options and Mike Clayton talks about them in his book, Risk Happens! I’ve got that here. There are two ways really that he talks about including contingency in a cost breakdown structure, either at the level of tasks so you could either add in contingency for every amount on every lower level task, or you can add it at the top level, or you could add it at a subsidiary, middle level on the structure as well. So that was one alternative.

But the option I like the best is this and his recommendation is this, to “add contingency at the level at which the budget will be managed. In this case” – in the example he gives in his book – “In this case the budget is managed at workstream leader level.” So what he has done in the example he has given here is to add contingency in the cost breakdown structure at the level at which somebody has responsibility for a chunk of work. So he has added contingency effectively to the task that is going to be managed by the workstream leader.  And that has given him the opportunity to be able to give someone responsibility for managing the budget and be able to track that and use the contingency as they see fit within the remit of what’s on their element of the work breakdown structure.

So I think cost breakdown structures could be a really good way to calculate your budget.

In this instalment of Ask the Experts I talk to Mike Clayton, author of Risk Happens!

Mike, what sort of budget-related risks might projects face?

“Cost over-runs” will be one of the first risks identified as soon as a project team starts brainstorming risks.  Of course, it is not a risk at all, it is and outcome.  Your question is critical – and to frame it in a more helpful way, “what are the uncertainties that can affect the financial outcome of a project?”

Of course, the answer will be highly situational and depend on the nature and detail of your project, but here are a few of my favourites:

• Poor specification, coupled with inadequate change control processes
• Superficial or inaccurate briefing of contractors or sub-contractors – often compounded by weak management processes
• Inadequate attention to planning  leading to unreasonable budgetary expectations – often influenced by unhelpful political pressures to “keep the budget down”
• Unrealistic allowance for pilots, prototypes and testing, leading to failures and delays that should have been budgeted for
• Overly aggressive negotiation by buyers and senor users leading to squeezed budgets and over commitments from the project team

You will notice that none of these look anything like the force majeure items of natural disaster, industrial action or catastrophic failures.  All of my favourites make the list because they are entirely predictable and can be readily accommodated by a realistic approach to risk from Day Zero.

OK, that’s sensible. How can we better identify risk then, so that project managers don’t just stick with the force majeure items on their risk logs?

There are lots of great techniques for identifying risks and it seems a shame to me how few are deployed on the vast majority of projects.  We all know that brainstorming is a good – but not great – technique, yet it is still everyone’s favourite, in my experience.

But, as you are asking about financial risks in particular, I want to advocate for a very powerful, yet easy to deploy, approach.  Easy to deploy, that is, if you are planning your project well in the first place.  Any substantial project must have a robust plan and at the heart of your planning process is a work breakdown structure (WBS).  And it is only one more step to create a cost breakdown structure (CBS) that builds your project budget up, step by step from the components of your work packages. 

This works whether you are based in the US, where WBS tends to be built from a product based analysis or in the UK, where we would call that a product breakdown structure and build our WBS from a task orientation.

Now simply review every item of cost on your CBS critically and ask:

• What assumptions have we made?
• What uncertainties remain?
• What could go wrong?

Do you think Earned Value Analysis is a big help to project managers looking to manage financial risks on their projects?

I look on Earned Value Analysis as the gold standard of the intersection between project delivery management and project financial management.  It won’t so much reduce your financial risk as give you a powerful tool to spot trends that will allow the wary PM to act early to address time and schedule over-runs.  Early action is at the heart of maintaining control and good information is essential for triggering the analysis that informed action needs.

Where the overhead of implementing EVA is merited and the project team is fully trained, EVA is a tool for financial risk management throughout the delivery stages of your project.

The delivery stage is a critical time, and that’s the point that conflicts arise between risk and return, when things are changing and stakeholders are keen to see progress. How can project managers handle that conflict?

Firstly, by not thinking of it as a conflict! There is a rational judgement about a trade-off to be made, which must be informed by sound estimating based on the best available data and robust methods.  That judgement must weigh risk and return and will often be a debate to be had within organisations.

Your role as a project manager is to:

• Gather the evidence and data
• Ensure the analysis is robust
• Place the analysis in an objective form before the right decision makers
• Ensure that the decision makers fully understand the analysis
• Facilitate a careful discussion
• Document the final decision

The “conflict” is a matter for good project governance.

It sounds as if project managers need to spend more time thinking about project risk, to head off some of these problems and be better prepared to make these judgements.

Yes. I think it interesting that the PMI’s Pulse of the Profession report for 2012 states that “change management and project risk management will become even more important core competencies” in 2012.  That can only be a good thing.  Whilst they remain the domains of Special Interest Groups within PMI and APM, too many project managers will see them as at best a specialist component to be delegated to a colleague and forgotten or, at worst, as an optional extra to project management.  I would like to see more projects and programmes putting risk management front and centre of the processes, routines and behaviours.

Thanks, Mike!

Risk Happens! is published by Marshall Cavendish. Find out more at http://www.riskhappens.co.uk or check out Mike’s website at http://mikeclayton.co.uk/

A couple of times people have said to me that sharing the project budget with their team members is Not A Good Idea. I don’t know why that is the case – they are stakeholders too. I think it is essential to be transparent about the budget, how it was created and how you, as a team, are doing with spending it. It helps the project team come together with a common objective, and it helps build trust in the way in which things are being done.

In his book, Employees First, Customers Second, Vineet Nayar talks about 5 ways that transparency helps build trust among the stakeholder community.

1. Understanding the bigger picture

“Transparency ensures that every stakeholder knows the company’s vision and understands exactly how his or her contribution assists the organisation in achieving its goals,” Nayar writes. In project terms, it is difficult for a project team member to contribute effectively without knowing what the bigger picture is. In budget terms, if team members don’t know how things are going overall and how much their elements are costing, they cannot help work more efficiently to get the job done.

2. Generating personal commitment

Nayar says that transparency ensures that “every stakeholder has a deep, personal commitment to the aims of the organisation.” I don’t believe this is true. Transparency may contribute to building this, but it is not the only way you get people to feel as if they are personally committed to a project.

3. Transparency is a given for Gen Y

The younger project team members will expect full transparency, and without it they will be suspicious and untrusting. “They post their life stories in public domains,” says Nayar. “They expect nothing less in their workplaces.”

Again, there is more to this than I think he brings out in the book. Transparency about the budget and all other elements of the project will help generate trust in team members of all ages. Generation Y team members may have a different expectation of what is appropriate to share, but sharing (or not sharing) will have an equal impact on the trust levels across the entire team.

4. Corporate transparency promotes customer transparency

Nayar says that in a knowledge economy, it is important for customers to share their ideas with companies. This is the way that we find out what products they want, how their lives are evolving and what would make their lives easier. They may also have ideas about solving problems with our products or corporate challenges that we are facing. “Why would a customer be transparent with a potential partner like us if that company does not trust its employees enough to be transparent with them?” Nayar asks.

This is a fair point. While I would not advocate sharing the project budget with customers (unless your work is in the public sector and this is therefore expected), it is a good idea to share the budget predictions with your suppliers and partners. Why not? It will help them pitch their services at a price that creates a win-win situation for you both. In one case I heard about recently, a supplier opted not to pitch for work when they heard the budget figure that the company in question had available. It saved both the company and the supplier a lot of time in the tendering process. Share your budget figures with people outside the immediate project team. Or at least consider reasons why you shouldn’t, and then critically assess those reasons to see if they still stand up.

5. Transparency helps contractors

Finally, you need to consider the work of contractors. “The only way these outsiders can get up to speed quickly and be as effective as possible is through sharing of information and complete transparency about the strengths and weaknesses, the issues and concerns, of the assignment,” Nayar writes. “The more transparent the process, the more trust that the outsiders felt in the organisation, the more we could reduce the amount of learning time, which would give us an advantage over our competitors.”

If you share project information with contractors, it helps them feel more comfortable in their role. It will also help other team members, who have to deal with these contractors, feel as if the contractors are offering a valuable service and are actually making a contribution. If the contractors operate without full visibility, other team members may well feel as if they cannot trust them to make the right decisions because they do not have all the relevant information.

How transparent are you with your project budget? Do you share this information with stakeholders as willingly as you share other project information? If not, why not?

“Influencing stakeholders is something we do from birth,” said Guy Giffin, speaking at the latest APM Women in Project Management conference. “As soon as you are dealing with more than a couple of stakeholders, you’re dealing with a number of conflicting views and interests.”

Giffin explained that “the same old things” keep turning up on the list of challenges for projects and that they nearly all have some link back to the humans involved in running the project. “It’s hard to give you a recipe for success,” he said. “Some analysis is scientific but building relationships is more art. Charm certainly comes into it.”

Giffin shared his 4 step process for managing stakeholders with the audience. “Some people get hung up about ‘engaging’ instead of ‘managing’,” he said. Whatever you call it, you need to go further than just plotting names on a chart and analysing impact and influence. Here are his 4 steps to better stakeholder management.

1. Identify

“Some appropriate questions asked in the right way can get you some good information,” Giffin said. The pool of stakeholders is probably wider than you first thought, so asking individuals for their view on who should be involved is a good way to identify your full stakeholder group.

2. Profile

The more you know about them, the easier it is to manage them. Giffin recommended finding out all you can about the stakeholders you have identified. Do this via their LinkedIn profiles, the company annual report (for the C-suite executives), a Google search or just by asking around.

3. Define

This step is about defining their role in the project. They may be the budget holder, or a representative of a group that needs to be kept informed. Determine what their role is and then you can judge the best compromises to use.

4. Sell

Giffin recommends using “all your weapons” to sell the project to the stakeholders. He talked about using allies on the project – those key stakeholders who strongly support the project’s aims. Get them involved in the sales activity on the project and encourage them to spread the word about the initiative and the changes that are coming. Use public relations activity – get your PR team involved and do as much communication as possible. Use internal newsletters, a wiki or an intranet site for this.

Project managers need to become experts in managing relationships. We need to understand EQ – the emotional equivalent of IQ. We need to be skilled in political science to be able to navigate through the boundaries of organisational politics. We need to understand social psychology. Good stakeholder managers are experts in communication and listening. They are great at consulting and they show deep empathy with the people they are working with, and working for. “It’s a bit of science, a bit of art, and a bit of luck,” Giffin said.

How to sell when you have no money

One of the questions from the audience was about how you can win over stakeholders when you have no budget for entertaining or ‘schmoozing’. “Asking good questions is a good start,” Giffin replied. There is a lot of mileage to be had in making sure that you have a proper, full understanding of the challenges facing stakeholders and the concerns they have about the project. Spend time with them understanding their world, and asking intelligent questions.

Once you have done that (and this is the bit that Giffin didn’t really cover) you need to follow up on your discussion sessions. It’s no good asking questions if you cannot resolve any issues that are raised. Even if there is nothing you can do, go back to the stakeholder in question, thank them for their input and explain why you cannot make the change they requested. This is an easy, free way to build a good relationship with stakeholders when your project budget does not stretch to corporate hospitality.

Just a note on hospitality: if you do decide to go down this route and host events for stakeholders or similar, be careful not to fall foul of the law in this area. In the UK, the Bribery Act sets out what you can and cannot do in a workplace setting, and I’m sure other countries have similar regulations.

This month, the discussion topic here at Gantthead is stakeholders. Project stakeholders need documents – but how do you know how much documentation is enough? Unfortunately, the answer is always, “It depends.”

The amount of documentation stakeholders need to feel comfortable depends on:

• The project scope
• The project size
• The project’s requirements and how complex they are
• Any legal requirements
• Any financial requirements
• Your company’s documentation standards (although you could flout these if you have good reason)

According to Tom Kendrick in his book, 101 Project Management Problems and How to Solve Them, there are three types of project management document:

Definition documents: these define the project so include things like the project charter, requirements catalogues and organisation charts. Stakeholder management/engagement grids and analyses also fit in here. Definition documents might sound static, but they actually need updating regularly as things will always change.

Planning documents: these help the project team plan the work. They include the plan (of course), risk register, the project schedule, and any other project-specific sub-plans like a communications plan.

Status documents: these are the documents that stakeholders are generally most interested in. While they should be interested in the requirements and the risk log, you’ll find that the majority of stakeholders only really want to know how things are going and what they have to do next. Status documents include the things you would expect like regular reports, the issues log and follow up actions, the change log and other regular, non-standard documents that discuss status like meeting minutes.

Where does your project budget fit in all of this? Well, it’s partly a definition document: as part of the project initiation activity you would have defined the budget in the project business case or initiation document. But it’s also a status document: the real-time changes in the budget and tracking how much you are spending is very much related to project status.

You may find that it is easier to have two versions of the project budget: one definitive, signed off, formal version of the budget that never changes and acts as a reference point (your project budget baseline) and another as a living document that you update for quarterly forecasts and use to record actual spend. Personally I spend much more time on my living document than I do going back to the original, but I know that at the end of the project I will be expected to justify any changes to budget in the post-implementation review, so it’s important to still have those figures unchanged, with details about the project assumptions that helped shape them as no doubt by the end of the project I will have forgotten why the budget was set up that way.

Those two documents are ‘enough’ for my project budget. I can pull extracts or summary figures for my status reports, and that satisfies my stakeholders. How do you manage your project documentation, and do you find yourself doing just enough, or producing documents that no one ever looks at again?