Risk Management Planning

In the last session, I gave an overview of what risk is and why it might be important, if not mandatory, to do risk management in your project. Today I want to talk about the first level of risk planning, which is to create a risk management plan. Now these management plans that we often see in the Project Management Body of Knowledge (PMBOK) are not always adopted within organizations. Very often they have enough paperwork and overhead without having to create yet another governing document. However, the risk management plan is one document you might think strongly about creating. It’s not necessary to create one for every project. It can be drawn up at the PMO or senior management level and used or modified by each project. It will give a good general guideline for what you need to consider.

Let’s take a look at the contents of a risk management plan and see how it might be effective. According to the PMBOK¹, it may include the following:

·         Methodology

·         Roles and responsibilities

·         Budgeting

·         Timing

·         Risk categories

·         Definitions of risk probability and impact

·         Probability and impact matrix

·         Revised stakeholders’ tolerances

·         Reporting formats

·         Tracking

Ok, maybe that’s a lot of stuff. And maybe you don’t have the time or inclination to do all that planning. Here, at a minimum, are some of the categories I would think about including. (And if you have time and inclination, consider the others):

Risk categories. In the risk sessions I’ve conducted, I find that team members seem to gravitate to two things: one is all the negative things that might happen (as opposed to the positive) and two is the technical risks that may occur. As to the positive things that might happen, we’ll talk about that in a subsequent post when we discuss risk responses. As to the type of risk, categorization may help in this sense: if you use categories for risk, it will expand your thinking about the types of risks you may encounter. And you will likely be able to do some root cause analysis. You also won’t leave the planning room without thinking about each of these types of risk. PMI mentions four categories – Technical (e.g., requirements); External (e.g., subcontractors); Organizational (e.g., resources); Project Management (e.g., Planning). So your risk management plan should include those categories that are important to your organization.

Definitions of risk probability and impact. We haven’t talked about this yet, but each risk that you identify will have a probability (of occurrence) and impact (on project objectives). These values will be determined by team members and we will see how that is done later. But the important thing to know is that someone in your organization has defined what the various levels of probability and impact mean to your project. A sample of what I mean is below: (I don’t show probability to 100% because then it’s a fact, not a likelihood).

Revised stakeholders’ tolerances. Something that may not be obvious in an organization but is nevertheless prevalent is the stakeholders’ tolerance for risk. It may be, for example, that a larger more established organization may be risk averse while a start-up may be more risk leaning. Consider when IBM wanted to create a PC. Rather than do it through their older established mainframe-based company, they spun off an organization in Dallas that built the PC and took the risk. So how risk-leaning is your organization? This is the best place to record it.

PMI also mentions here the Probability/Impact matrix. This is a very useful tool but I’ll have more to say about it later.1. A Guide to the Project Management Body of Knowledge, (online edition), pages 279-282.

Comments are closed.