Collaborative tools and techniques to build the project risk plan

Abstract

Through our experience working with project teams in many industries and on hundreds of projects, we recognize that although project managers are expected to manage risk on their projects, many times they end up fighting fires and managing the problems that result from unmanaged or unknown risks. There are many reasons why project managers avoid risk management and resort to firefighting project problems. Among the reasons are these perceptions:

  • “My project won't hurt anybody.”
  • “Our company has a ‘kill-the-messenger’ syndrome, so it is best not to bring up risks.”
  • “Firefighting is rewarded—the more problems I can solve, the better I look.”
  • “Failure is not an option, so why focus on risks? Our team won't allow them to impact the project.”
  • “Risk is inevitable, so why bother trying to avoid or manage it?”

We realize that many times the underlying reason for not managing risk on projects, or not managing it well, is that the project manager does not have the right tools and techniques for risk management. Oftentimes, project managers understand the need to manage risk, but they do not have the right tools to transform the theory into practical application, which will enable them to engage the project stakeholders in the risk management process (identifying, assessing, and effectively responding to risks). They may attempt to build a risk plan on their own. This results in the project manager being the only person who buys in to the risk plan and who understands the effort needed to manage the risks. Additionally, the scope of risks included in the plan is limited by the frame of reference of the project manager. This approach leaves many project risks unidentified and unmanaged, and reliance on the firefighting effort strong, time consuming, and costly to the project.

This paper focuses on tools and techniques that can be used to run a facilitated meeting to collaboratively build a comprehensive project risk plan, gaining alignment from all project stakeholders, in one to two days. The value gained in developing the project risk plan in a collaborative manner is that hundreds of project risks can be uncovered and managed, throughout the project lifecycle.

Overview of Risk and Risk Management

In order to identify project risks, it is necessary to first agree on the definition of what a project is. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) defines a project as “A temporary endeavor undertaken to create a unique product or service” (PMI, 2004, p. 5). Temporary means the project has an end, and unique means that the project is bringing about change by providing an end result that is different than what an organization is currently experiencing.

Uncertainty is directly associated with the change being produced by a project. Project risk can be defined as any uncertainty, or surprise, that if it occurs, would affect one or more project objectives negatively (a threat hurting the project's cost, time, quality, or scope) or positively (an opportunity enhancing the project's cost, time, quality, or scope). It is important to recognize that uncertainty, by itself, is not project risk. There must be an impact to one or more project objectives to have risk. For example, the chance that it might rain this afternoon is an uncertainty—but why would we be concerned about this? On the other hand, because rain has been forecast for this afternoon, it might prevent us from pouring the foundation's concrete, which could cause a delay in completing the foundation work; this describes an uncertainty along with a statement of impact for which we can sense concern. Problems and issues are not project risk either, because they have already occurred, and the uncertainty no longer exists. Project risk arises from the interaction of objectives and uncertainty.

Risk management can be defined as the systematic process of identifying, analyzing, and responding to project risk. Because risks can have positive or negative impacts on project objectives, risk management focuses on maximizing the probability and consequences of positive impacts to project objectives and minimizing the probability and consequences of negative impacts on project objectives. Several factors can stand in the way of an effective risk management effort, including:

  1. A lack of management support
  2. Preparing a risk plan with insufficient project knowledge
  3. Risk management is not an integral part of the organization's project methodology
  4. Too little time is invested in identifying and managing risk
  5. Too few risks are identified (10–20 risks versus hundreds of possible risks).

The Project Risk Facilitated Meeting

An effective means of overcoming the barriers that stand in the way of effective risk management is to use JAD (Joint Application Design) facilitated meetings. JAD meetings are led by a neutral facilitator (someone without a stake in the project) with the purpose of engaging all the appropriate stakeholders as participants, at the same time in a meeting, to make project decisions and create project deliverables.

To increase the successfulness of any JAD meeting, it must be fully planned prior to starting the meeting. Planning enables the project management team and the facilitator to set expectations and agree on the deliverables, activities to be created, and techniques that will be used to produce risk plan deliverables, during the meeting. A standard planning template and facilitator's agenda can save time preparing for the meeting and creates consistency in the planning effort. The facilitator conducts the meeting using collaborative techniques to collect information, validate this information, and continually adjust it to ensure it is clear, complete, and addresses the needs of the project. The results of facilitated JAD meetings are consensus among participants, ownership, and buy-in on all decisions made and all deliverables produced during the meeting.

