The Money Files

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!

This is an occasional series on project risk management, and last time we looked at what options are available to you as part of your risk response strategy. Today, we’re looking at how do you actually implement risk responses.

There’s a whole risk response process in the PMBOK® Guide that helps you work out how to approach this part of managing your project.

The Implement Risk Responses process is where you take your response plans and actually do the work to make them happen. The execution of risk response plans is important because you can’t always rely on talking about a potential problem as enough to get it remedied.

There’s no single time to be doing this – you’ll be identifying risks the whole way through your project, so as and when you’ve come up with a new one, you’ll prepare the risk response plan and then implement it. Make time during the project to ensure you think through how to do the implementation part of the risk response strategy – incorporate it into your regular risk meetings.

Inputs

The inputs to this process are:

• The project management plan, and in particular, the risk management plan section
• Project documents including 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 have them
• Organisational process assets.

The risk management plan will include the names of people responsible for the risk management process, and that’s helpful for assigning ownership of the management actions. You may also have info in there that relates to the level of acceptable risk – this is what you are trying to achieve by doing your risk management activities. It’s not always necessary to remove the risk completely; sometimes just reducing it to a level that’s acceptable to the project or the business is enough.

The OPAs are things like the corporate lessons learned repository which might give you insights into how other risk management approaches were implemented and what were effective techniques at doing so.

Tools and Techniques

The tools and techniques are going to depend very much on what kind of implementing you are doing. How to implement the ‘acceptance’ strategy is obviously very different to an approach where you are going all-out to mitigate it with a huge action plan.

However, there are some common threads to what kinds of tools and techniques you can adopt here, including:

• Expert judgement (drawing on the expertise of your team leaders and your own knowledge about how best to implement the plans)
• Interpersonal and team skills, especially influencing – that’s mainly going to fall to you to ensure that the work gets done
• Project management information system (document and record what you are doing).

Basically, use your PM knowledge to ensure that the planned actions for risk response actually happen.

Outputs

The outputs of this process are:

• Change requests (because your plans might involve adding or removing tasks to your project schedule, for example)
• Project document updates, especially to the issue log, lessons learned register, team assignments (as people’s work assignments need to be updated to reflect their new tasks), the risk register and risk reports.

And, of course, the work of doing the risk responses – built into your To Do lists and action logs, and discussions with team members.

As you get more experienced with project management, you won’t spend much time thinking about ‘doing’ this process. It just happens naturally as part of the things you’re doing on the project. It becomes an integrated part of how you manage risk, and so much aligned to the other parts of risk management that it all flows together. I don’t have meetings where I sit down and say, “Today we are going to do the implement risk responses process.” That’s just not a called out part of how we make risk management happen… but the process does happen. It’s simply integral to everything else and a natural part of how we work together as a team.

The process exists to remind you to make sure that risk responses aren’t something that you simply talk about. You want to avoid that issue of writing down risks and having a lovely risk log, but all the risks sit on there and nothing happens to actually take action on them.

Next time I’ll be looking at how to monitor risks to ensure that your action plans are being carried out as you would expect and are having the right impact on your project.

Pin for later reading

Let’s say you’ve been asked to look over a business case, or your sponsor has drafted a basic business case and has asked you to get it ready for the next review.

In this video, I’ll give you 5 things to look out for: 5 red flags that are worth spotting before your business case gets too far through the process of project acceptance, because if you don’t resolve them, the project will be really hard to manage and you’ll have all kinds of expectation management issues.

Enjoy the video!

Pin for later reading

The Practice Standard for Earned Value sets out the Assign Responsibility process, which is simply a way of making sure everyone knows who is doing what. It’s important in earned value because you need someone to take ownership for every piece of work – that’s the best way to track at each individual element of the work breakdown structure.

Inputs

There is only one input to the Assign Responsibility process and that’s the scope baseline.

What to do

Assigning responsibility isn’t a great name for this process, because ideally individuals in the team will volunteer for the responsibility, knowing that it is part of their job role. I prefer to allow people to step into the responsibility rather than forcing it on them, because I think you gain better buy in and results that way.

However, sometimes I have been known to specifically say, “So I’ll write you down as the owner for that task?” and call out someone as the individual responsible, in a nice way.

Assigning responsibility is about more than someone knowing it is their job to do the work. It’s also about making sure everyone else knows that it is their role, and that it is officially documented somewhere. That’s what this process does.

Create an organisation structure for the project. I tend to do that in PowerPoint, simply making a structure chart with names on that I can then drop into the relevant project documentation. You might have to create several ‘layers’ of your chart so that everyone responsible for substantive pieces of work for the purposes of EV tracking has their information documented.

The Practice Standard recommends that you take the list of people responsible for things and map them against the WBS to create a matrix instead of using an org chart structure. That certainly gives you more granularity and makes it very clear who is doing what.

Outputs

The outputs for the Assign Responsibility process are:

• The organisational breakdown structure – the hierarchy diagram that shows which team/area are involved in the project
• The Responsibility Assignment Matrix

The RAM matrix is a bit different to the traditional RACI matrix because it lists the work packages from the WBS across the top and then the teams or individuals down the side. Look at the relevant intersections and where they meet, put a cross to mark the fact that this person (or team) is responsible for this part of the WBS.

