Risk Register

Quick reference

• 00:05 Hi, I'm Ray Sheen.
• 00:06 I'd like to talk to you now about a great tool to help with project risk management,
• 00:11 that's the Risk Register.
• 00:12 The project management body of knowledge, the PMBOK Guide, defines a risk register
• 00:18 as a repository, in which outputs of risk management processes are recorded.
• 00:23 The Risk Register is used to organize the steps for project management.
• 00:28 It is often in the form of a spreadsheet or database.
• 00:31 If using a spreadsheet,
• 00:32 each column represents a step in the project risk management process.
• 00:36 Every organization has a slightly different risk management methodology.
• 00:40 So use columns that align with your approach.
• 00:43 Typically, there will be several columns associated with describing the risk,
• 00:46 several columns associated with analyzing each risk, and several columns associated
• 00:51 with responding to the risk, with a risk response implementation plan and status.
• 00:56 Since the Risk Register guides us through the project risk management process,
• 01:00 let's review the steps of that process.
• 01:02 First, you must identify the risk factors on the project, risks to scope, schedule,
• 01:07 and resources.
• 01:08 Both positive risk opportunities and negative risk threats.
• 01:12 The second step is to analyze and
• 01:13 prioritize those factors, these must be done for a specific project at hand.
• 01:19 A risk maybe of high importance on one project, and
• 01:21 the exact same risk turn out to be irrelevant on another project.
• 01:25 We discuss how to do this on another lesson.
• 01:28 If the risk is significant, the next step is to create risk response plans.
• 01:32 Again, other lessons will discuss different strategies for
• 01:35 risk response to both positive and negative risk.
• 01:39 Finally, the project team must actually implement those risk response plans in
• 01:43 order to avoid the negative risk, and to take advantage of the positive risk.
• 01:47 I've been in project reviews on several occasions, where the project leader has
• 01:51 described a project risk that was now creating a problem on the project, and
• 01:55 in the course of the discussion,
• 01:56 they state that, well, we knew this was going to happen.
• 02:00 I'll admit that makes me angry.
• 02:02 They identify this risk, they analyze it to the point that they thought it was
• 02:06 going to happen, but they did nothing about it, and
• 02:10 now they act like they're a victim of something outside their control.
• 02:14 They're not a victim, they're incompetent project leader,
• 02:17 it is their job to manage risk, and that includes doing something about it.
• 02:22 So what does a typical Risk Register look like?
• 02:25 This is an example I pulled from my files.
• 02:28 The first three columns are all associated with risk identification.
• 02:31 A risk number, and a risk description.
• 02:34 Also, I like this approach of identifying what part of the project is impacted
• 02:38 by the risk.
• 02:39 Notice, risks two, three, and four,
• 02:41 are the same risk that is occurring at three different times in the project.
• 02:45 They also have three different risk responses.
• 02:48 The next three columns are an analysis of the risk in this project.
• 02:51 First, there is the impact, and then an assessment of that priority and
• 02:54 urgency of the impact.
• 02:56 A common technique for prioritizing is to use the red, yellow, green stoplight.
• 03:01 I'm finding more and more risk registers are now including the urgency column.
• 03:05 This is especially useful for iterative and incremental project life cycles.
• 03:09 Some risk cannot be adequately addressed, until a later time or
• 03:13 phase in the project.
• 03:15 The final three columns are associated with the risk response and implementation.
• 03:19 We have the response plan and if needed, a trigger for when to implement it.
• 03:23 Finally, the current status of the implementation or the trigger.
• 03:27 Another use of the risk register is as a project documentation tool.
• 03:31 Once a risk is resolved, I remove it from the list, by cutting that line and
• 03:35 paste to get unto another worksheet in my spreadsheet,
• 03:37 that has titled resolved risks.
• 03:40 By the end of the project, all the risks are resolved, and
• 03:43 I have a record about what risks we faced, and what we did about them.
• 03:47 This is then reviewed in the Project Post Mortem or Lessons Learned Session.
• 03:51 The Risk Register is a living document during the project.
• 03:54 I recommend reviewing it regularly at project meetings for
• 03:57 updates on the implementation plan status, and to add any newly identified risks.
• 04:03 In fact, when I'm managing a small project that only has a few people, and
• 04:06 it's focused on just one or two major deliverables, I only use two or
• 04:09 three project management tools.
• 04:11 A project schedule, a WBS dictionary or task list, and a risk register.
• 04:16 That's all that you need.
• 04:20 Whether on a small project to a large project, a predicted project or
• 04:23 an adaptive project, a Risk Register
• 04:26 is an essential part of day to day project management and communication.

Lesson notes are only available for subscribers.