Sources and Methods for Identifying Risk

There is no reason for the project team to start from a blank slate when beginning to identify the project risks. Just by defining the scope of the project, the team has valuable information available for this effort. The project risk facilitated meeting uses deliverables that are already created for the project, including the project scope statement, which provides business and project objectives, project constraints, critical success factors, and project assumptions. Additionally, the project team can use the business and technical requirements as the project progresses to identify risks, as well as reviewing lessons learned from prior similar project efforts.

Project assumptions state expectations that one situation will occur over another, while critical success factors state mandatory project accomplishments. Project constraints define limits the project must operate within, and relaxing these could facilitate achieving the objectives or enhancing project outputs. When using project assumptions and critical success factors to develop project risks, the meeting participants review each statement, test it for instability (how likely is it to be false or relaxed or removed), and test it for sensitivity (if the assumption is false or the critical success factor cannot be met or the constraint is removed or relaxed, what is the impact to the project objectives). During the meeting, participants determine the appropriateness of converting these statements to project risks.

Another source for identifying project risks is the project's SWOT analysis, which is an assessment of the project's strengths, weaknesses, opportunities, and threats. The SWOT analysis is typically created for a project during the project scoping facilitated meeting. Because project risks can have positive impacts on the project objectives (opportunities) or negative impacts on the project objectives (threats), this deliverable provides a direct link to the project risk plan. The strengths and weaknesses listed in the SWOT analysis describe the project team's influence on exploiting or missing opportunities, or increasing or reducing the exposure to threats.

Once the existing project deliverables are evaluated for inclusion or exclusion in the project risk plan, the team can also use brainstorming, which is one of the most frequently used techniques, to identify other project risks. A brainstormed risk identification activity results in team building and team buy-in. The scoping deliverables provide focus during the brainstormed activity. Additionally, the participants can use the project work breakdown structure, as well as a separate risk breakdown structure. Using these deliverables helps avoid overlooking risks or focusing solely on negative risks.

By combining multiple risk collection methods, the project manager can reduce the likelihood of overlooking risks that could impact the project. This also provides an opportunity for the project stakeholders to consider project impacts from multiple perspectives. The use of collaborative meetings to develop the project risk plan creates both team and stakeholder buy-in and improves the overall quality of the risk management effort.

The Risk Management Process

The Risk Management Process consists of five processes or steps:

1. Risk Definition Process

2. Risk Identification Process

3. Risk Assessment Process

5. Risk Monitoring and Review Process

The Risk Definition Process occurs once at the beginning of any risk management effort, while the other processes are iterative and occur repeatedly throughout the project life cycle. As the project progresses, old project risks can expire and new project risks become relevant. The Risk Management Process addresses these changing needs in managing project risks.

Risk Definition Process

The Risk Definition Process defines the scope of the risk management effort. Similar to the overall project effort itself, which has a definition phase where the project effort is determined and communicated, the risk management effort also must be clearly defined and communicated to the project stakeholders. During this phase, determinations are made as to which objectives from the project will be assessed for risk exposure, and a risk management plan is created. The objectives are categorized as cost (cost to deliver the project within budget), time (schedule for delivering the project in the agreed time frame), quality (delivering the project to the specifications agreed to by the stakeholders), and scope (delivering the expected requirements/functionality for the project). Although this process develops the framework and produces the plan for the risk management effort, the specific risks are not defined during this process.

The risk management plan communicates who will participate in the risk management process and the roles and responsibilities for those participants. Additionally, it defines the types of risks to be managed and the organization's sensitivity to the impacts associated with the risks. Every organization has a different maturity and tolerance for risk. By aligning the risk management effort for the project with the risk maturity level of the organization, the chances of succeeding with the risk management effort improve. The plan also describes the approaches, tools, and data sources to be used for risk identification and assessment. The plan communicates the frequency of assessing and reporting on the project risks and the approach for ongoing monitoring throughout the life cycle of the project.

