The Money Files

How do you talk about risk? Do you talk about negative and positive risk, or threats and opportunities?

And do your colleagues use the same terminology? As a project manager, we need to be able to have conversations about risk – and make sure that the people we are talking to understand what we are talking about! That can be hard to do if you don’t have a standard risk language – terminology that everyone in the business understands.

In this video I talk about the benefits of standardising the way you and your team talk about risk because. With standard vocab you can gain better buy in for your risk management actions because people get what you want to do.

It also allows for comparability between risks between projects, programmes, portfolio and the enterprise level. By all using the same definition of ‘major’ to describe a risk assessment, for example, you ensure that everyone understands the same thing.

This video talks about how to have a conversation about standardisation, and what you can do as a project manager even if you think you aren’t in a position to influence corporate standards on risk.

Pin for later reading:

This question: What is project cost control? comes up quite a lot. I’m not sure exactly why, but I think it’s to do with project managers wanting to make sure they are putting adequate measures in place to monitor and control spending. After all, it’s not our money. We are responsible for making sure it gets spent in a way that supports the project’s objectives and is fiscally responsible. It can feel like a lot to ask.

In my experience, it is actually easier managing huge sums of money than it is managing smaller amounts. On a teeny budget, every dollar counts. The larger the budget, the easier it is to manage because you have latitude to make decisions within your control and tolerance limits, such as approving an extra $50 for something or dealing with an invoice that’s 10% more than you expected. Having financial responsibility is a good way to help manage roadblocks and get things done on a project.

OK, so what do we mean by cost control? Generally, we’re talking about processes to do with:

• Budget planning
• Estimating costs
• Budgeting
• Financing and funding i.e. finding the money from somewhere, applying for grants, securing financial support etc
• Managing costs i.e. the day to day operational effort of raising purchase orders for the correct amounts, receiving and matching invoices, tracking line items of project spend and ensuring that what you are spending isn’t more than what you thought you would.

All of these help to ensure the project can be completed within the approved budget.

One of the biggest areas of focus for cost control is budget tracking.

What do you track in a budget?

Let’s say you’ve started the work. What is it that you should be tracking through the project?

You can track:

• Forecast expenditure: What you are predicting to spend for the rest of the project
• Actual expenditure: What you are actually spending.

Actual expenditure itself is a bit of a vague term because it’s often used to encompass three other terms:

1. Committed spend: money you have definitely committed to spend. For example, you’ve raised a purchase order or placed a firm order for services or goods.
2. Accruals: where the work has been completed (or partially completed) but you haven’t paid for it yet, or you haven’t paid all of it yet.
3. Actuals: this is what we typically think of as ‘actual expenditure’. It’s money out the door, leaving the bank account, to settle an invoice or otherwise pay for something. The money has been physically spent.

Tracking budget KPIs

Another part of cost control is making sure that any financial reporting for the project is complete. Cost is normally a big factor in deciding whether the project is on track for success or not – I’ve certainly found execs to be very interested in the cost performance of projects, especially the larger budgets. They want to know the money is being spent in the way they expect and that we’ve got enough of it to get to the end.

Cost is typically a key performance indicator, but you might find it worthwhile to track other budget related KPIs. In a programme, you might track return on investment for projects that have completed, for example.

Who does project cost control?

The project manager is often fully responsible for project budget management, but you could also have a Finance person attached to the project (I had this once – he was great). Depending on the size of the project, and the size of the budget, you may be able to have someone on the project’s senior team leading on cost tracking.

Your corporate Finance team will also be involved, even if much of the day to day handling of invoices etc comes to you. They may rely on you to approve invoices (because you are best placed to confirm the work is complete) but they’ll be processing the payments in operational systems and checking they have been correctly posted to the right cost centre for accounting purposes.

Checking viability

Another part of cost control happens when the project is formally reviewed. The review happens anyway, and cost is part of the discussion, and part of the decision about whether the project is still viable.

One of the factors to take into consideration is sunk costs – costs that can’t be recovered because they have already been spent or committed including costs that would be incurred if you cancelled a contract or similar.

However, execs sometimes look at sunk costs and think they must continue the project because they’ve already spent money on it, even if all other signs point to the project being stopped. The viability check needs to take that into account: but why throw good money after bad? If you can’t salvage the project, don’t spend more on it just to get it to ‘done’. That would continue to be a waste of resources.

The project manager’s role is to input to these kinds of discussions with full facts and an approach that draws on commercial acumen, so the team ends up making the right decision for the future of the project.

Planning for risk

Finally, cost control also involves planning for financial risk – in fact, planning for any type of risk.

Dealing with risk costs money, because you’d want some kind of budget to pay for risk management actions such as mitigating the potential problem. Risk and issues can mean paying out for things you didn’t expect to have to fund.

