Risk Management Plan

The risk management plan typically includes the following ten components:

1. Methodology

2. Roles and responsibilities

3. Budgeting

4. Timing

5. Risk categories

6. Definitions of risk probability and impact

7. Probability and impact matrix

8. Revised stakeholders' tolerances for risk

9. Reporting formats

10. Tracking information

1. Methodology

Methodology describes:

• The tools, methods, and sources of information that will be used to perform risk management, including how risks will be identified, analyzed, and categorized;
• How risk response plans will be prepared, implemented, and monitored; and
• How risk triggers will be monitored.

2. Roles and Responsibilities

The roles and responsibilities section defines who does what during all risk management activities. In particular, it specifies who will direct and manage risk management activities, this person may be the project manager or a designated risk manager for the project.

3. Budgeting

The budget establishes the anticipated cost of the risk management activities and the associated risk response plans, including contingency reserves.

4. Timing

The timing describes how often risk management activities will be performed, and when they will take place within the project schedule.

5. Risk Categories

Risk management deals with eventualities that might affect the project but are not documented in the project management plan. This means thinking not only of problems that have occurred with this kind of work, organization, or project approach, but also imagining problems that have never occurred before, but may occur during the project.

The basic purpose of the Risk Identification process (presented in a subsequent section of the course) is to ensure that as many of these eventualities as possible are considered. To do this, it is helpful to have a list of risk categories that the project team will address, so that the process is as comprehensive as possible. The risk categories generated during the Risk Management Planning process will be an input to the Risk Identification process.

There is no single, standard list, but there are good starting points from which the team can build. Agreeing on the categories and making the list complete and practical is one of the first steps in identifying the risks themselves. Considering each risk category should help the team generate ideas on risk events specific to those categories.

Most risks fall into one of several broad categories; however, any project may run unique risks.

Risk categories are tools that:

• Enable the project team to more efficiently analyze and respond to risks with common characteristics; and
• Ensure that no potential sources of risk will be overlooked during the subsequent Risk Identification process.

Risk categories can be structured to provide different levels of groups for different risk management purposes or to provide greater scope or more focus as needed during risk analysis and response planning.

Typical Risk Categories

The Project Management Institute (PMI) guide Approach

The PMI approach breaks risks into technical, project management, organizational, and external risks.

• Technical risks are introduced by the difficulty of the work itself, new or changed technology, unrealistic performance goals, or changes to standards;
• Project management risks arise from poor use of resources, poor quality of the project plan, or poor project management discipline;
• Organizational risks are associated with cost, time, and scope objectives. They materialize when project objectives are incompatible; projects are not prioritized effectively within the organization; funding is not reliably provided; or there is competition for project resources from other projects; and
• External risks come from a changing regulatory environment, labor issues, changing priorities of the organization's owner, political or cultural factors in a country foreign to the organization, resource and product price fluctuations due to changing economic circumstances, and weather. They also come from issues that arise from dealing with the public.

6. Definitions of Risk Probability and Impact

The methods for scoring and interpreting the Quantitative and Qualitative Risk Analysis processes must be set in advance to avoid injecting personal biases or inappropriate influence into the attention paid to particular risks. Developing a common standard for defining different levels of a risk's probability and its impact ensures that risks will be analyzed and responded to objectively.

Probability and impact are independent variables.

Risk probability is the likelihood that a risk will occur, on a scale between 0% and 100%, where 0% means it is impossible, and 100% means it is certain.

Risk impact is the effect on project objectives if the risk event occurs.

Risk probability and risk impact are investigated separately; however, a common pitfall is for these terms to be confused, for example, assigning a high probability to a risk because the potential impact is severe. For example, imagine the risk of being struck by lightning - the impact is very high, but the probability is considered very low.

During risk analysis, these two dimensions of risk are applied to specific risks. This helps determine which risk events should be managed most aggressively, and the level of effort and investment that is justified.

 7. Probability and Impact Matrix

Each risk's probability rating (P) is multiplied by its impact rating (I) to generate a "risk score" (RS). Since the number of probability rating values and impact rating values is limited (normally, five of each), all possible combinations can easily be established and entered into a table or matrix. (Tables and matrixes are presented in a subsequent unit, Qualitative Risk Analysis.)