The organization's risk tolerances and thresholds take into account how risk-averse or risk-accepting the organization is. This refers to not wanting to take any risk versus balancing the risk occurrence with the impact or reward. Understanding risk tolerances and thresholds influences the types of risk responses defined in the risk plan (for example, reputational risks may not be tolerated at all, schedule delays of four days or less may be acceptable, and so forth). Also influenced is the accuracy of risk perception, in terms of what is and is not viewed as a risk, as well as the severity of each risk identified for the project.

Once the risk tolerances and thresholds are determined, the team needs to adjust or create a probability-impact matrix to be used during the risk assessment process. Typical ratings we start with on projects for probability are:

  • High – Almost certain to occur, 70% – 99% chance, value = 3
  • Medium – Fairly likely to occur, 30% – 69% chance, value = 2
  • Low – Unlikely to occur, less than 30% chance, value = 1

Notice the highest probability is 99%. This is because items identified as 100% likely to occur are not uncertainties and therefore not risks—they are known problems or issues that need to be dealt with as such.

Typical impact ratings measuring the effect on project objectives we use are:

  • High – Critical

    •    > 40% deviation of cost or > 20% deviation in schedule

    •    associated scope or quality reductions are unacceptable making the project result useless

    •    value = 3

  • Medium – Significant

    •    10% – 40% deviation of cost, 5% – 20% deviation of time

    •    major areas of scope or quality are affected, requiring project sponsor approval

    •    value = 2

  • Low – Insignificant

    •    < 10% deviation of cost, < 5% deviation in schedule

    •    degradation to scope or quality is barely noticeable

    •    value = 1

During the facilitated meeting, we update a color-coded probability-impact matrix to communicate which risk scores (probability x impact) will be targeted for developing responses, versus those that might only be watched.

Probability-Impact Matrix Example

Exhibit 1 – Probability-Impact Matrix Example

Risk Identification Process

The Risk Identification Phase begins the repeatable part of the Risk Management Process, and occurs after completing the risk definition activity in the facilitated meeting. Risk identification is the process of exposing and recording all foreseeable risks to the project objectives. The risk register is the key deliverable used to track risks, and is built in waves during the facilitated meeting. This deliverable is initiated with the identification of project risks. During the Risk Identification Process, the meeting participants are led through an activity allowing them to distinguish between the cause of the risk, the risk itself, and the effect of the risk occurring (positive or negative). It is typical on a project that 80% of the risks are a result of 20% of the causes.

We start the risk identification activity by reviewing the project scope deliverables (constraints, assumptions, critical success factors, SWOT analysis) and brainstorming the possible risk statements. Once the brainstorm subsides, the participants review each statement and clarify it to ensure that they have clearly differentiated cause, risk, and impact in each statement. To make this activity simpler, we have adopted a Risk Meta-Language technique (Hillson, 2004, p. 73).

The elements of the Risk Meta-Language are:

As a result of <definite cause>, an <uncertain event> may occur, which would lead to <effect on the project objectives>.

Example of using risk meta-language:

As a result of not being able to control the availability of our project resources, we may have to develop the critical data interfaces with less experienced staff, which would affect our ability to deliver the complete interface solution for the project.

This technique provides an easy way to group related risks by cause, whereby addressing one cause can eliminate multiple risks and their impacts to the project. The “definite cause” describes facts or conditions that exist in the project environment that give rise to the uncertainty, and we use present tense verbs to describe this. The “uncertain event” describes uncertainties that may or may not occur, and if they do, they will affect one or more of the project objectives. We use conditional verbs to describe the “uncertain event.” Finally, the “effect on the project objectives” describes the unplanned variations from the project objectives of cost, schedule, quality, or scope, and we use future tense verbs to describe this.

Risk Identification Example

Exhibit 2 – Risk Identification Example

Risk Assessment Process

The next activity conducted during the risk plan facilitated meeting is the risk assessment. The participants are led through a process of prioritizing the project risks, by understanding which risks are most important to manage, based on their probability and impact to the project. A complete risk register may contain hundreds of risk statements. It is not likely that all the risks can and should be addressed at the same time. By using the probability-impact matrix and the related definitions created during the risk planning process, we lead the meeting participants through a qualitative assessment activity.

