PMI RMP – IDENTIFY RISKS

1. INTRODUCTION

Hi and welcome back again to a new process, a new section of this course. Now, we were done with developing the risk management plan as a part of the previous process plan, risk management. So we planned for the risk on the project. We developed the methodology, we developed the strategy, we defined the risk funding sources, the risk rules and responsibilities, and all these details I explained earlier as a part of the risk management plan. So now we have in our hand the risk management plan. It’s the time to identify the project risks. So it’s the second process out of the seven risk management processes, it’s a part of the planning process group and the risk management knowledge area. Now, the process of identifying individual project risks as well as sources of overall project risks and documenting their characteristics. So in a high level description, identify risks process, it’s the process of identifying individual and overall project risks and documenting these identified risks characteristics. These documentations will be part of the risk register, which will be the primary output of the identified risks process. What’s the key benefit of the risk identification process? It’s the documentation of individual project risks and sources of overall project risks.

It also brings together information so the project team can respond appropriately to the identified risks. So this is the key benefit. We will have a documentation of the individual and overall project risk along with the information and characteristics related to the identified risks. So the efforts and the results of this process all will be documented in the risk register. And the risk register will be the base for all the upcoming efforts in the risk management processes. We are going to analyze subjectively the risks we are identifying in this process. Then we are going to analyze objectively these risks and then we are going to plan for the rest responses, which we already identified in the rest register. This is the importance of the rest register as an output of the identify risks process. This process is performed throughout the project. Yes, it’s part of the planning process group. Yet you can identify the project risks as any part of the project life.

Who are the participants in the risk identification process? Actually, any stakeholder on the project which you believe he or she will add value to the risk identification can be invited to participate in the Identifier risks process. Like the project manager. Usually the project manager will direct the efforts of the risk identification project team members, risk department, project risk specialist, customers, subject matter experts, risk manager, whoever might add value to the risk identification process should be invited to this process. Identifier risk process is an iterative process in nature. It’s iterative sensing your risks may emerge as the project progresses through its life cycle. So it’s an iterative process. You can find out, you can determine risks through any point of the project life cycle. Always the risk will emerge during the project execution or during the project monitoring and controlling phase of the project. Now, what are the critical success factors for the risk identification process? The first and the most important one is the early identification process.

Risk identification should be performed as early as possible in the project lifecycle. Early Identification recognizing the paradise that uncertainty is high in the initial stages of a project so there is often less information on which to base the risk identification. Early identification is a critical success factor to the risk identification process. You need to find out the project risks as early as possible in the project life. And keep in mind, as I explained in the Risk Foundation section that the highest uncertainty, the highest risk on the project is during the initial phases, during the initiating phase of the project due to the high level of uncertainty and the very few information available about the project. Early risk identification enables key project decisions to take maximum into account of risks inherent in the project and bear results in changes to the project strategy.

So this is the core value of an early identification of the project risks. It will enable key project decisions to take maximum account of risks inherent in the project. So the key project decisions will be considering the project risks in case we have an early identification. It also maximizes the time available for development and the implementation of risk responses which enhances efficiency since responses taken early are often normally less costly than later once. So it will maximize the time available for the team to develop and implement the risk responses. We are not just defining the project risks for the purpose of defining them. We need to plan for the risk responses. So when we are having an early identification of rest on the project, we will have available and enough time to develop and implement the risk response plan. In addition to saving costs because of the early identification, the second critical success factor will be the iterative identification.

It shall be repeated throughout the project. Not all risks can be identified at any given point in the project. This is why it’s called an iterative process risk identification. It’s an iterative process in nature. You can identify the project risks at any part of the project life cycle. And if you are applying an agile project, you need to perform the risk identification process before the start of each iteration. The third critical success factor is the emergent identification. The project risk management process should permit risks to be identified any time, not limited to former risk identification process or regular failures. Whenever there is an emergent risk you need to identify, document, analyze and plan a response for this emergent risks number four or critical success factor for you need to perform a comprehensive identification.

Broad range of sources should be considered to ensure that many uncertainties, as many uncertainties as possible that might affect objectives have been identified. You need to look everywhere for the sources of risk. You don’t need to focus on the technical ones or the management ones or the external ones. You need to consider a broad range of sources in order to have a comprehensive risk identification. Consider identification of Opportunities the majority of the risk identification workshops I attended in my practical experience are focusing on the threats. You need to consider both. As long as we have a threat, we have also an opportunity and our efforts we are spending in the risk management are aiming to increase the probability and effect of an opportunity while reducing the probability and effect of the threats.

The identifier risks process should ensure both are considered threats and opportunities. Multiple Perspectives the identifier risks process should take input from a broad range of project stakeholders to ensure that all perspectives are represented and considered. Limiting risk identification to the immediate project team is unlikely to expose all novel risks. So this is what I stated at the starting of this lecture. You need to invite anybody who you believe that he or she will add value to the risk identification process. You need to consider all the perspectives available on the project. You need to invite stakeholders from finance, from engineering, external stakeholders, customers, people on ground. All these people need to be considered in order to apply the multiple perspectives. Critical Success Factor risks should be linked to project objectives.