Each X marks a control account: an area of work that is going to be tracked and managed by a control account manager. This is the team leader responsible for doing the work, but CAM is the term used in the world of earned value.

How detailed should you make the plans?

There’s no right answer to this. The WBS and the OBS should be as detailed as necessary to get the job done. Go down to the right level for your project – you’ll have to use your professional judgement for this.

Ideally you are looking for control accounts to be at a level of complexity and scale that makes it possible for them to be managed adequately by one person. Too detailed, and you’ll end up with people responsible for fragments of work and so many control accounts that they are hard to manage in their entirety. Too few and the CAMs won’t truly be able to control the work within them as the tasks will rely on too many people or activities outside of their control.

Plus, think about how much time and energy you and the CAMs have got to dedicate to the admin of running a low-level, detailed plan. Do you really want to take on the management of a lot of tiny things? Isn’t there some saving to be had in combining a few more work packages and making your control accounts sit at the next level up?

Ultimately, you’ll have to make the call but don’t make it too hard for yourself or your team.

Managing changes

You might be thinking: that’s all very good but what happens when things change? Well, things always change, and you have to be alert to that. Respond to changes as and when they happen, using the change control process that you’ve adopted.

Make sure that the CAM impacted by the change (or group of CAMs if there are several) know what has changed and what that means for their work. Update the documentation accordingly. That assumes that you know about the change before the CAM – and sometimes that won’t be the case. They’ll be coming to you with suggestions for changes, so in that case, push them through the change control process and update the rest of the team as appropriate.

The Assign Responsibility process is really all about making sure people know what falls into their remit. If you work with an experienced in-house team, you probably won’t have much difficulty here. If you work with contractors, sub-contractors or external suppliers, make sure that the boundaries of their work are clear – this process helps formalise all of what you should be doing already.

Pin for later reading

Opportunities are positive risks – the risks we don’t spend much time thinking about because everyone assumes risk is bad!

However, if we use Dr David Hillson’s definition of risk as being uncertainty that matters, then some uncertainty could most definitely lead to a positive outcome for the project. Those are opportunities, and we handle them in the same way that we do the ‘negative’ risk or threats.

There are 5 strategies for responding to opportunity risk and they are:

1. Escalate
2. Exploit
3. Enhance
4. Share
5. Accept

Let’s look at each of those.

1.Escalate

Escalation is also a tactic to use for threat risk and the same approach applies here. When the opportunity is bigger than the project and falls outside of the scope of your work, escalate it up to the programme manager or portfolio manager, or simply pass it on to your boss. There’s nothing you can personally do about it as the opportunity falls outside of your level of authority. Your job is to make sure that the information you have is passed on to someone who can best act on it.

You can continue to support whomever picks up the information but you don’t have to track and manage the risk any longer.

2.Exploit

This strategy is where you basically force the risk to happen so you benefit from whatever good things are coming your way. You want to increase the probability of occurrence to 100% because it’s worth it.

That might include spending money or changing the direction of the project to make sure that you get the outcome you want. For example, you could pull resources from other projects on to your project to make the work take less time, you could upgrade some infrastructure to take advantage of technological advances by being able to use new solutions and so on.

I don’t really use this strategy much because I tend to think that if we take steps to make something happen, it’s not a risk any more, but that’s just how I think – I know the literature talks about this as a particular, specific strategy. For me, I wouldn’t ever have it on the risk register, it would be something we discuss as a team and then adapt our plans via a change request to make it happen. What would you do? Let me know in the comments below.

3.Enhance

The Enhance strategy is similar to Exploit in that you want to make the opportunity happen, but here all you are doing is influencing the outcome – you aren’t forcing the probability to turn to 100%.

What you try to do is increase the likelihood of it happening or increase the impact it would have if it did happen. You don’t have a guarantee of the outcome but you are influencing and negotiating your way to being able to capitalise on that fab opportunity.

I think this is hard to articulate because your response plan relies so much on what the opportunity is. We identify opportunities throughout the project life cycle and don’t always record them as risks. For example, if something came up in a team meeting where we could potentially complete a task more quickly if we had an extra pair of hands, we would decide there and then to do it and hope for the return, without necessarily formally documenting the risk.

Perhaps that tells you more about my lackadaisical approach to opportunity management than it does about the Enhance strategy!

4.Share

Sharing is a little bit like transference for threat risk. It’s where you split the benefit with a third party on the proviso that they help you try to get the opportunity. For example, you might share resources for a better outcome, you might set up a joint venture or create a specific team. All of those things might mean sharing the risk and therefore the benefit between several entities or teams, but overall may make the potential benefit larger.

5.Accept

Finally, the classic strategy of do nothing. This is also a valid response and useful when there isn’t much to be had by way of opportunity. You basically sit it out and wait to see if the benefit occurs and you might want to have a contingency approach in place in case it happens and you want to act then.

However, as with accepting threat risk, make sure that you are constantly monitoring the situation and actively discussing these risks with their risk owners and the team. You don’t want to be in a situation where you miss an opportunity because the context or environment changed and your risk response plans weren’t updated as a result.

Which of these have you used? Share your best tips for managing opportunity risk in the comments below.

So far, all we’ve achieved in the risk management process is working out how to respond to risk, but it’s all been about talk and planning. Next time I’ll be looking at how to implement risk responses and make sure the work to deal with risk actually gets done.

Pin for later reading