The Money Files

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!

The Practice Standard for Earned Value sets out the Develop Schedule process, which is simply a way of turning all the stuff in your WBS into a workable plan with timescales. Basically, it’s time to turn the WBS into a Gantt chart.

I guess you could use earned value for non-Gantt chart scheduling, but I can’t get my head around how that would work (tell me in the comments if this is something you do!).

The Practice Standard doesn’t go into loads of detail about how to make a project schedule, as there are other places you can go for that information – like the Practice Standard for Scheduling and also the PMBOK® Guide. However, the particular earned value bits of scheduling are covered in the EV standard, and especially this process.

Inputs

There are two inputs to this process:

• The scope baseline
• The resource breakdown structure.

The scope baseline is more than just the WBS. It also includes the scope statement and the WBS dictionary, so it’s the full set of documents about project scope and the full understanding of what the scope is. It’s the exact spec to a level of detail that allows someone in the team to get the work done.

The resource breakdown structure is the comprehensive guide to who is working on the project as well as the other, non-people, resources required to get the job done.

What to do

The Practice Standard is light on the ‘how to schedule’ element, as I mentioned above, but from a specifically EV perspective, here’s what to take into account:

• Create the schedule in a scheduling tool.
• Make sure dependencies are noted and accounted for, using the scheduling features of your tool
• Manage the relationship with the budget by setting up whatever you need to in the system that will manage that relationship. This might mean setting up control accounts in your accounting software or however you are tracking the budget figures for the project.

This last part is particularly important because it’s the way the schedule and budget relate that drives the EV calculations. You need the same dates, milestones, assumptions and resources set up in each so the measurement is consistent between both systems. In other words, you need to be sure that the work being done is accurately accounted for so that you are working out the right planned value.

Finally, get your project schedule approved the normal way and it then becomes the schedule baseline, against which you can track progress and monitor performance.

Outputs

The output for the Develop Schedule process is only the integrated master schedule, as you would expect.

The ‘master’ part of the IMS, as I understand it, is a way of referring to the fact this is the top level project schedule. The control account managers may have detailed sub-plans for their parts, and you might have intermediate level plans, depending on how complicated the project is. But the IMS – the master schedule – is the full picture of everything required to get the project done.

Dealing with changes

As with any aspect of project management, we have to allow and account for what happens when things change. It’s great to have the IMS as your overarching master schedule and performance measurement baseline, but it’s unrealistic to think that we’ll deliver everything perfectly to plan because that isn’t what happens in real life.

So, we need to use the change control process as and when needed, to make sure the whole thing stays aligned to actual performance. That’s not to say you’ll be re-baselining the project every day, but you will keep the schedule up to date with real progress to compare back to the original baseline, and then re-baseline if and when that becomes appropriate.

If you make schedule changes, you also need to consider what that means for the project budget. When using EVM, you can’t get away from the fact that the two need to align – that’s the point of this way of project tracking, after all.

The IMS exists as a way to outline what the team is planning to do and it gives you the logic for measuring performance. It’s important to get it as good as it can possibly be because it’s what future progress will be measured against and it’s used for calculating future outcomes – and you should want those to be as accurate as possible.

Next time, I’ll be looking at the next process in the earned value landscape, which is establishing the budget.

Pin for later reading

I’m surprisingly enjoying my deep dive into earned value management – it’s not a technique I would say I’m hugely experienced in, but it’s something I’m committed to learning more about.

In this infographic I summarise the 5 limitations of earned value:

• Numbers don’t tell you the whole story and you need a bit of contextual narrative too
• Data has to be accurate otherwise you’re making assumptions and predictions based on what isn’t truly happening
• Quality has to be assumed because EV doesn’t factor in quality as part of the way it measures performance
• EV and Agile aren’t perfectly aligned but that’s OK because if you’re in an agile team you’ll have other (more appropriate) ways of measuring performance
• There is a lot of jargon! And the words sometimes can get in the way of being clear about what you are talking about.

What other limitations of Earned Value have you come across as you’ve used it? Or perhaps you aren’t using EV because of another limitation that is stopping you from embracing it in your environment? Let us know in the comments below!