Organizations often find it useful to stratify the resulting RS values into three levels, one representing "low" risks, one representing "moderate" risks, and one representing "high" risks. To signify this, the associated matrix entries can be colored to identify which level they belong to. For example, the low risks may be colored green, the medium risks yellow, and the high risks red.

Using this technique simplifies applying different policies (and hence effort and resources) according to the level of the risk's RS. For example, risks rated as "red" may require review at every weekly status meeting, while "green" risks may be reviewed only monthly, or on a less frequent, rotating basis.

8. Revised Stakeholder Tolerances for Risk

Risk thresholds define the criteria that a risk must satisfy in order to be acted on.

Example: One threshold may require that if a risk delays the project's schedule objective by more than 30% and the project team would require another 20% of project budget to mitigate the schedule impact to below that level, a reevaluation of the project's cost-benefit ratio is triggered automatically.

Selecting which level of risk factors is "high" risk is a matter of stakeholder tolerance. In some cases, stakeholders may temporarily adjust their attitudes toward risk for a specific project, particularly if one or more project objectives represent significant strategic value to the organization.

Sometimes an organization faces significant external threats, such as the pressure of competitive innovation or significant restructuring in the industry. Stakeholders may also be willing to revise their tolerance for risk when a windfall opportunity presents itself. By temporarily suspending normal risk thresholds, the organization will have the agility to respond. Such variances from the normal thresholds should be clearly decided and communicated.

9. Reporting Formats

Reporting formats present:

• How the risk response plan will be organized;
• How the risk management activities will be documented, analyzed, and communicated to project stakeholders; and
• The contents and format of the risk register (described later).

 10. Tracking Information

The tenth and final component of the risk management plan is tracking information. Tracking information defines how risk management activities will be documented and audited for the following uses:

• Evaluation of the current project's performance; and
• Historical information for the benefit of later projects.

G. Probability and Impact Matrix

Has a matrix been constructed reflecting all possible combinations of risk impact

            and probability levels?

• Have the entries in the probability and impact matrix been stratified into a small

            number of overall risk levels?

H. Revised Stakeholder Tolerances

Have the normal risk tolerances of all stakeholders been reviewed and determined?

• Have any of the stakeholders' risk tolerances been temporarily relaxed or tightened

            for this particular project?

I. Reporting Formats

Has a standard entry form for the various sections of the risk register been

            developed, including the probabilistic project analysis and the revised project

            objectives, as well as the risk response plans?

• Have report layouts been defined for the periodic reporting of risks to the

            stakeholders?

• Has a form been designed for stakeholders to report the results of implementing

            their risk response plans?

• Has a form been designed for identifying new risks?

J. Tracking

•   Has a repository been set up to collect risk management work products?
•   Are the minutes of risk review meetings being collected and stored in the

                 repository?

•   Are the start and stop dates of risk management activities being reported?
•   Are all the significant data concerning risk management (reports, notifications,

                 memos) that are reported to stakeholders being recorded in the repository?

•   How are the audits of the risk management activities going to be carried out?

Risk Management throughout a Project's Life Cycle

Risk processes should be performed throughout the project life cycle, and can be performed at any time during the project life cycle. Determining when during the project life cycle to analyze potential risks should be one of the first actions in the process of planning risk management planning.

When a project consists of several phases, each phase may have its own unique risk characteristics; a specific risk assessment may therefore be performed at the beginning and at key points of each phase to identify risks and to characterize their severity.

Typically, the first risk analysis is performed early in the project, or during the concept exploration or project definition phases. It is during these phases that risk identification and management will have the most significant benefit in successful project completion.

The project manager should consider conducting a risk analysis for the following reasons:

• A major risk that has been previously identified has been realized, and new information is available;
• The potential of a high-risk item has been changed; and
• The potential for new risks has increased.

The Iterative Nature of the Project Risk Management Processes

The Project Risk Management processes are iterative. The very acts of managing the project and managing existing risks lead to the discovery of new risks. The progress of the project will unearth new unknowns and assumptions. A project manager may learn very late in a project about problems that could not have been anticipated; e.g., regulatory changes, changes in personnel, or changes in relationships with suppliers or contractors.

