PMI RMP – RISK MANAGEMENT FOUNDATIONS Part 2

6. GENERAL INPUTS TO RISK MANAGEMENT

Hi and welcome back again. So what are the general inputs you need to have before we start performing the risk management activities on the project? Now, for the upcoming seven risk management processes I’m going to explain in this section I will go through the inputs, tools and techniques and the outputs of each one of them. But the ten inputs I’m going to explain right now are the general ones that you need to have before you start the first risk management process.

I would be starting with the project background information as from the name it’s the background data and information and reports about the project. It’s the information such as the correspondence from before the project was approved, any emails, any communications, articles written about similar projects and other such information. It will help you identify risks. So the first general input is the project background information you need. Also the project charter, it’s the high level from management, high level documents from management. It will outline the overall project objectives. It will authorize the existence of the project. It gives the project manager the authority needed to complete the project. The project charter is the first document produced on the project as an output of the developed project charter process.

The project charter includes the project description, high level requirements, high level risks. This is why the project charter will be a useful input when it comes to planning for risk management on the project. The third input is the stakeholder register, which is an output of the identify stakeholders process. Stakeholders are individuals and organizations who are actively involved in the project or may affect or be affected by the project. This documents updated through the project stakeholders will contribute and risk identification on the process through the meetings, interviews, brainstorming sessions and so on. Now to know to home stakeholders, you need to communicate, you need to invite, you need to have the stakeholder register listing all the project stakeholders who you need to communicate with. The fourth input is the project scope statement.

The project scope statement is the approved project and product scope of the project. Now, to perform the project risk management, it’s important to have a finalized project scope statement that describes the complexity of the project. It also includes information about the project constraints and assumptions. The project scope statement is an output of the defined scope process as a part of the scope management knowledge area and it’s a part of the scope baseline. When it comes to risk management, the project scope statement is an important input because it includes the constraints and the assumptions. Constraints and assumptions are potential source for risk identification. A project constraint is anything that limits the team options.

The assumptions are things that are expected as true, but they may not be true. Project assumptions may increase or decrease the risks and help in determining risk impacts on the project. The fifth input is the wood breakdown structure. The WBS it decomposes the project into smaller, more manageable pieces, the lowest level in the hierarchy of the WBS. It’s called the work packages. Those work packages then are managed by the project manager. The project scope statement with the work breakdown structure and the work breakdown structure dictionary. All are within the scope baseline of the project. The work breakdown structure is the simplest way to have a visual look on all the activities and the work packages will be performed throughout the project.

So it will be a very useful tool when planning for risk on the project. We have also the resources plan, which is a formal plan identifying when and how the team and other stakeholders will be involved in the project and what roles they will perform. Number seven, and for me the most important one is the network diagram. It’s a dependency sequenced organization of the project’s activities. These activities are derived from the decomposition of work packages in the work breakdown structure. Now, when it comes to risk management and when you want to evaluate risks, you need to look at the network diagram for first of all the critical path, the path convergence, the path divergence and the near critical paths. I’m going to explain all these concepts in the critical path lecture of the math section in this course. Here’s an example for project network program with fixed processes.

It’s a virtual representation of all the project activities sequenced as per the relationships between the activities. Activity four cannot start before the completion of activity two. So this is a finish to start relationship. Activities four and five must be completed before activity six can start. Now the critical path is the shortest path to complete the project and all activities on the critical path have a zero float, they have no flow. This is why the critical path is important to define the project risks. Wherever there are two activities leading into one activity, this is the path convergence. This activity is riskier as activity sex will depend on activities four and five, not only on one activity in two activities. So this is the path convergence when two activities are leading into one activity and this is the path divergence when one activity is leading into two activities.

So the critical path, path convergence and path divergence are the reasons why we will lock on the network background while the risk identification process is going. Number eight. We have the procurement management plan. It’s a formal or informal plan for a project that describes what parts of the project will be purchased under contract or purchase order. It also includes a plan for managing sellers on the project. Relationships with the suppliers, contractors, third parties are all potential in order to identify the project risks.

