The Money Files

The risk management process is helpful for more than simply sorting out your risks and stopping potential problems (and, I know, capitalising on the positive risks). Did you know it also contributes to managing expectations and dealing with a culture where talking about bad news has everyone running for the hills?

In this video I explore the hidden benefits of risk management and how it can help you keep everyone on the same page. Plus, we talk about how sharing risk info can contribute to a positive workplace culture where it’s OK to bring up worries and concerns.

There’s more in the video.

What do you think about this? What other hidden benefits of risk management have you seen while working on projects? I’m sure there are more unforeseen positives to holding risk workshops and talking about risk with the wider team! Let me know in the comments.

Pin for later reading

I’ve been working my way through The Practice Standard for Earned Value in an attempt to really get to grips with the nuances of EVM. It’s one thing understanding the high level principles, but another to understand the individual processes and how everything fits together to give you a rounded process.

The Establish Budget process is a way of converting what you need to do the project (equipment, resource availability and so on) to an actual budget that you can track against and use during project execution. Note that at this time we haven’t actually started the project yet, we’re still planning out how it’s all going to happen. Now is the time to plan out how much our activities are going to cost in a way that aligns with the EV principles.

The Practice Standard doesn’t go into a lot of detail about how to document your budget, so you can choose a technique and a software tool that works for you. Typically, EV management systems need a ‘proper’ financial management and accounting tool that links into the resource management software, so a spreadsheet isn’t really going to be enough.

See what provision is made within your EV set up at work and make sure you are creating your budget in the right tool so it can provide information to the software used for reporting and analysis.

Inputs

There are three inputs to this process:

• The project charter
• The responsibility assignment matrix (RAM)
• The schedule baseline.

The RAM takes the WBS and organisational breakdown structure (OBS) and converts that into a matrix that covers who is managing what control account and who is doing what WBS element. You need these control points so individuals are clear about the estimates and resources for everything on the schedule, so it’s really important to get that right.

If your schedule baseline is rubbish, then your EV data will also be rubbish. It’s so important that the inputs to this process are good quality, otherwise all your numbers will be wrong. Your budget baseline and schedule baseline can be iterated together, but they need to be robust and based on decent information so that you end up with sensible reports at the end.

What to do

There are four steps to creating your budget:

1. Establish the budget structure

This means listing out and understanding the different elements that make up your budget, including:

• The base budget
• The management and contingency reserves
• Distributed and undistributed budget
• Summary level planning budget
• Control accounts
• Work packages and planning packages.

Once you’ve got your structure sorted, you can move on to the next part.

2. Develop the cost estimate

Next, for each relevant component (the work packages, planning packages and the summary level planning budget) develop estimates.

Estimate at the correct level for the element and as accurately as you can. Control account budgets need to be linked to the time frames for the work, so that’s how the progressive elaboration of the budget and schedule come together.

3. Authorise the work

Next, there’s a formal approval step. This gives the control account owner permission to begin the work.

4. Update the budget log

Finally, update your project management budgeting tool to show that the budget is moving from undistributed i.e. not authorised for work to proceed yet to distributed i.e. linked to a control account that is underway.

That might be a very simple exercise because you’ve allocated everything out at the beginning, or you might be approving chunks of work as you go so some budget is held back until it’s approved.

The budget log is just a way to track what’s been approved for spending so far.

Outputs

The outputs from this process are:

• Project budget – obviously, because you’ve spent this process creating it
• Project funding requirements – because you use the cost estimates to come up with the overall amount you need to request (you’ll use the budget info for this)
• Project budget log – if you didn’t have a template set up before, you’ll have one now
• Control account plans (CAPs) – basically, a plan for each control account.

It’s important to note that EVM uses ‘budget’ and ‘funding’ to mean two very different things. The budget is defined in the Practice Standard as ‘a work planning element that is earned’ when the work is completed. It’s not really the same definition as we would use in a non-EVM setting, such as when someone asks you what your budget is for your next holiday, or what you budget for your food bill each week.

Funding is used to mean the amount of money ‘available to accomplish the work’. This is what I would normally consider to be a budget in a non-EVM project where control accounts aren’t part of project performance management. In the EVM world, funding relates to what you are actually authorised to spend on any given chunk of work.

It’s a useful definition because it keeps the earned value part of performance management separate from the money leaving the bank account, and allows you to manage any conflicts that arise, when, for example, you don’t get approval to spend all the money that has been requested for any given control account.

I learned something new on this dive into the Practice Standard today. What about you?

Next time, I’ll be looking at the next process in the earned value management standard, which is determining measurement methods.

Pin for later reading

So you’ve created a great risk log, worked out what your risk responses are going to be and made a plan to get those actions done. But how do you check whether your risk response plans are having the desired effect?