Over time, the analysis of risk should show the probability and impact of risks decreasing in response to effective management. However, residual risks may remain even after such actions are taken. The probability of a risk may be significantly decreased, but it will never be eliminated.

Project managers should think of risk management as an integrated discipline that is practiced continually through the life of a project. This means that an action, or failure to take an action, in one area will usually affect other areas.

Risk management often requires tradeoffs among project objectives. Performance in one area will often be enhanced or safeguarded only by sacrificing performance in another.

Managing Risk by Project Phase

Different phases involve different types and sizes of risk. Two main principles cause this variation in project risk.

1. The kind of work performed in each phase is different, and each kind of work introduces its own risks.

Example: In the design phase, the faulty application of a design technique or tool can result in significant difficulties. This problem cannot occur during testing or implementation because the tool or technique is not in use in those phases.

2. The earlier in the project life cycle the risk is encountered, the greater the impact on the rest of the project.

Because most problems spread through the remaining project management activities and deliverables, more of the value of the project is affected by a problem in an early phase than by a problem in a later phase.

Example: An omission in a specification that occurs in the design phase and remains undetected until testing or even implementation will usually require reworking the design and every downstream deliverable that is affected.

Fundamental Concepts of Risk Management

Despite differences across industries, the following seven fundamental components of risk management are widely recognized. They can be considered imperatives - actions or attitudes that are required for effective risk management.

Determine Proportionate Expenditure.

The first fundamental principle of risk management is proportionate expenditure. The time and money spent in analyzing risk and determining strategies for risk management and mitigation should be considered from the perspective of cost-to-benefit analysis. It should not cost more to manage or mitigate the risk than to realize the risk.

In other words, if there is a risk of suffering a $1,000 loss on your project, an effective project manager would look for a preventive solution that costs, for example, no more than $100 in time or additional resources. If the risk cannot be prevented, a secondary strategy would be to find a way to limit the value of the loss to much less than $1,000. The goal is "spend a little to save a lot."

Determine Proportionate Expenditure to the Realized Risk.

Realized Risk

Realized risk is defined as the impact to the project should the risk actually occur.

This can be understood in terms of financial loss, delay in schedule, or inability to achieve stated requirements. Ultimately, each of these can be reduced to the time and cost that will be required to repair or recover from the risk event.

To illustrate, one might wish to estimate the value of realized risk from a public disaster such as a hurricane. We do not simply declare a "loss" of millions of dollars. Instead, we define the costs involved to return to normal (rebuilding roads, houses, and public infrastructure). Likewise, when a project suffers a loss, some course of corrective action is taken to recover. The cost of that action (in terms of time, resources, and budget) is the true realized risk.

In some project domains, the idea of realized risk is replaced by the value of the risk multiplied by the probability that it will occur. Statistically, a risk with an impact of $50,000 but with only a 10% likelihood of occurring is worth, or has an expected monetary value, of $5,000. Using the above illustration, you should not spend more than $5,000 to eliminate such a risk.

In a given project you will have dozens of risks, and only a portion of them will actually occur. You could not reasonably spend up to the full value of each risk in order to defend your project. Additional discussion of the statistical basis of risk will be seen in the material on Monte Carlo analysis presented later in the course.

Be Pragmatic.

The second fundamental principle of risk management is to use a pragmatic approach. Some risks simply cannot be controlled. For example, if a key resource pool belongs to a union that is sympathetic to a strike that may take place at an unrelated facility, management may choose to simply ignore the risk because there are no alternative strategies and the strike is beyond its control.

Similarly, the possibility of an earthquake is very real in some parts of the world, and the consequences potentially severe. However, it may not be practical to plan mitigating this risk into the project itself if the likelihood that an earthquake will occur during the project is extremely low.

It may be more cost effective to concentrate management attention on the mitigation of some moderate risks that can be controlled, rather than on some high risks with results largely determined by outside influences.

It may not be possible to manage or mitigate every risk; therefore, some risks must simply be accepted. Also, a risk with major consequences but an extremely low potential of occurring may not need to be considered a risk with any real potential for the project.

Communicate Effectively.

In order to maximize the probability that information about risks will reach the project team, every effort should be made to encourage and validate ideas from every possible source, no matter what the contributor's background or function.