This is why we need the procurement management plan. And for sure you will gain benefits, a lot of benefits of using the Listen language register from previous projects that document what went right, what went wrong or what would have been done differently by past project teams if they could execute their projects again. So listens, learn can help identify and manage risks on your project. Finally, we have the organizational process assets. Organizational process assets mean the company policies, procedures, processes templates. So if the company has any templates regarding risk management, you need to search out these templates as a part of the organizational process assets. These are the general inputs to the risk management. Thank you so much. I’ll see you at the next lecture.

7. RISK MANAGEMENT PROCESSES

Hi and welcome back again. So in this lecture I’m going to give you a highlevel description about the seven risk management processes. We are going to explain end to this course sections. So even the most carefully planned projects can run into trouble. No matter how you will plan, your project can run into unexpected expected problems. This is the nature of the project. Either your project is a construction project, software development, web design or whatever your project is. All the projects can run into unexpected problems. A team member on your project might get sick or might resign or quit. Resources you are depending on turn out to be not available.

Even the weather can throw you into a loop. So that just means you are helpless against unknown problems. Unknown problems are risks which we are going to plan through the risk management seven processes. You can use risk planning to identify potential problems that could cause trouble for your project. So the first step is to plan to identify the risks. Then you are going to analyze how likely they will be to occur. Take action to prevent risks you can avoid and minimize the ones you can’t.

So this is in a high level description what we are going to do in the 17 processes. First of all, we are going to plan for the risk, identify the risks, analyze and then plan the responses. The first process is the plan risk Management as a part of the planning process group. It’s the process of defining how you will conduct risk management activities for your project. This is the plan risk Management. We will think in advance how we are going to deal with any activity related to the risks on the project. It’s part of the planning process group and it’s the first process you are going to perform in the risk management knowledge area. Once you develop the risk management plan, it’s the time to identify the project risks so you would perform identify risks.

It’s the process of identifying individual project risks as well as sources of the overall project risks. We will have the primary output of this process, the risk register. Then you are going to take all the risks identified in the risk register and analyze them at the perform qualitative risk analysis or perform subjective risk analysis. It’s the process of prioritizing individual project risks for further analysis or action by assessing their probability of occurrence and impact as well as other characteristics. So we planned for the risk, we identified all the risks on the project. We performed subjective analysis to prioritize the project risk. Now it’s the time to perform an advanced quantitative or numerical risk analysis. It’s the process of numerically analyzing the combined effect of individual project risks and other sources of uncertainty on the overall project objectives.

So this is the subjective analysis of the identified risks and this is the objective analysis of the identified risks. The fifth process is the planned risk responses. It’s the process of developing options, selecting strategies and agreeing on actions to address the overall project threat exposure as well as to treat individual project risks. So we identified, we analyzed it’s the time to plan for the responses we want to minimize, to reduce the impact of the overall project threats and increase the probability or the impact of the project opportunities. All this will be done as a part of the plan risk response to the process. Here are a few examples of the strategies. You have the risk of failure from here. So simply you can just avoid, go away, walk away. This is the avoidance risk strategy.

You can mitigate the impact of the failure, you can transfer the risk, just pay for somebody to stand up here instead of you, or you can just accept the failure as it is. These are four strategies you can deal with while planning for risk responses for the threats. I’m going to explain all these strategies in detail. We have five strategies to deal with threats, five strategies to deal with opportunities. These are the five planning processes for the risk management. It’s the time to implement the planned risk responses and the implement risk responses process.

As a part of the executing process group and as a part of the monitoring and controlling process group, we have monitor risks. It’s the process of monitoring the implementation of agreed upon risk response plans. We’re going also to track the identified risks, identify and analyze the new risks and evaluate risk process effectiveness throughout the project. These are the seven risk management processes. I’m going to explain each of them in a dedicated section. We will discuss the ITTOs. The critical factors for success is we are going to solve more than ten or 15 questions about each process. Thank you so much. I will see you at the next lecture.

8. TRENDS AND EMERGING PRACTICES IN RISK MANAGEMENT

Hi and welcome back again. So before we end the section I want to talk about few trends and emerging practices. As per the PM book, the Project Management Body of Knowledge, the focus on risk management is to ensure that all types of risks are considered. Trends and emerging practices for project risk management includes first of all, you need to consider the non event risks. Most projects focus only on risks that are uncertain future events that may or may not occur. You need to think out of the box and think about the nonevent risks. There is an increasing recognition that nonevent risks need to be identified and managed.