The thing I see a lot of project managers doing – especially early on in their careers – is setting up the action plans for risk management and then not going back to check that the risk is actually being addressed. It’s one thing to ask people to take action. It’s another thing entirely to check they’ve done it, and to make sure that the actions you planned have actually addressed the risk in the way you want.

The thing with risk is that even if you do address it with an action plan, you might still end up with residual risk – potential problems left over after you’ve done your ‘main’ actions. And you need to understand what those residual risks are and what (if anything) you are going to do about them.

Last time in this occasional series on project risk management, we looked at how you implement risk responses. Today we’re looking at the monitoring part: the step in the risk management process where you double-check to make sure that your action plans are effective.

What to look for

The point of doing this process (the Monitor Risks process) is to make sure that the current level of risk exposure, taking into consideration any actions you are doing, is still OK overall. You’re looking for new risks, changes in risk status (because some might be getting more serious or less impactful for your project).

Also look out for:

• What assumptions did you make about project risks that need a review? You might have more information now or you may need to include new assumptions.
• What risk management policies do you have and are they being followed? Would it help to update or revise procedures in some way?
• Are stakeholders still happy with the level of risk? The overall level of risk might change (and often does) as the project progresses because more risks are uncovered and that shifts the balance. Check in to make sure you are still in line with stakeholders’ expectations.
• How much contingency or risk management budget is left? Is it being used in the way that you expected? Do you need to ask for more and if so, how are you going to justify that?

Inputs

The inputs to this process are:

• The project management plan, and in particular, the risk management plan section
• Project documents including the issue log, the lessons learned register, the risk register (because this is where you will have written down what you are supposed to be doing) and risk reports (if you create them – I typically don’t, I just write down the details in a column on the risk log)
• Work performance data and work performance reports – in other words, have the action plans been implemented?

Tools and Techniques

The tools and techniques for assessing whether the action plans have had the impact you expected are going to depend on how you can judge success.

However, there are some common things you can do to review and the kinds of tools and techniques you can use include:

• Data analysis techniques like technical performance analysis (to compare what you have done against what was planned in a tangible way) and reserve analysis (to see how much money you’ve got left).
• Audits - my recommendation is that you get an impartial person to run this for you instead of trying to review your risk processes yourself. Ask the PMO or a trusted colleague.
• Meetings (because who doesn’t love a good meeting to discuss all the things that might go wrong on the project?)

Pick and choose the tools that will let you assess the impact of the risk (again) to see if it’s all squared away or if there is more you can do.

Outputs

The outputs of this process are:

• Work performance info
• Change requests (because your new plans might involve adding or removing tasks to your project schedule, for example, to do a few more risk response actions)
• Project document updates, especially to the project plan, assumption log, issue log, lessons learned register, the risk register and risk reports
• Organizational process assets that might need updating e.g. risk template or your IT system, workflows etc.

Another output is doing the tasks to address the residual risks or any other actions you’ve uncovered to make sure that the risk responses are getting implemented as planned.

This process is something you can do on a regular basis. I put time aside in my diary to do a review of risk, normally once a week as I’m updating my project documentation. Then once a month I’ll try to work a risk conversation into our project team meeting – sometimes we only talk about one or two risks, the ones that are the most important at the time or that are likely to happen soon.

Use your judgement – this process is only there to prompt you to constantly keep your risks and management activities under review. If you keep risks front of mind, you’ll be fine.

Pin for later reading

As your PMO grows in size and responsibility, you’re going to need to get more people to work in it. That can be quite a hard sell, as it’s often difficult to explain what the PMO does and justify the value it brings, let alone secure the funding for an additional role (or two).

In this video I share ideas for how to put together a successful proposal for securing project management office resources as your team gets bigger. Top tip: use statistics and evidence where you can to show that the remit of the PMO is expanding and that can justify the extra person to support the additional workload.

Tell me in the comments: how many people are in your PMO? Is it easy to get funding for additional resources or are you stuck at a certain team size because of an inaccurate perception about what the PMO does? I’d love to hear!

Pin for later reading

Is it time for your project to wrap up? Congratulations! In this infographic I share a few tips for closing down your project in a smooth and controlled way.

These are things I’ve learned over time, because I’ve struggled in the past to get people to take responsibility for the stuff that the project has delivered. I’ve realised that a strong closure process and handover to the operational team is crucial if you want to be able to walk away from the project and not end up as the ongoing informal support person for whatever it was that you delivered.

In brief, my top suggestions for the closure process (not so much the handover to live, that’s a whole other topic) are:

• Close off everything on your project schedule by marking it as complete.
• Update the risk log and copy open risks to the closure document.
• Organise a post-project review to talk about how the whole thing went.
• Celebrate! Don’t forget this part 😊

Whare are your top tips for the last stage of a project? Share your ideas for making the project closure process as smooth as possible in the comments below!