The project management team should also encourage the free flow of information among all participants in the project. This will ensure that as many available sources of information about risks as possible will be found and tapped, and that potentially sensitive information will reach the necessary parties.

Because individuals have specific communications preferences, and because the project team cannot predetermine who will possess important risk information, the team should encourage the use of a wide variety of communication vehicles. This will increase the probability that information about a risk will be communicated effectively to the necessary parties on the project team.

Apply Processes Continuously.

The project team members and stakeholders must be constantly aware of the emergence of new risks. They must also continue to carefully monitor information sources that may provide warnings about impending risks.

The project management team must remain continuously engaged in managing risks through all phases of the project's life cycle.

Integrate Risk Management with Project Management.

The jobs of the project manager and risk manager include making risk management activities an integral part of the other project management activities. This includes considering risk whenever a project status meeting is held, a new resource is introduced to the project, or an unexpected event occurs.

In order to make Project Risk Management a more intrinsic part of project management activities, the project management team should ensure that all aspects of the project's infrastructure (such as its communication vehicles, repository, and work management processes) include a risk management component.

Additionally, the project management team should encourage risk awareness within the project team's culture. For example, the team members should be tolerant of negative reactions to new circumstances, and should explore them openly for any possible validity. They should also routinely challenge optimistic assertions and forecasts, discuss how adverse events might affect the project, and talk about how to prepare for such events in advance.

 Create a Shared Vision.

To increase each team member's effectiveness and enthusiasm for identifying and managing new risks successfully, the team should share a common understanding of the final product or service of the project. They should also, to the extent possible, be involved in defining the product and its functions, not merely depending on the sponsors for direction.

These two practices will make the team more alert to new threats to the project, and more tenacious about facing and averting them.

Build Teamwork.

The final fundamental concept of risk management involves teamwork. It is the project manager's responsibility to ensure that Project Risk Management is carried out, but the best results are achieved when all the stakeholders who might have information about project risks and impacts, or how best to mitigate them, are involved.

Reasons for Building Teamwork

The project manager will achieve the best results in risk management by engaging members of the project team in risk management activities.

This is primarily because:

• Project team members have the greatest familiarity with the kinds of technical risks that are likely to occur;
• Project stakeholders are in the best position to identify and assess external factors that may cause risks for the project; and
• Creative and analytical thinking is enhanced when the team is working well together.

Benefits of the Risk Management Planning Process

The Risk Management Planning process defines how risk management will be carried out, both as guidance for the team and as a commitment to the project sponsor.

The benefits of the Risk Management Planning process are the following:

• It ensures that threats do not cause the project to miss its objectives; and
• Opportunities are effectively converted into advantages for the project, all with a minimum investment of time and money.

For these benefits to be realized, the project management team must thoroughly and diligently design, then carry out Risk Management Planning and other processes in the Project Risk Management Knowledge Area.

 Tailoring the Risk Management Planning Process

The Project Risk Management Knowledge Area processes, like all other Project Management processes, must be tailored to match the level of effort in managing risk to the project's overall value to the organization.

Example: A business-critical project would require more effort and more sophisticated Project Risk Management processes than a project to perform a routine upgrade to an infrastructure service.

This tailoring can take the form of:

• A larger budget for risk management activities;
• More time allowed to perform the risk management activities;
• Higher levels of involvement by senior stakeholders; and
• Larger contingency reserves of cost and time to absorb risk impacts that cannot be efficiently eliminated.

The stakeholders' tolerance for risk is another important factor affecting the Risk Management Planning process. Their risk tolerance will affect how much they are willing to invest in Project Risk Management activities and contingency plans, and how much they set aside for contingency reserves of time and cost.

Organization Risk Tolerance

The second enterprise environmental factor involved in risk tolerance is the organization's risk tolerance. With most opportunity comes risk. Organizations are in business today because they were willing to take risks. The key is to find a balance between the opportunities they want to pursue and the risks they are willing to take.

Several risk experts have suggested that organizations and individuals strive to strike a balance between risks and opportunities in all aspects of projects and their personal lives. The idea of striving to balance risks and opportunities suggests that tolerance for risk is variable.

The organization's risk tolerance can be affected by:

• The current economic environment;
• The willingness of senior management to take risks; and
• Whether the project is high-value and complex or low-value and relatively simple.

It is important for the project manager and project team to know the risk tolerance of a company early in the risk-planning phase. A template from previous project efforts can be used; this helps define and explain the organization's methodology regarding risk tolerance.

Organizational risk management policies

The organizational risk management policies dictate:

• How risk management is to be performed;
• Who is to participate; and
• What deliverables are required.

Formally established, written rules assign accountability for risk management and ensure that new initiatives are analyzed for risk. The rules should also define:

• A standard risk process;
• Risk management tools; and
• The frequency and level of reporting.

Organizations may have policies or legal regulations for specific types of risks; for example, the handling and disposal of hazardous materials.

Templates

An organization may have a template for Risk Management Planning, especially in organizations with standards for quality systems, such as the ISO 9000 series. Applying the template ensures consistency, allowing individuals from different projects to easily comprehend the risk plans on any project undertaken by the organization.

The risk management plan template will normally include or refer to:

• Specialized tools such as a standard base set of risk categories;
• Risk screening checklists; and
• A standard probability and impact matrix or separate probability and impact scales.

Definitions of roles & responsibilities

The definitions of functional and matrix roles and responsibilities explain:

• Who must participate;
• Who is responsible for reviewing and approving risk management deliverables; and
• Who must be involved in risk mitigation strategies, including monitoring risk triggers and responding to risk events.

Depending on the organizational structure, certain types of risks may fall under the responsibility of specific parties in an organization.

The primary technique for the Risk Management Planning process is a combination of planning meetings and analysis. These are conducted the same way as other planning meetings, using these tools and techniques:

• An agenda;
• Objectives to create specific deliverables;
• Data-gathering to ensure that all meaningful input is obtained; and
• Objectivity in evaluating and making decisions

Planning Meeting Participants

The Risk Management Planning meeting involves key members of the project team, including:

• The project manager;
• Project team leaders;
• Key internal stakeholders;
• Risk officers, consultants, auditors, or others responsible for directing, conducting, or overseeing risk activities within the organization; and
• External stakeholders as required and allowed.

Purpose of the Planning Meeting

One significant purpose of implementing and following well-defined project management processes is to minimize the chance of oversights and errors. The project management team should review the processes for the current project to understand how these processes already minimize project risks. If a particular project management process does not minimize risks effectively, the team should determine whether applying the process more rigorously would help.

In particular, the planning meeting should establish a common understanding of the extent of control and the types of controls that will be in place for project monitoring and control. This helps team members understand the generic risk controls for low and medium risks, which are typically sufficiently covered by the prudent use of standard project management controls.

Planning Meeting Results

Planning meetings also define:

• Who will lead, support, and identify team members for each type of risk action;
• What approaches, tools, and data sources will be used for risk management;
• What scoring and interpretation methods will be used to categorize and analyze risks;
• Which team members will be assigned to each identified risk;
• What the criteria will be for the threshold of each level of risk impact;
• How much additional cost for risk mitigation will be acceptable to the project stakeholders;
• How often each risk management process will be performed;
• How reports will be generated and what standard content will be included, analyzed, and communicated; and
• How all the risk activities will be recorded and/or tracked.

The first planning meeting should define:

• How the planning meetings will be conducted throughout the project;
• How organizational process assets will be tailored to meet the needs of the project;
• How the remaining activities in the Risk Management Planning process will be conducted; and
• Agendas and deliverables for the remaining Risk Management Planning meetings.

Planning Meeting Activities

The planning meeting involves reviewing:

• Key project documents such as:
  • Project charter;;
  • Project scope statement;
  • Project schedule and project budget; and
  • Previous project management administrative work products.
• The planning assumptions
• Historical information, such as documentation of lessons learned from similar projects and risk management plans of previous projects
• Known risks, identified by questions such as:
  • What concerns have sponsors or key stakeholders expressed?
  • What risks have occurred on recent, similar projects?
  • What areas of risk require the team's attention?

Reviewing these materials will facilitate early identification of risks and risk-related information. Additionally, the materials may serve as examples for the current project to emulate.

Risk Breakdown Structure (RBS)

Risk Breakdown Structures