The more risk budget planning you can do, the better prepared you will be, and the less likely it is that your overall budget will suffer. You’ll have more time and money to deal with the problems because you planned for them.

Pin for later reading:

There are loads of things that make a project complex, and in the past I’ve written about criteria for complexity and what ‘true’ complexity means.

However, I’m now leaning towards the opinion that if you think it’s complex, it’s complex. The benchmark from which to approach managing complexity is whether you are worried about it being complex. Because if you are struggling with all the moving parts, then other people in your business probably are as well, and you all need strategies to get things feeling more comfortable.

OK, your project might not tick all the boxes for ‘pure’ complexity as defined by academics, but who cares about that, right? We want YOUR project to be successful, and that means meeting you where you are, and dealing with the stakeholders and the situation you find yourself in.

So when you’re feeling like things are getting out of control and the complexity level on your project is spiralling, what can you do about it? The infographic below sets out – in a high level way – three ways you can start to approach complex situations. Ultimately, the aim is for you to feel like things are under control.

Take whatever steps you need to that help you identify where the complexity is coming from and then break it down to deal with each part.

There’s more information about how to reduce complexity on projects in this article.

Pin for later reading:

We all know we have to do risk management on projects. And beyond that, our businesses should have enterprise risk management in place, because… well… it’s the right thing to do.

However, if you’ve ever had to convince a project sponsor that it’s worth spending time on risk in a project board meeting, then you’ll know that sometimes not everyone feels the same way about risk management.

When you need to have conversations with your stakeholders and teams – and perhaps even the leadership in your organisation – about why risk management is a worthwhile endeavour, then this video will help.

I talk about the benefits of managing risk at an enterprise and project level. Specifically, we do risk management:

• Because it meets mandatory requirements
• For assurance
• For effective decision making
• For process efficiency.

Watch the video below and then let me know – what are the benefits of risk management that are the most important to you?

Pin for later reading:

It’s time for the sixth and final part of our look at the Scope Management Knowledge Area from the PMBOK® Guide-- Sixth Edition. We made it! Thanks for sticking with me to the end on this one. It’s a process with a lot of moving parts!

You can find the previous parts of this series here:

• Plan Scope Management
• Collect Requirements
• Define Scope
• Create WBS
• Validate Scope

The Control Scope Process

As we’ve just seen, this is the final process in the Knowledge Area. We are still in the Monitoring and Controlling process group.

The point of this process is to manage changes to the scope baseline as you go through the project. The purpose is to ensure you’ve got clarity about what the project is going to deliver. You’ll do this process as you go, at various points through the project life cycle. Basically, whenever there is a possible change to scope. In fact, you might not need it at all, on a simple project where the scope doesn’t change.

That’s possible, but unlikely! I don’t think I’ve ever worked on a project where the scope at completion has been identical to the signed off scope as part of the Project Charter… but I’m sure it does happen.

You have to use this process in conjunction with the Perform Integrated Change Control process. This process ensures the changes and actions go through that process. Plus, Control Scope is also used to manage the changes once they’ve been approved, and because of that it’s got links to all the other Control processes.

Inputs

We’ve got the same changes to this process as we saw in Validate Scope. Basically that means requirements documentation and the traceability matrix is out, and the generic ‘project documents’ is in. Therefore, the inputs to this process are:

• Project management plan
• Project documents
• Work performance data (e.g. documentation about the number of changes received and processed – reporting your PMO might find useful about how the project is handling change, as the frequency and type of change can tell you quite a lot about the stakeholders and how the project is being managed)
• Organisational process assets.

In this context, project documents could include the lessons learned register (because at every point in the project you can learn from what’s gone on before), requirements documentation (obviously) and the traceability matrix.

Tools & Techniques

There was only Tool and Technique in the Fifth Edition: variance analysis.

That’s gone. And now we have the broader term, data analysis. Which includes, surprise surprise!, variance analysis. And also trend analysis which looks at project performance over time. If a project is getting more and more changes as it progresses, that can provide useful information about the quality of requirements or how under control the work actually is.

Outputs

There’s a tiny change to the outputs of this process.

The outputs are:

• Work performance information
• Change requests
• Project management plan updates
• Project document updates.

Organisational process assets has dropped off the list.

The thing with scope changes is that they affect so much. Anything that goes through change control can have a fundamental impact on the project so you’ll want to update all the records to make sure you’ve got accurate notes about what you’re now doing and why.

So you might update the scope management plan, the baseline, the schedule baseline and cost baseline. On top of that, you could be updating the lessons learned register, requirements documentation and that traceability matrix.

Frankly, it’s easier if the scope doesn’t change! But as it is almost guaranteed to change at some point, you need to be prepared to put the work in to update all the documentation and tell everyone what’s now going to be the new approved scope.

And that brings us to the end of this process, and our trip through the world of Scope Management.

Pin for later reading: