Write a one page summary on the attachment Identifying Risk

4.1 

Identify Risks

Exam Objectives

3. Domain 3: Risk Process Facilitation

3.1. Task 1 Apply risk assessment processes and tools in order to quantify stakeholder risk tolerances and determine risk levels.

3.2. Task 2 Facilitate risk identification using a variety of techniques in order to enable the project team and stakeholders to understand and determine the risk exposure of the project.

3.3. Task 3 Facilitate the project team’s evaluation of the identified risks’ attributes using qualitative and quantitative tools and techniques in order to prioritize the risks for response planning.

3.4. Task 4 Facilitate the development of an aligned risk response strategy and related risk actions by risk owners from the information gathered during risk analysis in order to ensure timely and defined action when required.

3.5. Task 5 Facilitate the formulation of project contingency reserve based on the risk exposure of the project in order to have the capability and resources to respond to realized risks.

The Identify Risks process involves identifying all the risks that might impact the project, documenting them, and documenting their characteristics. Identify Risks is an iterative process that continually builds on itself and is performed throughout the project.
As you progress through the project, more risks might present themselves. Once you've identified or discovered a potential new risk, you should analyze it to determine whether a response plan is needed. You can see that the risk management cycle starts again with Identify Risks and progresses through the remaining risk processes to determine what to do about them.
The objectives of risk identification are as follows:

• Identifies and categorizes risks that could affect the project and documents these risks

• Defines the parameters used for analyzing and categorizing risks, and the parameters used for controlling the risk management effort

• Establishes and maintains the strategy to be used for risk management

Risks might or might not adversely affect the project. Some risks have positive consequences, whereas others have negative consequences. However, you should identify all risk events and their consequences. Here's a partial list to get you thinking about where risk might be found:

• Budgets/funding

• Schedules

• Scope or requirements changes

• Project plan

• Project management processes

• Technical and personnel issues

• Hardware

• Contracts

• Political concerns

• Business processes

• Legal processes and activities

• Environmental concerns

• Management policies, processes, and attitudes

This is by no means an exhaustive list. Remember that risk is uncertainty and realize that risk (uncertainty) is lurking almost anywhere on your project. It's your job to discover as many of the potential risks as possible using the tools and techniques of this process and to document these risks.
The inputs, tools and techniques, and outputs of the process are shown in Figure 4-1.

Figure 4-1: Identify Risks: Inputs, Tools and Techniques, and Outputs
Figure 4-2 shows the data flow diagram for the process.

Figure 4-2: Identify Risks: Data Flow Diagram
This process considers both individual project risks and sources of overall project risk. Participants involved in the risk identification activities may include the project manager, project team members, project risk specialist (if assigned), customers, subject matter experts from outside the project team, end users, other project managers, operations managers, stakeholders, and risk management experts within the organization. Risk events can occur at any time during the project, and all project participants should be encouraged to continually watch for and report potential risk events.
To describe and record individual project risks, a consistent format should be used for risk statements to make sure that each risk is understood clearly and unambiguously. For individual project risks, risk owners can be nominated as part of the Identify Risks process and will be confirmed during the Perform Qualitative Risk Analysis process. Also, preliminary risk responses can be determined and recorded, which will be reviewed and confirmed as part of the Plan Risk Responses process.

Inputs of the Identify Risks Process

Here are the inputs of the Identify Risks process:

• Project management plan: The components of the project management plan include:
  

  • Requirements management plan: It identifies project objectives that are particularly at risk.

  • Schedule/cost management plan: It identifies areas that are subject to uncertainty or ambiguity.

  • Quality/resource management plan: It identifies areas that are subject to uncertainty or ambiguity. Also, it identifies key assumptions that can give rise to risk.

  • Risk management plan: It documents information on risk-related roles and responsibilities. It describes risk categories and indicates how risk management activities are included in the budget and schedule.

  • Scope baseline: It includes deliverables and acceptance criteria, which might give rise to risk. It also includes the WBS (work breakdown structure), which can be used as a framework for structuring risk identification techniques.
    

Note

The WBS is a hierarchical decomposition of the total scope of work to be done by the project team for achieving the project objectives and creating the required deliverables. It helps in organizing and defining the total scope of the project and represents the work specified in the present approved project scope statement.
The WBS includes work packages, which are the lowest level of WBS components where the planned work is stored. A work package is used to group the activities where work is scheduled and estimated, monitored, and controlled. In terms of the WBS, work is referred to as work products or deliverables that are the outcome of an activity and not to the activity itself.

• • Schedule baseline: It identifies milestones and deliverable due dates that are subject to uncertainty or ambiguity.

  • Cost baseline: It identifies costs or funding requirements that are subject to uncertainty or ambiguity.

• Project documents: For this process, project documents that can be considered as inputs include:
  

  • Assumption log: It includes assumptions and constraints that may give rise to individual project risks and may also influence the level of overall project risk.

  • Cost estimates: They provide quantitative assessments of project costs, ideally expressed as a range, indicating the degree of risk.

  • Duration estimates: They provide quantitative assessments of project durations, ideally expressed as a range, indicating the degree of risk.

  • Issue log: It records issues that may give rise to individual project risks and may also influence the level of overall project risk.

  • Lessons learned register: It is reviewed to determine whether similar risks might recur during the remainder of the project.

  • Requirements documentation: It lists the project requirements and allows the team to identify those project requirements that could be at risk.

  • Resource requirements: They provide quantitative assessments of project resource requirements, ideally expressed as a range, indicating the degree of risk.

  • Stakeholder register: It details those individuals who are available to act as risk owners.

• Agreements: If the external procurement of resources is required by the project, the agreements may include information such as milestone dates, contract type, acceptance criteria, and awards and penalties that can present threats or opportunities.

• Procurement documentation: If the external procurement of resources is required by the project, the initial procurement documentation should be reviewed as procuring goods and services from outside the organization which may increase or decrease overall project risk and may introduce additional individual project risks.

• Enterprise environmental factors: These can influence the Identify Risks process and include published material, including commercial risk databases or checklists; academic studies; benchmarking results; and industry studies of similar projects.

• Organizational process assets: These can influence the Identify Risks process and include project files, including actual data; organizational and project process controls; risk statement formats; and checklists from previous similar projects.

Knowledge Check

Tools and Techniques of the Identify Risks Process

Here are the tools and techniques of the Identify Risks process:

• Expert judgment: Experts for risk identification purposes can include anyone who has experience in working on similar projects, experience in working in the business area for which the project was undertaken, or specific industry experience. When using this technique, you should consider any bias your experts may have regarding the project or potential risk events and take that into account when performing the risk processes.

• Data gathering: It encompasses several techniques, including brainstorming (Delphi technique), checklists, and interviewing. The goal of these techniques is to end up with a comprehensive list of risks at the end of the meeting. Let's take a quick look at each of these techniques.
  

  • Brainstorming: It is probably the most often used technique of the Identify Risks process. Brainstorming involves getting subject matter experts, team members, risk management team members, and anyone else who might benefit the process in a room and asking them to start identifying possible risk events. The trick here is that one person's idea might spawn another idea, and so on, so that by the end of the session you've identified all the possible risks. The facilitator could start the group off by going through the categories of risks, and/or using RBS to get everyone thinking in the right direction.
    

Exam Spotlight

Delphi technique is a lot like brainstorming, except that the people participating in the meeting don't know one another. In fact, the people participating in this technique don't all have to be located in the same place and usually participate anonymously. You can use email to facilitate the Delphi technique easily.
The Nominal Group technique is not included as part of the information gathering techniques in the PMBOK Guide. However, it's possible you may see a question about it on the exam. The Nominal Group technique is a brainstorming technique, or it can be conducted as a mass interview technique.
This technique requires the participants to be together in the same room. Each participant has paper and pencil in front of them, and they are asked to write down what risks they think the project faces. Using sticky notes is a good way to do this. Each piece of paper should contain only one risk. The papers are given to the facilitator, who sticks them up on a wall or whiteboard. The panel is then asked to review all the risks posted, rank them and prioritize them (in writing), and submit the ranking to the facilitator. Once this is done, you should have a complete list of risks.

• • Checklists: This technique is used as a reminder and includes a list of items, actions, or points to be considered. These are used during the Identify Risks process and are usually developed based on historical information and previous project team experience. The checklist should be reviewed from time to time for updating new information as well as removing or archiving obsolete information. You may also obtain risk checklists from sources that are specific to your industry. If you typically work on projects that are similar in nature, begin to compile a list of risks. You can then convert this to a checklist that will allow you to identify risks on future projects quickly and easily. However, don't rely solely on checklists for Identify Risks because you might miss important risks. It isn't possible for a single checklist to be an exhaustive source for all projects. You can improve your checklists at the end of the project by adding the new risks that were identified. It identifies potential risks and helps plan for them ahead of time. It is a quick and simple approach for performing an initial high-level analysis of risks. This analysis will not identify new risks that are not on the checklist. This is a limitation.

  • Interviews: These are question-and-answer sessions held with others, including other project managers, subject matter experts, stakeholders, customers, the management team, project team members, and users. These folks provide you with possible risks based on their past experiences with similar projects.
    This technique involves interviewing those folks with previous experience on projects similar to yours or those with specialized knowledge or industry expertise. Ask them to tell you about any risks that they've experienced or that they think might happen on your project. Show them the WBS and your list of assumptions to help get them started thinking in the right direction.