A risk breakdown structure (RBS) is a hierarchical, multi-tiered organization of the risk categories. When risks are being analyzed, grouping them this way makes it possible to gather and review together risks with a common characteristic, such as their cause, or the phase or activity in which they occur.

This approach to reviewing risks that appear together in the risk breakdown structure increases the efficiency of investigating their causes, and may also increase leverage when risk response plans are developed. For example, risks with similar or a shared cause in a particular process step may be mitigated by the same process change.

Definitions of Risk Probability and Impact

The methods for scoring and interpreting the Quantitative and Qualitative Risk Analysis processes must be set in advance to avoid injecting personal biases or inappropriate influence into the attention paid to particular risks. Developing a common standard for defining different levels of a risk's probability and its impact ensures that risks will be analyzed and responded to objectively.

Probability and impact are independent variables.

Risk probability is the likelihood that a risk will occur, on a scale between 0% and 100%, where 0% means it is impossible, and 100% means it is certain.

Risk impact is the effect on project objectives if the risk event occurs.

Risk probability and risk impact are investigated separately; however, a common pitfall is for these terms to be confused, for example, assigning a high probability to a risk because the potential impact is severe. For example, imagine the risk of being struck by lightning - the impact is very high, but the probability is considered very low.

During risk analysis, these two dimensions of risk are applied to specific risks. This helps determine which risk events should be managed most aggressively, and the level of effort and investment that is justified.

Probability and Impact Matrix

Each risk's probability rating (P) is multiplied by its impact rating (I) to generate a "risk score" (RS). Since the number of probability rating values and impact rating values is limited (normally, five of each), all possible combinations can easily be established and entered into a table or matrix. (Tables and matrixes are presented in a subsequent unit, Qualitative Risk Analysis.)

Organizations often find it useful to stratify the resulting RS values into three levels, one representing "low" risks, one representing "moderate" risks, and one representing "high" risks. To signify this, the associated matrix entries can be colored to identify which level they belong to. For example, the low risks may be colored green, the medium risks yellow, and the high risks red.

Using this technique simplifies applying different policies (and hence effort and resources) according to the level of the risk's RS. For example, risks rated as "red" may require review at every weekly status meeting, while "green" risks may be reviewed only monthly, or on a less frequent, rotating basis.

 Reporting Formats

Reporting formats present:

• How the risk response plan will be organized;
• How the risk management activities will be documented, analyzed, and communicated to project stakeholders; and
• The contents and format of the risk register (described later).

10. Tracking Information

The tenth and final component of the risk management plan is tracking information. Tracking information defines how risk management activities will be documented and audited for the following uses:

• Evaluation of the current project's performance; and
• Historical information for the benefit of later projects.

Checklist for the Risk Management Plan

A checklist can be used to complete the risk management plan. The checklist below includes the ten components described on the previous pages, but can be expanded for the specifics of a particular project.

The risk management plan checklist should be completed as the risk management plan is developed, and should be referred to at each planning meeting or review of the risk management plan.

Next page is an example of a risk management plan checklist.

CHECKLIST

A. Methodology

• Does the plan describe how it was developed, and how it will be maintained?
• Does the plan describe how Risk Identification will be carried out?
• Does the plan describe how Qualitative Risk Analysis will be carried out?
• Does the plan describe how Quantitative Risk Analysis will be carried out?
• Does the plan describe how Risk Response Planning will be carried out?
• Does the plan describe how Risk Monitoring and Control will be carried out?

B. Roles and Responsibilities

• Who will direct all risk management activities?
• Who has been designated to participate in the risk management group's work sessions for risk assessment and Risk Response Planning?

• What are the duties of the participants in the risk management group's work sessions, including preparation, outside research, and documentation?

• What governing body will oversee the execution of risk management activities?
• Who represents internal stakeholders in risk management activities?
• Who represents external stakeholders in risk management activities?

C. Budgeting

• Have all risk management activities been budgeted?
• Have contingency reserves for cost been set aside to accommodate residual and secondary risks?

D. Timing

• Has frequency been determined for all regularly occurring risk management activities, such as risk review sessions?

• Have all risk management activities been incorporated into the project schedule?

E. Risk Categories