There are two main types of non event risks. The first one is the variability risks. Uncertainty exists about some key characteristics of a planned event or activity or decision. The second tie is the ambiguity risks. Uncertainty exists about what might happen in the future areas of the project where imperfect knowledge might affect the project’s ability to achieve its objectives. So you need to think and consider the nonevent risks both sides the variability risks and the ambiguity risks. The second trend is the project resonance.

The existence of emergent risk is becoming clear with a growing awareness of so called unknowable unknowns. There are risks that can be only recognized after they have occurred. I will talk more about the unknown unknowns and the plant risk responses process. There are risks which cannot be identified and you need to just find a workaround to deal with.

Emergent risks can be tackled through developing project resolutions which requires each project to have first of all, the right level of budget and schedule contingency for emergent risks. Flexible project processes that can cope with emergent risk while maintaining overall direction towards project goals empowered project team frequent review of early warning signs to identify emerging risks as early as possible clear input from stakeholders to clarify areas where the project scope or strategy can be adjusted in response to emergent risks.

So what are the emergent risks? They are risks that you cannot get, you cannot identify, you cannot think about and advance. They just happen. Now, in order to control more the emergent risks you need to have these five points. We have also the integrated risk management as the project exists in an organization context and they may form a part program or portfolio. Risk exists at each of these levels and risks should be owned and managed at the appropriate level. Some risks identified at higher levels will be delegated to the project team for management and some project risks may be escalated to higher levels if they are best managed outside the project. There is one risk response strategy called Escalation which I’m going to explain. In the planned risk responses process when the risk falls in an area which is outside the project manager authority, then the risk just need to be escalated. This is all for the trends and emerging practices and risk management. Thank you so much. I’ll see you at the next lecture.

9. TAILORING AND AGILE CONSIDERATIONS

Hi and welcome back again. So what are the tailoring considerations when it comes to risk management and why? I need to tailor the risk management practices and policies on my project? Because each project is unique. This is the nature of the project. Who is responsible to tailor the project manager need to tailor the way the project risk management is applied. We have four major considerations you need to think about when tailoring risk management. The first one is the project size. Does the project size in terms of budget, duration, scope or team size require a more detailed approach to risk management? Or it’s small enough to justify a simplified risk process? It’s the risk manager and the project manager responsibility to determine and to have a proportionate relationship between the risk management efforts and the project size.

Then you need to think and consider the project complexity. Does the project includes high levels of innovation and new technology or external dependencies that increase project complexity? Or the project is simple enough that reduced risk process will be sufficient. So also you need to consider if your project is a simple one, recurring one, or your project is a state of art or one of kind or innovation. So this will affect the risk management activities on your project, the project important. And when I see the project importance, I mean the importance of the project to the organization running this project. How strategically is the project important for the organization? And what’s the development approach you are applying? Are you following a waterfall or traditional project life cycle?

Or you are following an adaptive agile life cycle in a waterfall project where risk processes can be followed sequentially and iteratively or does the project follow an agile approach where risk is addressed at the start or before the start of each iteration as well as during execution? So the development approach will affect your risk management activities and the frequency of the risk management processes on your project. So these are the four tailoring considerations and when it comes to an agile environment, the agile environment or the agile project’s nature includes high variability and it includes more uncertainty and risk.

Now to address this project managed by adaptive approaches, make use of frequent reviews of incremental work products. When I say an incremental work product at the end of each iteration in an agile project, you will have an increment which is part of a feature of the working product and the cross functional project teams to accelerate knowledge sharing and ensure risk is managed closely. Cross functional project teams it’s a commonly used term in agile project. When I say that I have a team of five persons, five people, it’s a cross functional team. It means that each person from this team represents a function, might be a programming function, an engineering function, and It function, a financial function, might be. But this is the cross functional project team. Risk is considered when selecting the content of each iteration and risks will also be identified, analyzed and managed during each iteration and the requirements are kept as a library document that is updated on regular basis and work may be reprioritized as the project progresses based on an improved understanding of the current risk exposure. This is what you need to think about for the agile environment. And this is all for this lecture. Thank you so much. I will see you at the next lecture.