• Data analysis: It also involves several techniques including root cause analysis (RCA), assumption and constraint analysis, SWOT analysis, and document analysis. We'll look at each as they pertain to this process.
  

  • RCA (root cause analysis): It involves digging deeper than the risk itself and looking at the cause of the risk. This helps define the risk more clearly, and it also helps you later when it's time to develop the response plan for the risk. A great technique you can use for RCA is called 5 Why's.

  • Assumption and constraint analysis: It is a matter of validating the assumptions and constraints you identified and documented during the course of the project-planning processes. Assumptions should be accurate, complete, and consistent. Examine all your assumptions for these qualities. Assumptions are also used as jumping-off points to further identify risks.
    The important point to note about the project assumptions is that all assumptions are tested against two factors:
    

    • The strength of the assumption or the validity of the assumption

    • The consequences that might impact the project if the assumption turns out to be false

All assumptions that turn out to be false should be evaluated and scored just as risks.
Constraints are examined to determine if they are valid and accurate and to determine which ones could bring about risk. Examine the constraints that could bring about positive risks to see if the risks could be enhanced by softening the restrictions caused by the constraint or if the constraint should be eliminated altogether.

• • SWOT (strengths, weaknesses, opportunities, and threats): Strengths, weaknesses, opportunities, and threats (also known as SWOT analysis) is a technique that examines the project from each of these viewpoints. It also requires examining the project from the viewpoint of the project itself and from project management processes, resources, the organization, and so on to identify risks, including those that are generated internally to the project. Strengths and weaknesses are generally related to issues that are internal to the organization. Strengths are what your organization does well according to your customers, or the marketplace. Weaknesses are areas the organization could improve upon. Typically, negative risks are associated with the organization's weaknesses and positive risks are associated with its strengths. Opportunities and threats are usually external to the organization. SWOT analysis is sometimes known as internal-external analysis and can be used in combination with brainstorming techniques to help discover and document potential risks.

  • Document analysis: It involves reviewing project plans, assumptions, procurement documents, and historical information about previous projects from both a total project perspective and from the individual deliverables and activities level. This review helps the project team to identify risks associated with the project objectives. Pay attention to the quality of the plans (is the content complete, or does it seem to lack detail?) and the consistency between plans. An exceptionally documented schedule is great, but if the budget isn't as well documented, you might have some potential risks.

• Interpersonal and team skills: The interpersonal and team skills that can be used for this process include facilitation, which helps in improving the effectiveness of many of the techniques used to identify individual project risks and sources of overall project risk.

• Prompt list: This list is somewhat similar to a checklist in that you have a defined set of risk categories you can use to determine both individual risks and overall project risks. You can use the lowest level of the RBS to construct a prompt list for individual risks. According to the PMBOK Guide, you could consult strategic analysis tools to assist in determining overall project risk such as PESTLE, TECOP, or VUCA.
  PESTLE analysis examines political, economic, social, technological, legal, and environmental factors to see if they may have an overall project impact. For example, let's say your project involves new oil and gas drilling procedures. When examining risks from the perspective of PESTLE, environmental factors should jump right out as a potential area for overall project risk. The team should explore this area in depth to determine and identify the risks that could impact the project.
  TECOP analysis looks at technical, environmental, commercial, operational, and political risks. Like in the earlier example, you should examine each of these elements to determine if there are overall project risks that could impact the project.
  VUCA analysis looks at volatility, uncertainty, complexity, and ambiguity.

• Meetings: For risk identification, the project team may hold a specialized meeting, also called as risk workshop. Most risk workshops embrace some variety of brainstorming however other risk identification techniques could also be enclosed depending on the level of the risk process outlined within the risk management plan. Use of a skilled facilitator will increase the effectiveness of the meeting. It is important to ensure that the right people participate in the risk workshop. For larger projects, it will be appropriate to invite the project sponsor, subject matter experts, sellers, representatives of the customer, or other project stakeholders. Risk workshops for smaller projects may be restricted to a subset of the project team.

Estimating techniques

The risk manager should be familiar with three specific estimating techniques in order to properly analyze activity cost and duration estimates, as part of the activity duration and activity cost estimates inputs. The estimating techniques are as follows:

• Analogous estimating: It is a technique that uses the values of parameter, such as scope, cost, budget, and duration or measures of scale such as size, weight, and complexity from a previous, similar activity as the basis for estimation of the same parameter for a future activity. It is a top-down estimating technique and is a form of expert judgment. It provides a lower degree of accuracy than other estimating techniques. This technique is primarily used when there is a limited amount of detailed information about the project or program.
  With this technique, you will use the actual duration of a similar activity completed on a previous project to determine the duration of the current activity—provided the information was documented and stored with the project information on the previous project. This technique is most useful when the previous activities you're comparing are similar to the activity you're estimating and don't just appear to be similar.
  This technique is especially helpful when detailed information about the project is not available, such as in the early phases of the project. Top-down estimating techniques are also used to estimate total project duration, particularly when you have a limited amount of information about the project. The best way to think about top-down techniques is to look at the estimate as a whole.

• Parametric estimating: It is a quantitatively based estimating method that multiplies the quantity of work by the rate or uses an algorithm in conjunction with historical data to determine the cost, budget, or duration estimates. This technique can be highly accurate depending on the sophistication and underlying data built into the model.

• Bottom-up estimating: It is a cost estimating technique that estimates the cost of individual work packages or schedule activities to the finest level of detail. The detailed cost is rolled up (or summarized) to higher levels to arrive at a total project estimate. The summarized data are very useful for reporting and tracking purposes. Bottom-up estimating provides a higher degree of accuracy.

Knowledge Check

Outputs of the Identify Risks Process

Here are the outputs of the Identify Risks process:

• Risk register: It documents details of identified individual project risks. It is a document that contains results of the Perform Qualitative Risk Analysis, Plan Risk Responses, Implement Risk Responses, and Monitor Risks processes. On completion of the Identify Risks process, information in the risk register includes:
  

  • List of identified risks

  • Potential risk owners

  • List of potential responses

The risk register also often contains warning signs, or triggers, although they aren't listed as an official part of the register. You'll take a look at all of these elements next. Understand that all risks should be documented, tracked, reviewed, and managed throughout the project.

• • List of identified risks: Risks are all the potential events and their subsequent consequences that could occur as identified by you and others during this process. You might want to consider logging your risks in a risk database or tracking system to organize them and keep a close eye on their status. This can easily be done in spreadsheet format or whatever method you choose. List the risks, assign each risk a tracking number, and note the potential cause or event and the potential impact. This list gives you the means to track the risks, their occurrence, and the responses implemented.

  • Potential risk owners: Risk owners are the departments or individuals responsible for monitoring the risks, implementing risk response plans if the risk event occurs, and updating the project team on status.

  • List of potential responses: You might identify potential responses to risks at the same time you're identifying the risks. Sometimes just identifying a risk will tell you the appropriate response. Document those responses here.
    A sample risk register is shown in Table 4-1. As you progress through the risk planning processes, and through the project itself, more risks may be identified and more information will become known about the risks. You should update the risk register with new information as it becomes known.
    

    Table 4-1: A Sample Risk Register
    ID	Risk	Trigger	Event	Cause	Impact	Owner	Response Plan
    	Infrastructure team is not available when needed	Predecessor tasks are not completed on time	Operating system upgrade is delayed	Equipment was not delivered on time	Schedule delay	Brown	Compress the schedule by beginning tasks in the next milestone while working on operating system upgrade

  • 
    Triggers
    Triggers are warning signs or symptoms that a risk event is about to occur. For example, if you've ever suffered from a hay fever attack, you can't mistake the itchy, runny nose and scratchy throat that can come on suddenly and send you into a sneezing frenzy. Signals like this are known as triggers, and they work the same way when you're determining whether a risk event is about to occur. For example, if you're planning an outdoor gathering and rain clouds start rolling in from the north on the morning of the activity, you probably have a risk event waiting to happen. A key team member hinting about job hunting is a warning sign that the person might be thinking of leaving, which in turn can cause schedule delays, increased costs, and so on. This is another example of a trigger.
    Triggers are not listed as one of the risk register elements until the Plan Risk Responses process is carried out, but in practice this is an appropriate time to list them. Also, throughout the remainder of the project, be on the alert for triggers that might signal that a risk event is about to occur.

• Risk report: It provides information on sources of overall project risk, together with summary information on identified individual project risks. It is developed progressively throughout the Project Risk Management process. It also contains results of the Perform Qualitative Risk Analysis, Plan Risk Responses, Implement Risk Responses, and Monitor Risks processes. On completion of the Identify Risks process, the information risk report includes are:
  

  • Sources of overall project risk, indicating that are the most vital drivers of overall project risk exposure.

  • Summary data on known individual project risks, such as the number of identified threats and opportunities, distribution of risks across risk categories, metrics and trends, etc.

Additional data is also enclosed within the risk report, depending on the reporting requirements specified in the risk management plan.

• Project documents updates: For the Identify Risks process, project documents that may be updated include:
  

  • Assumption log: During the Identify Risks process, new assumptions may be made, new constraints may be recognized, and existing assumptions or constraints may be revisited and modified. The assumption log ought to be updated with this new data.

  • Issue log: It ought to be updated to capture any new issues uncovered or changes in presently logged issues.

  • Lessons learned register: It can be updated with information on techniques that were efficient in identifying risks to enhance performance in later phases or other projects.

Knowledge Check