A qualitative versus quantitative assessment is the initial assessment performed, and many times the only type of assessment used. A qualitative assessment is a simpler approach that can be easily facilitated, using words and phrases to represent the dimensions of probability and impact. The qualitative assessment generally provides enough understanding of the risk, and allows for easy prioritization of the risks, to develop appropriate responses. A quantitative assessment, on the other hand, is a more complex approach that cannot be accomplished during a facilitated meeting. It generally requires sophisticated software to perform statistical numerical analysis.

Meeting participants review each risk statement answering these questions:

  • How likely is it that this risk will occur (probability)
  • If the risk does occur, what is the impact to the project cost, schedule, quality, or scope (impact)

A risk score can be calculated by multiplying the risk probability value by each risk impact value. If the risk impacts more than one type of objective, we sum the individual risk score values into one overall risk score. For instance, a risk could have a high likelihood of occurring, giving it a value of 3 for probability. The risk could impact both cost and quality objectives differently (high impact to cost for an impact value of 3 and low impact to quality for an impact value of 1). The resulting risk score would be (3 x 3) + (3 x 1) = 12.

Risk Assessment Example

Exhibit 3 – Risk Assessment Example

Risk Response Identification Process

The Risk Response Identification Process is completed during the facilitated meeting, typically on all high- and medium-scoring risks. Risks with a low risk score are generally treated as risks to be watched, and may not have a response identified. As the project progresses, the risk scores of risks on the watch list may increase, due to changing circumstances on the project, requiring responses to be identified. The effectiveness of the risk responses can influence the risk exposure. Responses to risk may result in eliminating a cause, which in turn could eliminate multiple risks. The information contained in the risk responses also provides information for adjusting project schedules and budgets as needed for contingency.

Many project teams believe there is only one risk response, mitigation, and define all of their responses as such. This approach is limiting and can create more exposure. Risks and the nature of each response can be addressed in one of four ways, depending on whether the risk is a threat or an opportunity.

  • Avoid (Threat) / Exploit (Opportunity)

    •    Remove the cause of the risk by executing the project in a different manner

    •    Exploit the likelihood of the risk occurring by removing the uncertainty to ensure the opportunity happens

  • Transfer (Threat) / Share (Opportunity)

    •    Shift responsibility of risk ownership to a more appropriate organization or entity to better manage the threat (contracts with third parties, insurance, and so forth)

    •    Share the opportunity with another organization or entity best suited to ensure the opportunity happens (such as contract or partnering with third parties)

  • Mitigate (Threat) / Enhance (Opportunity)

    •    Preventive actions to reduce the likelihood of a risk occurring or making the impact less severe

    •    Enhancement to maximize the benefit of the opportunity to the project

  • Acceptance (Threat or Opportunity)

    •    Passive acceptance incorporates the residual risk impact into the baseline of the project

    •    Active acceptance involves developing a contingency plan

Contingency plans are actions to be taken when the risk occurs (such as disaster recovery or business continuity plans). They are used when the responses to the risk produce unintended effects on the risk exposure and help minimize the adverse impact of the risk. Defining a contingency plan is not enough on its own. For a contingency plan to be valuable to the project team, it must also be planned, funded, and resourced—ready to execute in the event it is needed.

During the facilitated meeting, the participants review each high- and medium-scoring risk to document the type of response and a clear brief description of the response action. If needed, a contingency is also documented. The final step includes assigning project team/stakeholder responsibility for executing the risk response/contingency.

Risk Response Identification Example

Exhibit 4 – Risk Response Identification Example

Risk Monitoring and Review Process

Risk Monitoring and Review closes the loop of the Risk Management Process, by creating a continuing process to review how the project's risk exposure has changed, if at all, assessing the effectiveness of the risk response actions and communicating the results of the risk management process to the project stakeholders. During the facilitated meeting, the participants create the risk communication plan to manage communication to the project stakeholders.

Risk plan updates occur based on the frequency defined earlier in the Risk Definition Process. During the ongoing risk monitoring and review effort, risk responses are continually reviewed for effectiveness and determinations are made about whether new responses are required, due to changes in probability-impact rankings, changes in project variables, or external circumstances. During the review meetings, participants also identify and assess new risks to be managed, which is the beginning of the risk management loop. Secondary risks may occur as a result of original risk responses, and additional risks may become visible later in the project that were not visible earlier. Workarounds are also created to address any unplanned or unmanaged risks that have occurred (problems or issues) and are identified.

