Risk Management Planning

I’ve offered – and provided already to many requestors – my template for a Risk Management Plan. It’s not groundbreaking or even earth-shattering, but there are just some key concepts to include and critical areas to ensure are covered. It’s not absolutely necessary to even have a formalized plan, unless you’re working on a critical government project and it’s required or you’re working with a project staff or customer that is missing the point of managing risk…then it may be necessary to formalize it for them.

I recently ran across another outline for a risk management plan and I am sharing it below. If you want my copy/template as well, just send me a note and I’ll email it to you – mine comes as a prepared document and you can just insert your info.

Risk Management Plan

Purpose

The risk management plan lays down the groundwork for how risk management will be carried out in a project. It serves as guidance for the risk process, its thresholds, and its formats, defining the roles and responsibilities of stakeholders in risk management. It is notable that the risk management plan is not a listing of specific risks and is not used to establish the particular strategies for risks, once they are identified.

Application

The risk management plan is shared with project stakeholders to clarify their roles and responsibilities in the risk management process and to identify when specific potential risks are truly of concern to the organization. It also outlines the risk budgeting process, detailing how and when risk contingency funds may be allocated and applied.

Content

The risk management plan consists of basic information about how risk management will be conducted during the project. It does not address specific behaviors associated with specific risks, but instead forms a framework for the rest of the risk management process.

1.0 Risk Process

Risk process may be as simple as two steps (e.g., assessment and response) or as complex as six or seven steps (e.g., planning, identification, qualification, quantification, response development, and response control). The process steps should include clarification on how each of the processes will be carried out and the level of depth of information to be provided for each.

2.0 Risk Responsibilities

Just as the buyer and seller in project environments have different responsibilities for deliverables, so do they have different responsibilities for risks. Those responsibilities should be outlined here. Responsibilities may include information on who will identify risks, as well as who should evaluate them and develop strategies for those that are of the greatest significance.

3.0 Risk Thresholds

Thresholds represent personal and organizational tolerance for risk. They are the definitions of tolerance in terms of budget, schedule, requirements, and other sensitive cultural issues (e.g., politics, media exposure). They are normally expressed as ceilings beyond which the project should not proceed, or as notification points for upper echelons of management.

4.0 Risk Finances

This element of the risk management plan may address both funds set aside for risks within the project (contingency reserve) and funds set aside within management control for risks outside the project’s purview (management reserve). In both cases, this component of the plan details how and when the project team may draw down funds from those reserve accounts. Risk finances may also provide detail on how the amounts for the reserve accounts will be established.

5.0 Risk Evaluation

Because evaluation protocols vary from project to project, the risk management plan should include some detail on how risks will be scored and termed. Particularly for risk qualification, there should be some definition of terms for both the probability of a risk’s occurrence and for the impact should it come to pass. Many projects employ the high–medium—low (H-M-L) scheme for both impact and probability. The risk management plan should define each of those terms.

6.0 Process Timing

High-risk projects may require frequent risk reevaluation. Projects with lower risk may not require such frequency. The risk management plan should include detail on the frequency of risk identification, assessment, and response development, as well as the appropriate application of any tracking processes or documentation.

What is Project Control?

Another useful section of Gary Heerkens’ brief case book “Project Management” covers Project Control and what it really means to the project manager. The discussion centers around the objectives of project control and what it is that the project manager is actually trying to control. I’m not wholeheartedly endorsing this information – I never am when I provide a magazine or book excerpt. However, I do find it interesting and worth further review and discussion.

What Project Control Really Means

The term control has several meanings. Those new to project management are initially dismayed by the use of the term “control,” because they mistakenly equate it with the concept of authority. In the world of project management, control has very little to do with telling people what to do, dictating their actions or thoughts, or trying to force them to behave in a certain way— all of which are common interpretations of control. In project management, the term “control” is much more analogous to steering a ship. It’s about continually making course adjustments with one main objective in mind—bringing the ship into safe harbor, as promised at the start of the voyage. And the successful project voyage includes identifying a specific destination, carefully charting a course to get there, evaluating your location throughout the voyage, and keeping a watchful eye on what lies ahead.

The Objective of Project Control

Fledgling project managers (and some experienced ones!) often make the same mistake when trying to keep control of their projects. They get wrapped up in the here and now—the measurement and evaluation of their immediate situation—to the exclusion of everything else. They calculate their current position and how far off course they are. That’s what they report to management and promise to fix. Their entire focus consists of staying on the line they’ve drawn from the beginning to end of the project. Unfortunately, controlling the destiny of your project is not that simple.

As we’ll see, evaluating where you are in terms of where you’re supposed to be is certainly part of the overall control and “getting back on track” is almost always a sound strategy. But your primary mission is to deliver what you’ve promised, so you should think of “maintaining control” in terms of minimizing the distance between where you end up and where you said you’d end up.

This means that overall project control requires an eye on the future, as this formula shows:

Calculated Present Variance + Estimated Future Variance = Final Project Variance

Maintaining proper control really requires that you consider three parameters: (a) where you are, compared with where you’re supposed to be; (b) what lies ahead that can affect you; and (c) where you’re going to end up, compared with where you said you would end up. Bear in mind that (a) and (b) are used primarily as internal control functions(although you may choose to report them outside the team). They’re used for evaluating (c). At the risk of being repetitive, your primary focus should always be on evaluating where you think you’re going to end up.

There are two reasons for this.

First, you must take intelligent and meaningful corrective action with the end point in mind. Guiding the ship must include more than just steering it back on course; it must also include recognizing that there’s an object up ahead that you’re going to have to steer around or winds around the upcoming point of land that have kicked up since you started your voyage. The future will always be different than expected at the outset of the project. Assumptions will be revised, operating conditions will change, and new things will be thrown in your path. Sometimes, actions you take now must compensate for future sources of variance as well as variances created though past performance.

The second reason you need to focus on the end point pertains to management reporting. In most cases, what will probably interest them most is a prediction of where you think you’re going to end up: this is the type of information they need to run the business. Being able to report to your management that you’re two weeks behind schedule or $10,000 over budget right now may or may not be of value to them. Reporting that you expect the project to be completed three weeks late or $15,000 over budget is much more likely to be of value.

What Are You Actually Controlling?

At this point, you’re probably saying, “OK, so I should be focused on the end point of the project and I should be trying to ‘get back on track’ and minimize variances. But the end point of what? Get back on whattrack? And whatkind of variance are we talking about?” All good questions.

The answers to these questions will take us back to the discussion in Chapter 2 about the dimensions of project success. The most fundamental measure of project success relates to meeting the agreed-upon targets in each of these dimensions. These are the targets that you promised to meet at the beginning of the project; these are the targets that you should focus on controlling.

Two of the targets pertain to the consumption of resources:

• Schedule: Was the project completed on time? (How long did we take?)
• Cost: Did the project come in at cost? (How much did we spend?)

The other two targets are tied to the deliverables of the project:

• Functionality: Do project deliverables have the expected capability? (What can they do?)
• Quality: Do the deliverables perform as well as promised? (How well can they do it?)

As far as many organizational managers are concerned, the ideal end point occurs when a project meets these four targets exactly as promised. Although “beating targets” is often characterized as desirable, hitting targets provides a level of predictability that most organizational managers value. The first two targets (schedule and cost) often get the most attention; hence the very common phrase “controlling cost and schedule.”

Sometimes, however, controlling cost and schedule gets too much attention and deliverable performance is not as closely monitored as it should be. This is a major oversight, one that you should concentrate on avoiding.