• If a set of standard risk categories is available in the organization, was it adopted for use on the current project?

• Has the set of risk categories been tailored to suit the characteristics of the current project?

• If a risk breakdown structure (RBS) will be used, has it been developed yet?

F. Definitions of Risk Probability and Impact

• Has a scale of terms been defined for different levels of risk probability?
• Has a scale of terms been defined for different levels of risk impact?

 G. Probability and Impact Matrix

• Has a matrix been constructed reflecting all possible combinations of risk impact and probability levels?
•  Have the entries in the probability and impact matrix been stratified into a small number of overall risk levels?

H. Revised Stakeholder Tolerances

• Have the normal risk tolerances of all stakeholders been reviewed and determined?

• Have any of the stakeholders' risk tolerances been temporarily relaxed or tightened for this particular project?

I. Reporting Formats

• Has a standard entry form for the various sections of the risk register been developed, including the probabilistic project analysis and the revised project objectives, as well as the risk response plans?

• Have report layouts been defined for the periodic reporting of risks to the stakeholders?

• Has a form been designed for stakeholders to report the results of implementing their risk response plans?

• Has a form been designed for identifying new risks?

J. Tracking

• Has a repository been set up to collect risk management work products?
• Are the minutes of risk review meetings being collected and stored in the repository?

• Are the start and stop dates of risk management activities being reported?
• Are all the significant data concerning risk management (reports, notifications, memos) that are reported to stakeholders being recorded in the repository?

• How are the audits of the risk management activities going to be carried out?

Being Proactive in Risk Identification

Using a proactive approach to identify risks is far better than waiting for the problems to arise on their own. Being proactive has the following benefits:

• Anticipating risks allows the participants to become more comfortable discussing and analyzing circumstances and events that would normally cause anxiety. By handling the topics in a methodical way, participants are reassured that the risks will be successfully managed.
• Analyzing the potential for risk helps ensure that all areas of potential risk will be fully explored and that identified risks will receive balanced treatment, regardless of personal biases and influences.

One aspect of the methodical approach involves separating the identification of positive risks from the identification of negative risks. It is usually best to provide separate agenda time or even to set up separate risk assessment sessions for these two kinds of risks. The reason for this is that thinking about negative risks tends to dominate the participant's attention since anxiety is such a powerful emotion. If the two types of risk are considered in the same period, the positive risks will tend to get overlooked or only reviewed in a cursory manner.

Some risks will be seen to have both positive and negative impacts, depending on the actions taken. For example, a risk that a task will take longer than expected may also present an opportunity to finish sooner than expected.

Checklist Analysis Advantages and Disadvantages

Advantages of Checklist Analysis

The advantages of using checklist analysis to identify risks are:

• Checklists are helpful when they reflect lessons learned from previous projects; and
• Checklists are simple and efficient.

Disadvantages of Checklist Analysis

The disadvantages of using checklist analysis to identify risks are:

• Checklists can be limiting if the team automatically assumes that the checklists are comprehensive and complete, which is rarely the case; and
• A large project is likely to require a lengthy checklist and no checklist can be wholly adequate without being tailored to the current project.

A Sample Checklist

An organization involved in project management should consider developing a risk checklist specific to its needs; however, the sample below may be sufficient for most projects.

The checklist below shows risks by category, such as technology and time. When time is short, this type of checklist lets the team focus on specific areas for their risk potential rather than running through the entire list. Once an area of concern is flagged, it is necessary to identify specific risk statements that describe the specific concern more completely, for example, "Development software vendor fails to provide adequate technical support," or "Major snowstorm prevents team from reaching offices for two workdays

A. Technology

New technology?

Unknown or poorly documented technology?

New application of existing technology?

Advanced technology being modernized in existing application?

B. Time

Project schedule uncertainties or constraints that may impact project completion or milestone dates?

Procurement items with long lead times that may affect completing the critical path or milestones?

C. Contractor Capabilities

Potential that qualified vendors or contractors may not be available?

D. Interfaces

Significant transportation or infrastructure impacts?

Multiple project interfaces?

Significant interfaces with an operational facility?

E. Safety

Risks to worker safety during construction?

Significant contamination potential?

Accidents due to new design or other non-reviewed safety questions?

Involvement of hazardous material?