That’s true from the risk definition. It’s an uncertain event that if it occurs, will affect at least one of the project objectives. So each risk you are identifying and documenting as a part of the risk identification process should be linked at least to one project objective. Each identified project risk should be related to at least one of the project objectives. A complete risk Statement identified risks should be clearly described so that they can be understood by those responsible of risk assessment and risk response planning. We are going to use the coast risk effect format which is called the risk meta language. I’m going to explain in the following slide the aim of this critical success factor that you need to write clear a complete risk statement so anybody from the project, from outside the project, from the risk team can understand exactly the details of this stated risk.

The Ownership and Level of Detail each risk should be described at a level of detail at which it can be assigned to single risk owner with clear responsibility and accountability for its management. So each identified risk on the project will be the responsibility of a risk owner. So who is the risk owner? The person responsible or the person accountable for this risk? He or she needs to monitor the risk trigger and implement the planned response whenever this risk occurs. So the risk owners will be documented, identified, finalized at the planned risk responses process. For now, you need to know that the ownership and the level of detail where this risk is identified as a critical success factor. The last one is the objectivity avoiding biases and minimize the subjectivity while identifying the project risks. You need to avoid biases both types, the motivational and the cognitive one motivational biases are where someone is trying to balance the result in one direction or another.

Why? The cognitive biases are where biases occur as people are using their best judgment and applying heuristics may occur. This should be explicitly recognized and addressed during the identified risk process. So these are the ten success factors you need to consider, you need to take care of while you are applying the risk identification process on your project. So I mentioned at point a complete risk statement using the risk meter language format. So to avoid the confusion in writing the project risks and documenting them direct register, there is a cause risk effect format. What’s the cause? Risk effect Format as a result of a definitive cause, an uncertain event may occur which would lead to an effect. So in this simple statement which is called the risk meter language or the cause risk effect format, you clearly stated the cause of the risk, the risk itself and the effect. An example as a result of lack of clear scope of the hotel lobby part.

So you have a hotel project, an oil construction project and there is a lack of the clear scope of the lobby part of this hotel. So this is the definitive cause, what is the risk or the uncertain event? There could be rework and waste of efforts, so this is the uncertain event, there could be rework and waste of efforts which would delay the project critical path by two weeks. So this is the risk meter language you stated the definitive cause which is the lack of clear scope of the Ottawa P path you mentioned also the uncertain event which is the reward and waste of efforts and the effect which is that the project critical path might be delayed with two weeks. To confirm that this is an effect, as I mentioned earlier, it shall relate to project objectives, project constraints and risk tolerances.

Here is another example of the risk meta language cause risk effects the system backup recovery mechanism may not work. This is the definitive cause, the risk or the uncertain event which could lead to loss of programming codes and this data developed to date and the effect will be the system failure. Now, before we move to the next lecture to the inputs, I just want to give you a high level description of the ITTOs of the Identifiers process. We have a lot of inputs. All the project management plan components, requirements, schedule, cost quality resources and risk subsidiary management plans will be very useful to lock in for new risks on the project. The performance baselines as well, the cost baseline scope and schedule. The three performance baselines you will need also the project documents, the assumption log, the cost estimates, duration estimates, issue log, listens and register requirements, documentation requirements or resources requirements and the stakeholder register. Any signed agreement or contract can be a potential source of the project risk.

This is why it’s an input to this process. In addition to the enterprise environmental factors and the organizational process assets, the tools and techniques as per the project management body of knowledge, the PM book, we have the expert judgment data gathering techniques which are the brainstorming, sessions, checklists and interviews you will use. Also the data analysis techniques, the root cause analysis, assumption and constraint analysis, SWAT analysis and documentation analysis, the interpersonal and team skills, the facilitation, prompt lists and meetings. In addition to these six tools and techniques, I’m going to explain more than seven tools and techniques from the practice standard of rest management.

Like the pre mortem, like the Delphi technique, the affinity diagramming, the force field effect analysis, the force field analysis, the failure mode effect analysis, the influence diagramming diagramming so all these tools and techniques from the project management body of knowledge and from the practice standard, risk management. The practice standard of risk management published by the PMI will be considered in this section. And we have two primary outputs of this process the risk register and the risk report. Keep in mind that the primary output of the Identifier risks process is the risk register.

But you need also to consider that this risk register will be updated as an output of each risk management process on the project. And you need to understand and memorize the risk register updates of each process for the PMI RMB exam. In addition to the risk register and risk report, we will have also few project documents updated like the assumption log, the issue log and the elephant learn registered. This is all as an introduction of the Identifier risks process. Thank you so much. I see at the next length.

2. INPUTS