The risk communication plan is a deliverable built during the facilitated meeting to document the types of information to be communicated to the project stakeholders throughout the project duration. This deliverable identifies the stakeholders requiring communication, their interest in the project, the information required to be communicated, the purpose of providing the information to the stakeholders, the frequency of reporting the information, and the format for reporting.

Summary – Critical Success Factors For Effective Risk Management

In summary, the risk management effort is not a one-time activity on the project. It is required to manage the exposure to the project objectives that results from changes that are being introduced into the environment. The more people involved in identifying risks and developing responses to risks, the higher the likelihood of limiting unforeseen problems and issues that take the project off track or impact the teams ability to succeed on the project.

There are four critical success factors that influence the effectiveness of a risk management effort in an organization:

  •      CSF-001 – clear and widely accepted definitions
  •      CSF-002 – simple/scalable process
  •      CSF-003 – appropriate infrastructure to support the risk process
  •      CSF-004 – attention to risk attitudes

As organizations embrace CSF-001 (clearly and widely accepted definitions), they accept the fact that risk is related to uncertainty and, if it happens, the risk will affect a project objective. Organizations also realize that risk is different from problems and issues, which have already occurred, and the culture shifts from rewarding and encouraging firefighting to managing the risk. These organizations also recognize that a lack of clarity regarding risks produces confusion, inefficiency, and wasted effort in risk management.

As organizations adopt CSF-002 (simple/scalable process), they incorporate the five processes of risk management into their methodology (Risk Definition Process, Risk Identification Process, Risk Assessment Process, Risk Response Identification Process, and Risk Monitoring and Review Process). The processes implemented are simple enough to meet the needs of every project, recognizing that complex processes are avoided by project managers and perceived as overhead and cost drivers, with minimal value.

As organizations achieve CSF-003 (appropriate infrastructure to support the risk process) they have achieved the right balance between a casual and a formal process, with the appropriate tools, techniques, resources, and training required to support the process. With too little infrastructure, risk management is difficult to manage and repeat efficiently. With too much infrastructure, risk management adds costs without value.

As organizations achieve CSF-004 (attention to risk attitudes), they recognize the difference between, and identify themselves appropriately, as being risk-averse, risk-tolerant, risk-neutral, or risk-seeking. Risk-averse organizations are uncomfortable with uncertainty and tend to identify many risks as severe threats, requiring aggressive responses. Risk-seeking organizations tend to be more relaxed about risk, with a higher threshold for accepting risk.

References

Project Management Institute. (2004). A guide to the project management body of knowledge (PMBOK® guide) (2004 ed.). Newtown Square, PA: Project Management Institute.

Hillson, D. (2004). Effective opportunity management for projects – Exploiting positive risk. New York: Marcel Dekker Inc.

© 2007 Paul Burek
Originally published as part of 2007 PMI Global Congress Proceedings – Atlanta, GA, USA

Advertisement

Advertisement

Related Content

  • PM Network

    New Digs member content locked

    By Waity, C. J. Ore deposits are hardly the only factor project leaders use to determine future mining sites in Latin America. Everything from geopolitical turmoil to local labor markets can impact a mining…

  • PM Network

    Interior Motives member content locked

    By Wenger, Fred Project managers are accustomed to looking outside their projects for risks—at competitors, clients, suppliers, the economy, even the weather. But experience has taught me that all projects face a…

  • PM Network

    Rookie Revelations member content locked

    PM Network asks the project management community to share their mistakes made at the beginning of their careers.

  • PM Network

    Safety in Numbers member content locked

    PM Network interviews Henry Jong-Hyeon Lee, PhD, PMP, corporate senior vice president, mobile security technologies at Samsung Mobile in Suwon, South Korea.

  • PM Network

    Rethinking Modular? member content locked

    By Ali, Ambreen The collapse of a prefabricated bridge in March in Miami, Florida, USA killed six people and made national headlines. It also reignited a discussion of whether modular makes sense in large-scale…

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.