Negative Risk Response

Quick reference

• 00:04 Hi, I'm Ray Sheen.
• 00:05 Let's talk about how to respond to threats, negative risks on your project.
• 00:10 >> The Project Management Body of Knowledge, the PMBOK Guide,
• 00:13 defines a threat risk as a risk that would have a negative effect on one or
• 00:17 more project objectives.
• 00:19 There are five different approaches you could take, escalate, avoid, mitigate,
• 00:23 transfer, and accept.
• 00:26 Which approach you take will depend upon a number of different factors associated
• 00:30 with your project or the business.
• 00:32 For instance, the type of project, project phase, resources, time and
• 00:37 money that are available, even the rationale and
• 00:40 management commitment to the project can impact which risk response you choose.
• 00:45 Let's look at each of the responses in just a little more detail.
• 00:49 One response strategy is escalate.
• 00:52 Now I'm not suggesting that this should be your first response, actually this is
• 00:57 usually the last response if none of the others will control the risk.
• 01:01 This strategy leads to a rebaseline of the project,
• 01:04 often to go down a different path which avoids or neutralizes the risk.
• 01:09 The magnitude of this risk is one that is beyond the ability of the project team to
• 01:13 address, so they bring it to the stakeholders with the request to change
• 01:17 the project goal or boundaries.
• 01:19 This risk is bigger than the team's ability to take
• 01:22 an appropriate action on it.
• 01:24 One thing the stakeholders must choose to do is to add or subtract scope.
• 01:29 Another thing is to change the project's schedule boundary,
• 01:31 like moving the project to a different fiscal year.
• 01:35 Or the stakeholders could change the project total budget, adding money or
• 01:38 moving spending between one location and another.
• 01:41 Keep in mind the stakeholders may also say that they need to find a different team.
• 01:46 The remaining four strategies are all strategies that the teams can apply
• 01:49 without asking permission from the stakeholders,
• 01:52 because the rest of the techniques do not change the overall project boundaries.
• 01:57 Let's look at the strategy avoid, this strategy removes the risk so
• 02:02 that it cannot happen.
• 02:04 This is a preventive action strategy,
• 02:06 the project plan is changed in such a way that the risk cannot occur.
• 02:11 One way to do this is to change tasks within the scope so
• 02:14 as to eliminate the tasks with the risk in it, or
• 02:17 change how that task is accomplished and controlled.
• 02:20 Another way to do this is to change the schedule so
• 02:23 that tasks happen at different times when they're not susceptible to the risk.
• 02:28 Or we can change resources by using a resource pool with different skills or
• 02:32 changing roles and responsibilities among team members.
• 02:36 A risk may be avoided.
• 02:38 One caution when using this approach, the change may eliminate one risk, but
• 02:43 there is normally new risk associated with the changed approach.
• 02:47 Be sure to add this new risk to your analysis.
• 02:50 One other point, some risks just can't be avoided so this is not always an option.
• 02:55 The next risk response strategy is mitigate.
• 02:58 Instead of a preventive action approach, we're taking an early corrective action.
• 03:02 Again, we change the project plan, but instead of avoiding the threat,
• 03:07 we prepare for it.
• 03:08 We make allowances for it within the project plan, it could still happen, but
• 03:12 it won't hurt as much.
• 03:14 We often do this by, again, changing the tasks that make up our scope or our
• 03:18 deliverables, in particular the definition of done to a different standard.
• 03:23 I often mitigate risk by changing the cost or schedule estimates.
• 03:27 I build into my estimate a risk response so I'm ready for
• 03:30 the problem when it occurs.
• 03:32 This can insulate the rest of the project from the problem,
• 03:35 isolating the impact to just that one task.
• 03:39 Another way to mitigate a risk is to create an early warning signal.
• 03:43 The sooner you know that a risk will occur, the sooner you can take action.
• 03:47 And generally, taking action early in a project will be less expensive and
• 03:51 disruptive than waiting until late in the project.
• 03:55 Finally, you can pre-position risk response capacity at a point where
• 03:59 the risk could impact the project.
• 04:02 I often do this by adding a risk mitigation task.
• 04:05 An example of this is adding a task for
• 04:08 software bug fixing in a software development project.
• 04:11 This prepositions time and
• 04:13 resources to address the unknown aspect of software bugs.
• 04:20 The next response strategy is a transfer of the risk.
• 04:23 Transferring a risk is to use some organization that is not part of
• 04:27 your organization to assume some aspect of the risk.
• 04:31 It requires a contract with that other organization, clarifying the liability and
• 04:35 exposure.
• 04:37 Some risks can be insured,
• 04:39 typically these will be things like natural disasters or damage of some type.
• 04:44 Insurance does not prevent the risk, but
• 04:46 it provides resources we can use to recover from the risk.
• 04:51 We can also transfer the risk through contract terms with a supplier,
• 04:54 such as bonds and guarantees, or using service level agreements with suppliers.
• 05:00 Even the contract type can transfer risk.
• 05:02 A fixed price contract transfers the risk of an over run to the supplier.
• 05:08 You can also transfer schedule and quality risks through penalty and
• 05:11 incentive clauses.
• 05:13 The last strategy is to use the accept approach.
• 05:17 If you haven't done one of the other four, escalate, avoid, mitigate, or transfer,
• 05:22 you are doing acceptance.
• 05:24 With this strategy, there is no immediate action on the project.
• 05:28 The project plan remains unchanged, either the threat is so small or it's so
• 05:32 uncertain you accept it for now.
• 05:35 Even though I accept the risk, I may still create a trigger.
• 05:39 That is some type of warning that this risk has grown in magnitude or
• 05:43 it has gone from being very unlikely to becoming likely.
• 05:47 If that happens, the accept strategy is changed to one of the other strategies.
• 05:53 If you have many risks that are in the accept category,
• 05:55 you should set aside a reserve to handle that.
• 05:59 This is a small amount of resources or
• 06:01 time that can be applied to these irritating small risks.
• 06:05 One final point about the accept strategy,
• 06:08 by definition accept is not a good strategy for a red risk.
• 06:13 That risk is likely to happen and it's a big deal,
• 06:16 you can't just close your eyes and accept it.
• 06:19 >> When you have a threat risk on your project you need to plan an appropriate
• 06:22 response.
• 06:23 Now whether it's escalate, avoid, mitigate, transfer, or accept,
• 06:28 select a response strategy and then implement it.

Lesson notes are only available for subscribers.