The Money Files

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

When you have to pay for internal or external resources, the costs can soon mount up. It’s not difficult to find yourself with spiralling resource costs, even if they are just wooden dollars being moved between departments.

The most likely causes are poor estimating and too many change requests.

It’s often hard to drill down into the detail of where a resource is spending time, especially if you don’t have a timesheet application. If you don’t record time, then start doing that first! It will really help you improve your estimates over the longer term.

Short term, you need to sit down with your team and reforecast the whole project. If you then can’t afford to do all the work that you’ve planned out, you need a frank conversation with your project sponsor about what can be taken out of scope for this phase.

This video explains more.

Pin for later reading

The first process detailed by the Earned Value standard is ‘Organise Project’. Basically, you can’t run earned value management on your project if your project is a disorganised mess. But it also means more than that: you have to have an understanding of scope so you can split the project into work packages that make sense and can be tracked.

How do you work out the scope?

The easiest way to work out the scope of the project is from the charter: this outlines what you were tasked with doing. The requirements documentation will also have useful information.

However, that’s all likely to be quite high level. To get to work package level, you have to use decomposition. All this means is breaking down big chunks of work into smaller sections until you get to a level where it’s possible for someone to take responsibility for managing the thing.

This is how you create the work breakdown structure: take the high level requirements and decompose them, structure them, into something that gives you a logical overview of what is happening on the project.

You might think it’s not worth starting at the top and breaking it down. Why not start at the bottom and build it up? I suppose either works fine. For me the default would be to start with the big picture because then we make sure that what we build meets that need. There’s a chance that if you start at the bottom and build up, what you actually end up with isn’t quite what was asked for. However, do what works for you: as long as you end up with decomposed work packages (as in, broken down, not mouldy), then you’re good.

The WBS is linear, in that the branches don’t twine together. Once you’re on a branch, you stay on that branch, and all you are doing is breaking the work down further and further. How do you know when to stop? I say that’s a judgement call. The work package size needs to be controlled enough for someone to feel like they can get their arms around it and lead it, but not so detailed that you are creating a ton of WBS paperwork for something that ends up taking a couple of hours.

How to represent your WBS: diagram or list?

When you see WBS info in textbooks, and indeed, in the EV standard, you’ll see it as a picture; a kind of tree diagram or hierarchy chart. Personally, I don’t think in pictures so I prefer to create a numbered list. I love the fact that my scheduling tool of choice will add in the WBS numbering automatically as I create the list. Creating your WBS directly into your scheduling tool is not (in my view) a great practice, but it works for the kind of projects I do as they are generally pretty small at the moment.

Your project is organised

The end result of the first EV process is that you end up with a WBS and some other scope documentation that fleshes out what you have agreed to do, like the scope statement and a plan for managing scope should things change. If you’re going down the route of preparing a ‘proper’ WBS instead of a simple numbered list of tasks – which is necessary if you are handing work packages over to teams to run with – then you’ll also have a WBS dictionary which is the text part that adds detail and colour to the titles on the WBS diagram.

All this forms your scope baseline: the official statement of what it is you intend to deliver. The important thing to remember is that you do not create this alone – just don’t! Scope needs to be created with input from technical experts because you don’t know what you don’t know. Even if you think you are an expert in the subject – or you were at some point in your career – the people doing the work need a say in what they are doing so they can start thinking about how best to do it. Collaboration is your friend: yes, it takes longer but the end result is a project that everyone can buy into, and that will save you a lot more time in the long run.

Setting up your project for success with a solid scope is important all the time, but if you are going to follow the EV standard, it’s essential. You can’t measure project performance unless you know what you should be performing!

Pin for later reading

Let’s look at what tasks happen when during the project life cycle. Different budget requirements fall into different parts of the project, from start up through to delivery and closure, with different tasks required every month and then different tasks again every couple of months.

The infographic below explains what to be focused on at different points in the project life cycle. What would you add? Let me know in the comments!

A threat is a risk with a negative impact on the project – so this article isn’t about dealing with bullying behaviour at work or anything like that. We often talk about risk as if all risks are the same, but they aren’t. There are ‘negative’ risks i.e. threats and ‘positive’ risks i.e. opportunities. The way we respond to each is different because you want a different outcome each time. With threats, you want the risk to go away. With opportunities, you want the risk to happen so you get the benefit.

In this article I’m talking about your options for responding to risks that are perceived to be a threat to the project.

There are 5 responses:

1. Escalate
2. Avoid
3. Transfer
4. Mitigate
5. Accept.

Let’s look at each of those in turn.

1.Escalate

Escalating means passing the risk up to someone else to deal with, because the team and/or the project sponsor believe it’s something that is outside of the scope of the project. Often projects will uncover risk or issues that are actually nothing to do with the scope of their work. In my experience, sometimes that means my project gets extended to also deal with whatever problem we’ve found, but sometimes the right thing to do is escalate to the PMO and let someone else deal with it.

This is also an appropriate strategy if the risk response you’re considering would need more than the level of authority you have within the team.

Basically, you’re passing the risk up to the programme or portfolio management team and while you’ll input to the response, it’s no longer your risk to track and manage.

I don’t remember this being an option when I first learned project management on an internal course my employer ran. I think it’s definitely a valid option and one we’ve used on my projects.

2.Avoid

You can avoid a risk if you change your plans so it couldn’t possibly happen. For example: there’s a risk of getting wet if you go out because it’s raining. You remove the risk and don’t get wet because you don’t go out that day.

Sometimes you can make this happen with project risk but often avoiding a risk is expensive and time-consuming so it might not be worth it.

However, some risks can be avoided simply by gathering more information like getting clearer requirements, hiring someone with particular skills who would know what to do or being better at stakeholder engagement.

3.Transfer

Transferring risk means passing it over to another party to manage and the example typically given is insurance. You can transfer the risk (in exchange for a fee) over to an insurance company who then take the risk on your behalf.

A similar thing happens when you write warranties and guarantees into contracts – the other party carries the risk in exchange for some kind of consideration on your part.

4.Mitigate

This is what we normally think of when it comes to risk management, and often internally – at least in my teams – we talk about risk mitigation instead of risk management because it’s what we do most often.

Mitigation is about reducing the impact and likelihood or a risk so that if it does happen it’s easier to manage the situation. We take steps to make the risk less likely to happen and less of a problem if it does.

For example, we might do more testing, add more resources to a project task, review more thoroughly, subject a process to internal audit or peer review and so on. We create back up plans, policies and build redundancy into the system so if something does go wrong, it’s easier to cope and get the project back on track without a major interruption.

5.Accept

Finally, you can choose to do nothing. This is an appropriate response to small, low level risks. It’s also a temporary response to risks that are likely to happen far into the future where it’s not necessary to spend time preparing a response yet.

You can put aside time or money to prepare for dealing with the risk as a minimum if you can’t do anything else. However, it’s important to monitor the risks where you have chosen acceptance as a strategy, because something might change in the future that makes it a less attractive option. Keep these risks under review and adapt your strategy as necessary to ensure you’re still doing the right thing for the project.

All risk responses could be combined if it’s appropriate to take two or three actions. You can even have different people responsible for taking different actions, although I’d stick with having one risk owner so that someone has a complete picture of what is going on.

Prioritise managing the most risky risks first and then invest the appropriate amount of time, resource and budget into reviewing and acting on the others.

Next month I’ll be looking at 5 strategies for dealing with opportunities – those positive risks we want to encourage.

Pin for later reading