Hi and welcome back again. So before we start the risk identification process on our project, what are the inputs, what are the documents we need to have in order to start? So what you are going to need for the Identifiers process, we have five inputs only the first one will be the project management plan. As we are identifying risks, you need a lot of sources to consider approved categories of the project risks. So we will need a lot of the subsidiary plan as a part of the project management plan. First of all we will need the requirements management plan as it indicates the project objectives that are particular at risk. So you can study, you can check the requirements management plan in order to find these project objectives. The schedule management plan in order to identify areas that are subject to risk and uncertainty. The same for the cost management plan, the same for the quality and resources management plan.

These four management plans regarding the schedule cost, quality and resources will identify the areas that are subject to uncertainty and where key assumptions have been made that might give rise to arrest. The assumption lock and the assumption of the assumptions actually made in the project are potential to become project risk. This is why we will need the assumption lock as an input to this process. We will need also the risk management plan which was an output of the plan risk management process. The previous one, the risk management plan provides information on how risk related roles and responsibilities. Also it identifies how risk management activities are included in the budget and schedule. So how we are going to identify the project risks, what are the tools and techniques, what’s the method of documenting these risks. All are documented in the risk management plan. We will need also the three performance baselines.

The first one is the scope baseline as it includes deliverables and their criteria for acceptance, some of which might give to rest the deliverables. The product scope, the project scope, the acceptance criteria, all are documented as a part of the scope baseline. The schedule baseline may be reviewed to identify milestones and deliverables due dates that are subject to uncertainty. The cost baseline may be reviewed to identify costs or funding requirements that are subjected to uncertainty. Now we need also few project documents. First of all is the assumption log assumptions recorded may give rise to project risks. We have a separate tool, it’s called assumption and constraint analysis which will be performed as a part of the Identifier risks process. So in order to analyze these assumptions we need to have the assumption log, cost and schedule or duration estimates except usually as a range indicating the degree of risk associated with this estimate.

We will need also the issue log as all the issues recorded may give arise to the project risks. The lessons learn register about risks identified in earlier phases of similar previous projects. The requirements documentation lists the project requirements and allows the deeper identifying those that could be a risk. The resources requirements expressed usually as a range indicating the degree of risk. This is why the resource requirements and estimates cost and schedule estimates are very important as an input to the Identifier risks process as usually all the estimates done on the project are represented or are indicating the degree of risk.

By representing a range of the estimate, the stakeholder register indicates stakeholders who might participate in risk identification also will need the agreements or the contract may have information such as milestones, dates, contract types, hours and penalties that might be threats or opportunities. Agreements, contracts, terms and conditions of these contracts are all potential sources for the project risk identification process. We will need also few enterprise environmental factors and few organizational processes assets about previous and similar projects. These are the five inputs you need to have in order to start the Identifier risks process. Thank you so much. We move now to the tools and techniques.

3. STEPS TO FOLLOW IN RISK IDENTIFICATION

Hi and welcome back again. Now, we are almost done with the Identifiers process. What are the steps exactly? Steps you need to follow in the Identifiers process first of all, you need to collect the historical information of similar projects and the project background information.

Then you need to determine determine who may have insight into risks from all the project stakeholders. You need to determine which risk identification methods, tools and techniques to use and with what groups. Identify risks with others brainstorming, checklists and affinity diagrams. Make a list of all identified risks on a risk registered. Step number six determine with the risk team assistant how confident you are that the major risks have been identified.

Step seven if you are not confident that you have identified all the risks, redo the previous steps. If you are confident, determine whether questions remain and what information is still needed to understand the listed risks. Step eight ask the remaining questions and collect information. Add new risks to the list and eliminate any items identified as not really risk. This is your responsibility as a project manager. Discuss remaining risks as necessary to understand them. Move to the perform qualitative risk analysis process. These are the steps you need to follow while identifying the project risks at a high level. Thank you so much. I will see you at the next lecture.

4. SUMMARY

Hi and welcome back again. So, as a summary of the Identifier risks process. The objective of the Identifier risks process is to divide the longest list of risks possible using a combination of tools, techniques and methods to prevent three work. Be prepared with historical and project background information before you begin to identify the project risks.

Everyone, including all stakeholders, should be involved in identify risk process. Risks should be identified in all relevant risk categories and perspectives. Remember to identify opportunities as well as threats. In most of the risk identification workshops I attended in my practical experience, the majority of the stakeholders will focus on the threats. You need to consider both threats and opportunities.

And for the Primp exam, you need to be aware of all these terms identify risks process, risk categories, codes, risk effect format, root cause forms, checklist picking notes, brainstorming, pre mortem, affinity diagrams, expert interviews, nominal group techniques, delphi techniques, complex code and effect diagram, failure mode, effect analysis, four speed analysis, swap analysis and direct registers. This is all for the Identifier process. Now we will have a quiz of 15 questions in order to test your understanding of that process. Thank you so much. I will see you after the call.