Cause and Effect Diagrams

Cause and Effect diagrams, also known as Ishikawa diagrams or fish-bone diagrams are one of the most commonly used diagramming methods in project management, quality management and risk management. So, if you have decent project management experience/exposure you would’ve seen or used this diagram invariably.

So, what are these Cause & Effect diagrams? These are diagrams that we can use to identify the causes of risks. If you can identify the cause you can not only arrive at a better solution, but also identify other related risks that may go undetected if you did not investigate thoroughly. The purpose may be similar to the root cause analysis technique but it is slightly different. As I said just a few lines ago, if you are a PMP or have been a Project Manager for a while, you would’ve most probably seen this. This and other techniques commonly referred to as the “7 basic tools of quality” are all covered in the “Perform Quality Control” chapter of the PMBOK. We had covered that process in the chapter on Controlling Quality in our PMP exam prep series. You can Click Here to visit that chapter.

If you see the first line of this chapter, I have used 3 different names for this diagram. Frankly speaking they all refer to the same thing but for different reasons. Like:

a. Cause & Effect diagram – As we are attempting to get to the cause of the issue we call it so
b. Ishikawa Diagram – This name is in honor of the gentleman who created this diagram Mr. Kaoru Ishikawa
c. Fishbone Diagram – This name is because it looks like a fish bone.

The diagram shows how various factors may be connected to a potential problem or effect. In our case from a risk management perspective, we will be looking at all the contributing factors to a risk.

Look at the diagram below:



It looks like a tree structure where we are looking to identify or locate the root of the problem. The original problem is on the right hand side and we have identified 4 main causes. Within each cause we have identified a number of sub-causes. As we dig deeper we will be able to narrow down to the heart of the problem.

However, I repeat, all this is from a risk perspective and the problem on the right hand side will usually be a risk and we are breaking down all the causes of that risk using this fish-bone/ishikawa/cause & effect diagram.

Remember that you don’t need to be an expert in all these diagramming methods in order to pass the RMP Examination. But, you need have a good understanding of these topics in order to answer the questions that may be covering these topics.

Prev: Checklist & Assumptions analysis

Next: Process Flowcharts

Checklist and Assumptions Analysis

In the previous chapter we learnt about the Information Gathering Techniques to identify the potential risks in your project. In this chapter, we are going to take a look at two more tools & techniques you can use to identify risks. They are:
a. Checklist Analysis
b. Assumptions Analysis

Checklist Analysis

Checklist Analysis, as the name suggests deals with creating risk checklists in your project. These lists can be simple short lists or lengthy comprehensive lists. We will use these checklists to ensure that all potential categories and areas of our project are explored. Simply put, the checklist will contain all those categories that can be sources of potential risks and by striking them off one by one, we can ensure that we have covered all areas and ensure a complete/thorough investigation.

If you do not have the time or the resources to create a separate checklist as such, the lowest level of the Risk Breakdown Structure (RBS) can be utilized as a checklist. Do you remember that I said that the RBS can be used during the risk identification process in our previous chapter? By ensuring that every single item in the lowest level of a detailed/well created RBS can help us cover all possible sources of risks for our project.

As a project manager, when you sit down to identify risks for your project, it may look like a daunting task because there is so much information to understand and analyze. In such situations if you use a checklist, it can not only make your job easier, but also ensure that our analysis is thorough. In this stage, practically speaking we are combing through every single area of our project looking for risks. Checklists can help us confirm that we have looked into everything.

If your organization follows sound project management practices, you are sure to find risk checklists from other previous projects that were similar to yours. You can use that as a template or a baseline to create a custom checklist that will be comprehensive and better suited to your project’s needs.

Trivia:

Many companies/managers do not archive project documents or lessons learned. This is an incorrect project management practice. The whole purpose of this exercise of archiving project documents is to help our future generations to learn from our mistakes and if we don’t document them, it is possible that other projects are going to repeat the exact same mistakes over and over again causing delays and losses to the organization as such.

If you are in an organization where people don’t follow such good project management practices, bring this to the attention of your senior management or PMO and lead by example. Do it for your project and help others understand the importance and usefulness of this activity.

Assumptions Analysis

Assumptions analysis, as the name suggests is the technique where we are going to systematically analyze all the assumptions in our project. We are going to check if each of those assumptions is valid. If an assumption is inaccurate or inconsistent or incomplete, it can be a source of risk.

For ex: let us say you are constructing a house and you need the concrete mixer machine to lay the roof of your home. As per your schedule plan, the roof has to be laid 6 weeks from now and you have called up the company that leases out the mixer and blocked the dates. Based on this, you have made up the further schedule on constructing the first floor of your house. Here, you are making an assumption that the mixer will be available on time and will be fully functional in order for your scheduled construction of the first floor is to proceed. Isn’t it?

What if the company goes bankrupt just few days before our scheduled roofing plan? Or what if the mixer breaks down as soon as it reaches our construction site? These are all some issues that could affect us because of the assumption we made about the availability of the concrete mixer. Isn’t it?

This is exactly what we are going to try and identify during this assumption analysis.

Where will we look for all these assumptions? – The Project Scope statement & the Project Plan would have listed down all the assumptions that are relevant to the current project.

Prev: Information Gathering Techniques

Next: Cause and Effect diagrams

Information Gathering Techniques

In the previous chapter, we saw one of the techniques used to identify project risks namely the “Documentation Review”. As outlined in the chapter on “Overview of Tools & Techniques used in Risk Identification” there are several other tools & techniques that we will utilize in this risk identification step. In this chapter we are going to take a detailed look at “Information Gathering Techniques”

Information Gathering Techniques

The information gathering techniques are involves utilizing techniques that predominantly revolve around interacting with experts and trying to gather as much data as possible about the potential risks that may affect our project. The information gathering techniques we can utilize are:

1. Brainstorming
2. Delphi Technique
3. Interviewing
4. Root Cause Analysis
5. Expert Judgment

Trivia:

Are you wondering why I have added “Expert Judgment” as an entry in the Information Gathering Techniques chapter when it was also part of the superset list of techniques used to identify risks??

The answer is simple. Expert judgment is utilized in almost every management activity we might end up doing on our project. In this case, the techniques like Delphi or interviewing etc. need a certain amount of expert judgment in order to be fully successful. That is why it is added here as a separate entity.

Before we go any further to discuss these techniques in detail, we need to know the participants, the “Who” part of these techniques. If you ask a project manager this question, his answer would most probably be “Everyone” and if so, his answer is almost correct. This is because the list of people who are involved in these information gathering activities include almost everyone that you can possibly think of. It includes:

1. The Project Manager
2. Project Team
3. Risk Management Team (If a separate team exists for risk management)
4. Customers
5. Stakeholders
6. End Users
7. Subject Matter Experts
8. Risk Management Experts
9. Other Project Managers

The people in points 7, 8 & 9 are usually not part of our team. An experienced project manager will identify such key people who can contribute greatly to the projects risk management effort and invite them for these activities to make use of their expertise and experience.

Now let us take a detailed look at each of these techniques…

Brainstorming:

Brainstorming typically involves a large group of people who get together solely for some purpose (Here it is Risk Identification) and share their individual ideas and suggestions under the topic of discussion. In this case, the outcome of a brainstorming session could be a comprehensive list of all possible project risks. Brainstorming sessions are typically led by a facilitator (To ensure focus on the topic & decorum) and may also involve experts from outside the team as required.

There are two ways in which these brainstorming sessions can be held:
1. Large Group Technique – Here a large group gets together and it is a free for all kind of scenario.
2. Nominal Group Technique – Here, smaller sessions are held first at different times and then the outputs are reviewed/discussed in a larger meeting.

An important point about this technique is that, the meeting/gathering should use the Risk Categorization standards as well as the RBS in order to identify risks effectively. As and when risks are identified, the group usually categorizes them as well.

Delphi Technique:

The Delphi Technique is almost similar to the Brainstorming technique but with a few major differences:
1. We will utilize experts instead of the everyone
2. Experts share their feedback/suggestions anonymously to the facilitator
3. The facilitator summarizes the responses and re-distributes it to all the experts
4. This cycle is repeated until a consensus is reached

Trivia:

Are you wondering why do experts have to respond anonymously? Well think of it this way; let’s say you are attending a brainstorming meeting where the Director of your department too is a participant. As the technical architect of your team, you are an expert and your ideas have a lot of weight with the project manager. So, you have an idea and share it with the group but your director thinks that this idea will not work and your project manager agrees instantaneously because he is the “BOSS”. Now, go back and ask yourself the same question “Why do experts need to respond anonymously?”

An important point to note here about this Delphi technique is that, we will be utilizing the expertise of only those people who are experts in Risk Management.

Interviewing:

Well, this is probably the simplest of the information gathering techniques and is probably self-explanatory as well. Anyways, for the sake of completeness, this technique involves interviewing subject matter experts (SMEs), stakeholders and other experienced project participants with the purpose of generating risk related ideas. An important point to note about this technique is that, this is one of the primary sources of risk identification data.

Root Cause Analysis:

As with the interviewing technique, this root cause analysis technique too is straight forward and you might already know about it. This technique involves:
a. Identifying an issue
b. Determining the underlying cause (to figure out why it is happening) and
c. Develop preventive measures (to ensure that it does not happen)

Easy isn’t it? This technique attempts to address the real problem to find “Why” a risk exists. Instead of just responding to the risk, we are trying to figure out the root cause of the risk and address that directly so that, not only this risk but also others that may exist due to this cause are all taken care of in one go.

Expert Judgment:

Expert judgment is an indispensible asset for any good manager and that is why we are talking about it as a separate entity even though it is utilized in almost every risk related activity we do. There is truckloads of knowledge and expertise around us and it is our responsibility to learn all that from those experts and utilize their expertise. So, as a subset of Information gathering, expert judgment involves talking to the experts and getting their opinion/feedback. As a project manager we must invite selected experts who have already participated in similar projects and can be a valuable addition to this exercise. But, the PM must ensure that he considers the experts bias before accepting their views. For ex: some experts may prefer doing certain things the way they are comfortable with, even if there are better/faster ways of doing the same thing. In such cases, the PM (You & Me) must take the judgment call and choose what is best for the project.

Prev: Documentation Reviews

Next: Checklist & Assumptions Analysis

Documentation Reviews

In the previous chapter, we saw all the tools & techniques that we will be using in this “Identify Risks” process at a very high level. In this chapter we are going to take a detailed look at the first item in that list “Documentation Reviews”

What are Documentation Reviews?

This technique looks at all the project plans & documents and performs a structured review to determine the following:

1. Are all the plans consistent with the Project Requirements?
2. What are the assumptions made within those plans?
3. Are the Plans thorough? – Do they cover everything that they should?
4. Do plans even exist?

As you must have figured out by now, the answers to these questions are indicative of the risks that are just waiting to happen.

Examples:

If the Quality Management Plan for the project is missing, imagine how poor the quality of the project outcome will be and how many risks we will be forced to face because of it? (For point no. 4)

If the plans are not consistent with the project requirements imagine how many problems we will face? Let say as per the customer requirement the product must be available for use on or before the 1st of January 2013 and as per our plan, the project is going to complete only on the 15th of January 2013. Isn’t that a ticking time bomb just waiting to explode? (For point no. 1)

The point on Assumptions is a no-brainer. Any assumption is an inherent risk that will occur if our assumption turns out to be false. If I assume that you will be coming to office tomorrow and have planned to get some work done by you, it is a risk I am taking. What if you don’t show up to work due to some reason?

Experts say that most projects that fail, fail due to lack of proper planning. This essentially means that our project failed due to poor Risk Management. Are you wondering why???

If Risk Management had been conducted in a proper way, all those gaps in planning would’ve been identified and we would’ve taken steps to fill those gaps and push the project towards success. So, it is safe to say that the success or failure of a project can be directly attributed to how effectively risks are managed by the project manager.

Prev: Overview of Tools & Techniques in risk identification

Next: Information Gathering Techniques

Overview of the Tools & Techniques used in Risk Identification

In the previous chapter, we took a very detailed look at all the inputs that we are going to use in the Identify risks process. Now we have all the information we need to proceed further. Logically speaking the next step would be to do something with all the information we gathered in the previous step in order to identify the risks that may affect us. Isn’t it?

The technical term for this “Do Something” is “Use some Tools and Apply some Techniques” on those inputs. There are a total of 7 Tools & Techniques that we will be using in order to identify the list of all potential risks in our project by using the inputs we collected in the previous chapter. They are:

1. Documentation Review
2. Information Gathering Techniques
3. Checklist Analysis
4. Assumptions Analysis
5. Diagramming Techniques
6. SWOT Analysis and
7. Expert Judgment

Expert Judgment is one tool or technique that I can’t possibly explain here because it depends on the expert judgment of the person doing the risk identification. So, I will only be covering all the remaining techniques.

Some of these tools & techniques have sub-items as well.

Information Gathering includes:

a. Brainstorming
b. Delphi Technique
c. Interviewing and
d. Root Cause Analysis

Diagramming Techniques include:

a. Cause & Effect Diagrams
b. System/Process flowcharts
c. Influence Diagrams
d. Etc.

To remind us all of the goal or purpose of this whole exercise, the output of this “Application of Tools & Techniques” on the “Inputs” identified in the previous chapter is to “Create the Risk Register” which will be the master list of all possible risks that can affect our project. This register will be updated in all the subsequent process of risk management. Remember the Risk Register Update Cycle?

Identifying all potential risks is not an easy process and requires a lot of time and dedicated effort along with sound understanding of risk management processes. If I start explaining all these tools & techniques in this chapter, it will be too lengthy. So, let us take a look at each of these tools one by one in the subsequent chapters.

Prev: Inputs used in Risk Identification

Next: Documentation Reviews

Inputs Used in the Risks Identification Process

The Identify Risks process is all about figuring out all possible uncertainties or problem areas that may come to bite us in future. So, to ensure that we figure out all possible problems we need to look at a variety of project related areas. All these put together are known as the “Inputs” to the Risk Identification process.

Inputs Used in the Identify Risks process

We have successfully entered the Identify Risks process. This is where we are going to take a look at all possible inputs that can help us identify all possible risks that may affect us. We will be looking at every nook and cranny of our project to uncover as many risks as possible.

Trivia:

The 4th edition of the PMBOK Guide is the latest and we will be using the same in all our studies. If you have an older version of the PMBOK guide, the names of the processes or the inputs/outputs may be different. As both the exam as well as this blog is based on the 4th edition of the PMBOK guide, I suggest you upgrade to the same. If you are a PMI Member a soft copy of the 4th edition is available for download as a member benefit. Alternately you can even order a paper-back copy from PMI website or Amazon.

The following are the items that we will need while Identifying Risks:

1. Enterprise Environmental Factors
2. Organizational Process Assets
3. Risk Management Plan
4. The following documents/plans from the Project Management Plan

a. Cost Management Plan
b. Scheduled Management Plan
c. Quality Management Plan
d. Scope Baseline

5. Activity Cost Estimates
6. Activity Duration Estimates
7. Stakeholder Register
8. Other Project Documents like

a. Work Performance Reports
b. Earned Value Reports
c. Assumptions Log
d. Baselines
e. Network Diagrams
f. Etc.

As we saw in the chapter on “Managing Uncertainty” Uncertainties are sources of risks and they can exist anywhere in our project. The list above is basically a “Where” we will be looking for all those uncertainties that exist in our project so that we can address them appropriately. Let us now take a detailed look at each of these items.

A word of Caution:

It is never a good idea to memorize stuff blindly, esp. for certifications like the RMP that test our practical knowledge and understanding of Project Risk Management concepts. So, take your time, read and understand what each item is and why it is used. This way you will not only be a better risk manager, but also eliminating the need to memorize stuff.

1. Enterprise Environmental Factors

We have learnt what these enterprise environmental factors are many times in this blog. The factors that are relevant in our identifying risks area are:
a. Commercial Databases
b. Public & Industry studies

2. Organizational Process Assets

These again have been covered many times. The organizational process assets include files & data from previous projects. We can study what the actual risks were, the responses that we used and the actual outcomes of the responses. We can utilize this information to ensure that we do not commit the same mistakes as our predecessors. Looking at the lessons learned documents from previous similar projects would be a good idea too. Document Templates also come under this section.

3. Risk Management Plan

As you may have guessed correctly by now, the risk management plan comes as an input to every risk management process in our project that happens after it is created. As this document explains how risk management activities are to be carried out in our project, it is an indispensable resource. We will be using the following from the risk management plan:
a. Assignment of Roles & Responsibilities
b. Budget and Schedule provisions & allocations to Risk Management activities
c. Risk Breakdown Structure


4. Artifacts from the Project Management Plan

The following artifacts from the Project Management Plan will be useful for us in this step. An important point here is that, you need not remember all intricate details about these processes like inputs, tools & techniques, outputs etc. (like what we were forced to remember for the PMP Exam). But, you need to understand these items in detail to ensure that you are able to correlate all those areas from these artifacts that can contribute to the projects risk management area.

a. Scope Baseline

The scope baseline includes the Project Scope Statement along with any constraints & assumptions. As you might already know, wherever assumptions are involved, there are bound to be uncertainties and it is these uncertainties that we are looking for. Also, constraints can be a major source of risks.

The scope baseline contains a key artifact that will be very useful for us from a Risk Management perspective. If you have already done your PMP you must have guessed this by now…

“Work Breakdown Structure”

A Work Breakdown Structure is going to give us a detailed perspective of the project work that will be done including tasks and sub-tasks. By going through this WBS thoroughly we can uncover a lot of potential risk possibilities.

b. Cost Management Plan

The Estimating Costs and Determining Budgets process of Project Planning creates the Projects Cost Baseline or in other words the Project Budget. The approach used in managing the project costs can be a major source of risks. For ex: a project that is operating on a tight budget with little room for maneuvering has a great risk of cost overruns. On the other hand, if the project has good cost reserves planned already, then the risks go down accordingly.

c. Schedule Management Plan

The Develop Project Schedule process creates the Project Schedule. By understanding the Projects Schedule and the Schedule Management Plan will give us a good idea of whether the project is operating on tight deadlines or has any slack in terms of completion dates. As in the case of Projects Budget, projects operating on a tight schedule can have a great deal of risk in terms of schedule overruns.

d. Quality Management Plan

The approach to quality management in the project has a direct bearing on the project risks. A Project where a great deal of importance is given to quality related activities to produce a good quality work product usually has lower risks when compared to one that does not follow good quality practices. In cases where the quality or work done is compromised (for whatever reason it may be), risks are introduced.

Poor Quality Standards is a major source of risks in many projects. If we address the Quality aspect of our project, we will be eliminating a good number of risks at its source.


5. Activity Cost Estimates

The Cost Estimates are created in the Estimating Costs process and these estimates can give us a good idea of the likely cost involved in all the scheduled project activities. This way we can identify if the project is in any danger of cost overruns.

6. Activity Duration Estimates

The activity duration estimates are created in the Estimate Activity Duration process. The quality and accuracy of the estimates can have a direct impact on the risks. If the estimate is accurate then the risks of schedule overruns are low whereas if the estimates are rough or ball-park then the chances of schedule slippages are pretty high which in turn means high risk.

7. Stakeholder Register

The stakeholder register gives us details about the list of all people who have a stake in our project. We can use it to identify the high influence group of stakeholders and handle them accordingly. We can also use this document to invite all those important stakeholders to the risk related meetings to ensure that everyone is on the same page.

8. Other Project Documents

There are a whole bunch of other project related documents that can be sources of risks or risk related information. Some of them are:

a. Work Performance Reports – The output of the Direct and Manage Project Execution process
b. Earned Value Reports – The output of the Measure Project Performance process
c. Assumption logs
d. Baselines (Cost, Schedule and Scope)
e. Network Diagrams – Created during the Develop Project Schedule process
f. Etc.

If you see closely, the scope baseline was considered as a separate input entity just a few paragraphs ago and has been mentioned again as part of the general term “Baselines” along with the Cost and Schedule baseline. Also, the Schedule Management Plan & the Cost Management Plan were covered already as inputs in detail and their baselines are considered here. This should give you a fair idea of the fact that the golden triangle “Scope-Time-Cost” are the key sources of risks for the Project and need to be investigated & analyzed thoroughly in order to minimize risks and to enhance the chances of the Project’s Success.

Apart from all the above mentioned inputs, any other document or information related to the Project that can be a source of risk or that can provide insights that will help in project risk management can be considered as input to this process.

Prev: Intro to Risk Identification

Next: Tools & Techniques used in Risk Identification

Introduction to Risk Identification

In the previous section, we took a detailed look at the “Risk Register”. But, if you had read the section carefully you could’ve spotted one gaping hole. Can you guess what it was?

Though we covered details like what a Risk Register is, what it contains etc. we never touched upon the topic of how we actually create the risk register. Isn’t it?

Well, if you spotted that then give yourselves a pat in the back, “Good Job”. If you missed it, then its ok. We have just begun our journey to be experts in Project Risk Management. So, its ok. Mistakes do happen…

Coming back to topic, the whole idea behind leaving out the “How to Create” part of the risk register was intentional. The Risk Register in itself as I have repeated time and again is one of the key aspects of Project Risk Management. A well-defined and comprehensive risk register is paramount for successful risk management in our project. So, I left out the create part on purpose so that we can take a detailed look at it in future.

In this section, we are going to cover in detail the “Identify Risks” process. We are going dig deep into this topic and learn about the inputs we will use to identify project risks, the techniques we will use to process those inputs in order to uncover all those potential risks that may affect our project. The output of this whole exercise or should I say section will be the “Risk Register”. A good risk register will outline or list down all possible risks that may affect the project no matter how big or small the risk impact will be. Our job here is to just identify all possible risks. We are not going to analyze them in detail here. That is what the subsequent sections on Qualitative and Quantitative risk analysis are for.

Without further delays, shall we get right down to business? The next chapter is going to be a detailed look at all the inputs we will be utilizing during the risk identification process.

Prev: Section Summary - Risk Register

Next: Inputs to Risk Identification

Section Summary – The Risk Register

In the previous two chapters, we took a detailed look at one of the key documents that is created/updated throughout project risk management “The Risk Register”. Let us now quickly summarize what we have learnt so far about the risk register.

• The risk register contains the list of all risks that have been identified as well as its details like description, owner, category, root cause, probability & impact etc
• The risk register is an input to 4 of the 6 risk management processes and an output of 5 of the 6 risk management processes, making it the document that is going to contain the most up-to-date information reg. all the project risks
• The risk register is created in the Identify Risks process and is updated in all the other processes
• The risk register contains the up-to-date status information of all the risks including who is responsible for it, the proposed response, the owner of the risk, the actual outcome etc
• Not all risks are analyzed in the quantitative risk analysis phase. Only those risks that are selected as “Requiring further analysis” in the qualitative analysis phase are analyzed in this phase
• A watch list has to be constantly monitored to ensure that those lower priority risks don’t become near-term threats
• Updating the actual outcomes (even if they are failures) can help us in the future. It can also help other project managers who may work on similar projects in our organization.

Prev: Contents of the Risk Register

Next: Intro to Identify Risks

Contents of the Risk Register

In the previous chapter we learnt that the risk register is going to be constantly updated as we progress through the various processes in the Risk Management knowledge area. From the RMP exam perspective we will be using a term called the “Risk Register Update Cycle” which refers to how the risk register is going to get updated right from the moment it gets created in the “Identify Risks” process to the last process in risk management “Monitor & Control Risks”

The Risk Register Update Cycle is illustrated in the picture below:



If you are preparing for the RMP Certification, it would be a good idea to print out this picture and keep it handy because this is going to give you a high level idea of the overall risk management activities in your project. More importantly, understanding this whole cycle is vital in understanding the subsequent chapters in our RMP preparation series.

Let us now take a detailed look at the various stages in this Risk Register Update Cycle.

1. Identify Risks

Identify Risks is the risk management process that actually creates the Risk Register. When we create the risk register, the following initial/basic information is available:

a. List of identified risks with their description, owner, consequences if the risks were to occur
b. Root causes of risks
c. Potential risk responses

A point to note here is that risk owners or root causes or potential responses may not be immediately available when the initial version of the risk register is created. But, at this stage we must make a dedicated attempt to furnish as much information as possible so that the subsequent processes can take things forward.

2. Perform Qualitative Risk Analysis

The Perform Qualitative Risk Analysis process takes the risk register created in the Identify Risks process and makes further updates to the same. The updates that happen to the risk register in this process include:

1. Ranking or a priority list of risks
2. Risks grouped by categories
3. Causes of risks
4. List of risks that require a near-term response
5. List of risks that require additional analysis & response
6. Watch list of low priority risks
7. Trends in qualitative risk analysis results

As you must remember from the previous section on the Risk Management Plan, we will use the Probability & Impact matrix to classify risks and to create a prioritized list of risks. The purpose of categorizing risks is to group related risks and to address them together. Usually this is done because this categorization can help us identify the root cause and addressing one root cause can help us eliminate multiple risks.

In this process, we identify those risks that are urgent (ones with high probability & impact) and try to take care of them immediately. There are also cases where we may need to perform further analysis before we decide on the further course of action on the risk. In those cases, we note them down and analyze them in the next process which is the Perform Quantitative Risk Analysis. During our analysis we may also find out certain risks that are either very low risk or impact or both. In such cases we usually move them to a watch list for the moment and continue with the other risks. We must constantly monitor those watch list items to ensure that their probability or impact hasn’t changed to ensure that we don’t get any unwanted surprises.

The trends identification part may have taken you by surprise. Identifying trends is not easy and requires a lot of experience. Do you remember that I said that Risk Management is an iterative process? We usually do multiple iterations of these processes and during such cases, if we watch closely we may be able to identify trends on those risks that may be due to a totally different or even a bigger problem.


3. Perform Quantitative Risk Analysis

After we complete qualitative analysis, we would’ve identified a subset of risks that need further analysis. We will be analyzing those risks quantitative in this process. During this phase, the following updates happen on the risk register:

1. Probabilistic Analysis of the Project
2. Probability of Achieving cost & time objectives
3. Prioritized list of quantified risks
4. Trends in quantitative risk analysis results

Conducting a probabilistic analysis of the whole project helps us avoid cost and schedule overruns. Here we will be trying to figure out the probability that we will complete the project in time or under budget. This will also give us a fair idea of how much reserves are required.

At the end of this process, we would have further prioritized the risks. The trends part here is similar to the trends we covered under the Qualitative analysis process.

4. Plan Risk Responses

After we have analyzed and prioritized all the risks, the next step is to figure out “What to do in case the risk occurs” and that is what we will be doing in this process. This is the process that makes the most number of updates to the risk register. Also, most of these updates are interrelated.

The updates that happen to the risk register in this process are:

1. Agreed upon response strategies
2. Risk Owner & Assigned Responsibilities
3. Specific actions to implement the chosen response strategy
4. Symptoms & warning signs of risk occurrence
5. Budget and schedule activities required to implement the chosen responses
6. Contingency reserves of time & cost designed to provide for stakeholder risk tolerances
7. Contingency plans and triggers that call for their execution
8. Fallback plans
9. Residual risks expected to remain
10. Secondary risks
11. Contingency reserves that are calculated based on quantitative analysis

By this point all risks must have an assigned owner who is in-charge of those risks. If some of the items in the list above seem new to you, don’t get overwhelmed. This is just the introductory phase of our preparation for the RMP Certification. There is still a long way to go and we will be covering all of these in great detail…

Usually our response strategies are based on our organizational policies as well as risk tolerances. Also, the organizational and stakeholder risk tolerance has a direct bearing on the contingency reserves. Usually if the stakeholder risk tolerance is how, the reserves will be low and vice versa. It is our responsibility to gauge the risk tolerance level and arrive at the appropriate contingency reserves.

Fallback plans are those “Plan B” kind of plans that we will implement in case the original response is not fully effective. Residual risks are those risks that remain even after our original responses are implemented. Secondary risks on the other hand are those risks that are caused because of the risk response plan we implemented. These risks must not be ignored and have to be dealt with accordingly.

5. Monitor & Control Risks

This is the last process in our risk management knowledge area. In this process the following updates happen to the risk register:

1. Outcomes of risk assessment, risk audits and periodic risk reviews
2. Closing risks that are no longer applicable
3. Actual outcomes of Project risks & risk responses

An important point to note here is that, risk reassessments and audits may unearth new risks as well. We need to ensure that those risks are handled appropriately as well. Also, documenting the actual outcomes can help us as well as other projects in future that may encounter similar scenarios as those that just failed for us. So, it is extremely vital that we document all those items accurately and truthfully.

Prev: Overview of Risk Register

Next: Section Summary - Risk Register

Overview of the Risk Register

The risk Register is one of the most important (if not the important) components of project risk management. It is also a key component of the Project Management Plan. The risk Register stores all the identified risks along with a lot of other information regarding those risks.

The details that you can expect to find in a Risk Register, about those risks are:

1. Risk Description
2. Risk Owner
3. Risk Category
4. Root Cause
5. Impact on the Project Objectives (If the risk event occurs)
6. Probability of the Risk Occurring
7. Proposed Responses
8. Current Status of the Risk

As you can see, it is the one stop shop for all your information needs with respect to the risks that might affect your project. Because of all the details it contains, it is an input and/or an output of almost all risk management processes.

Remember the chapter on Risk Management & the PMBOK guide? Of the 6 Risk Management processes outlined in that chapter, the Risk Register is an input to 4 of those processes and an output of 5 of those processes.

The Risk Register is an input to the following risk management processes:

1. Perform Qualitative Risk Analysis
2. Perform Quantitative Risk Analysis
3. Plan Risk Responses
4. Monitor & Control Risks

In short – It is an input to every single process that comes after risks are identified.

The Risk Register is an output of the following risk management processes:

1. Identify Risks
2. Perform Qualitative Risk Analysis
3. Perform Quantitative Risk Analysis
4. Plan Risk Responses
5. Monitor & Control Risks

In short – It is an output of every single process that comes after risk management is planned.

Trivia:

If you see that the Risk Register is an input to a process, it essentially means that it will be updated and be an output of the same process as well.

Because the risk register is part of almost all activities/processes in project risk management, if you properly understand the risk register, you will be able to easily understand the rest of the topics on risk management. So, it is very important that you understand the purpose of the risk register and how it used instead of just memorizing what you read here.

Prev: Section Summary - The RM Plan

Next: Contents of the Risk Register

Section Summary – The Risk Management Plan

In the previous few chapters, we took a detailed look at the Risk Management Plan. Let us now quickly summarize what we have learnt so far about the RM Plan…

• The RM Plan is the heart and soul of Risk Management
• The purpose of the Risk Management Plan is to define how risks will be managed, monitored and controlled throughout the project
• The RM Plan is created during the Plan Risk Management process of the PMBOK guide.
• The following are the inputs used in creating the RM Plan:

o Project Scope Statement
o Cost Management Plan
o Schedule Management Plan
o Communications Management Plan
o Enterprise Environmental Factors &
o Organizational Process Assets

• The Risk Management Plan is created using a Planning Meeting
• The Planning meeting is critical to the project’s success because they create the foundation and the roadmap for all risk related activities in the project
• As per the PMBOK guide, the RM Plan contains 10 sections. They are:

o Risk Methodology
o Roles & Responsibilities
o Budgeting Information
o Timing Information
o Risk Categories
o Definition of Risk Probability & Impact
o The Probability & Impact Matrix
o Revised Stakeholder Risk Tolerances
o Reporting Formats and
o Risk Tracking Information

• Based on the guidelines defined in the RM Plan, risks are first identified and added to the risk Register. They are then prioritized during Qualitative risk Analysis and the risk register is further updated with the Risk Ratings which will help us decide which risks to concentrate on and which ones we can worry less about.

Prev: Contents of a RM Plan

Next: Overview of the Risk Register

Contents of a Risk Management Plan

In the previous chapters we took a look at inputs or resources we will use in the creation of a risk management plan as well as about the Risk Planning Meetings that are used to actually create these plans. So, the next logical step is to know what the risk management plan contains so that we will know what all to include in our plan to ensure smooth and successful risk management in our project.

According to the PMBOK guide, the Risk Management Plan contains the following elements:

1. Risk Methodology
2. Roles & Responsibilities
3. Budgeting Information
4. Timing Information
5. Risk Categories
6. Definition of Risk Probability & Impact
7. The Probability & Impact Matrix
8. Revised Stakeholder Risk Tolerances
9. Reporting Formats and
10. Risk Tracking Information

Many of those contents look pretty straight forward and if you are a PMP you must by now know a fair bit about these elements. Anyways we will be covering them in detail one by one. An important point to note here is that organizations can have templates and documents from previous projects that can be very useful in creating the risk management plan for the current project. From the RMP Exam perspective you need to use the structure that PMBOK suggests.

Risk Methodology

Risk Methodology covers the “How” of Risk Management. We define the methods and tools we will use in our projects risk management activities. We will also mention the sources from where we will get the data that will be used in the risk related processes in our project.

Roles & Responsibilities

This section defines the roles & responsibilities for everyone who will be involved in risk management activities in our project. “Who” they are and “What” they will be doing will be clearly defined here. A point to note here is that anyone and everyone who will be involved in risk related activities in our project will be added here and most importantly people from outside our project team too could be a part of this.

Budgeting Information

This section covers the financial aspect of the risk management activities in our project. It defines the amount of funds set aside for risk management activities as well as the contingency reserves that are available. It also describes the amount of money that will be spent on the risk management activities as well as the resources that will be used for the same. This information will be part of the projects overall cost performance baseline

An important point here is that, this section also defines the protocols or situations under which the contingency reserves will be utilized.

Timing Information

This section covers the timing/schedule aspect of the risk management activities in our project. i.e., it explains when the risk management activities will happen in our project. It also contains details of the schedule contingency reserves that are available. This information will be part of the overall projects schedule baseline.

An important point here is that, this section also defines the protocols or situations under which the schedule contingency reserves will be utilized

Trivia:

Did you realize that the budgeting & timing information in the RM plan is part of the Projects overall Cost and Schedule baseline? Did you stop and think why they are being added to the baseline?

This risk management activity is part of the work that will be taken up as part of our project. So it makes sense for us to include the money and time we are going to spend on these activities into the projects overall budget as well as schedule. Doesn’t it?

Risk Categories

This section explains all the risk categories that will be used in our project. It could also contain some rationalization/justification behind the selection of these categories. This is done to ensure consistency across the project. The Risk Breakdown Structure is a common way of depicting the risk categories. Though the RBS is fairly common in almost all RM Plans, it is not mandatory. You can decide how you want to depict the risk categories you will be using in your project. It could be a RBS or just a simple list of risk categories.

Revised Stakeholder Risk Tolerances

This section defines/explains the updated risk tolerance levels of all the project stakeholders. This will be the baseline based on which as project managers we will handle risks in our project.

Reporting Formats

This section defines how risk activities will be documented, analyzed and shared with all appropriate stakeholders. Most organizations have a standard template or format in which this information is shared. Usually the Risk Register (with all the latest updates about the identified risks) is the document that gets shared

Risk Tracking

This section describes how the risk activities will be recorded with the project as well as how the lessons learned will be documented. This section also contains information on how our risk related processes will be audited.

Definition of Risk Probability & Impact

This section defines the risk probability and impact using a scale or a rating system. This rating system is defined here in the risk management plan so that we can easily and consistently rate all risks that may affect our project. We will be defining the guidelines that we will be using to accurately assess and rate risks in our project. This information will be used in the Qualitative Risk Analysis process where we assign a rating to all our identified risks to shortlist the higher priority risks.

There are various ways of documenting the risk probabilities and impact and as you might have guessed by now, it depends on your organization. Some commonly used ways are to use the “High-Medium-Low” scale or a Numeric scale. The picture below shows two sample scales.



The image on the top classifies the risks based on their impact or probability as low, medium and high whereas the one in the bottom assigns a numeric value based on the same criteria as the table above it.


Probability & Impact Matrix

The probability and impact matrix is used to prioritize risks and to determine which risks require a response. This will serve as a look-up table that combines both the probability and impact rating so that risks can be rated in a consistent manner. This again will be used in the Qualitative Risk Analysis process.


Don’t worry, we will be covering the Qualitative analysis in great detail in future. For now just know that the probability and impact definitions as well as the probability and impact matrix are defined in the RM Plan. Based on the guidelines defined in the RM Plan, risks are first identified and added to the risk Register. They are then prioritized during Qualitative risk Analysis and the risk register is further updated with the Risk Ratings which will help us decide which risks to concentrate on and which ones we can worry less about. This is explained in the picture below:



Prev: Creating the RM Plan

Next: Section Summary

Creating the Risk Management Plan

In the previous chapter, we took a look at the resources or the inputs we will use to create the Risk Management Plan. In this chapter, we are going to look at the techniques used to create the RM Plan which is “Planning Meeting & Analysis”. Planning Meetings & Analysis is listed as a Tool & Technique in the Plan Risk Management process of the PMBOK Guide.

The Planning Meeting:

The Planning Meeting is where we are going to create our Risk Management Plan. In order to conduct or carry-out an effective meeting, we need to know what needs to be done. The following are things we need to know/get-done in order to complete this activity

1. Purpose of the Meeting – The high level purpose of our meeting is to develop the Risk Management Plan and all other risk management related activities in the Project
2. Who Attends – Usually the list of meeting attendees will include the Project Manager, selected project team members (usually leads) and stakeholders, anyone else who may be involved in risk planning and risk execution activities etc. Practically speaking everyone who has a say in how risk is planned or executed in our project must be a part of this meeting
3. When they are held – These planning meetings are usually held in the very early stages of the planning stage of our project
4. What to bring to the meeting – We need to bring all documents & resources that will be used to create the RM Plan. Remember all the inputs from the previous chapter?
5. Meeting Agenda – The meeting agenda usually varies from project to project but the basic agenda revolves around “What we are planning to accomplish in this meeting” which will be ”Creating the Risk Management Plan”. During the meeting, the participants have to go over various areas that need to be covered in order to complete the creation of the RM Plan. This would include

a. The Cost of conducting risk management activities that need to be included in the project budget
b. The risk schedule of activities that need to be included in the project schedule
c. The approach for risk & contingency reserves
d. The contingency reserves
e. Assigning risk related roles & responsibilities
f. Identifying risk categories that we will use in our project
g. Define the levels of risk, their probability & impact to be considered in our project
h. Etc.

6. The Output – This is a no-brainer. The output of this meeting would be the draft version of the Projects Risk Management Plan.

These planning meetings are critical to the project’s success because they create the foundation and the roadmap for all risk related activities in the project. The success of this meeting has a direct impact on how risks are managed in the project and eventually on the projects overall success itself.

We have seen above that the output of this planning meeting is the Risk Management Plan. But, what does this plan contain? This is what we are going to cover in the next chapter.

Prev: Inputs to Create the RM Plan

Next: Contents of a Risk Management Plan

Inputs to Create the Risk Management Plan

In the previous chapter, we saw the importance of having a good Risk Management Plan in order to conduct the risk management activities efficiently in our project. But, before we can actually look at how to create this plan, we need to take a look at the resources or items that we will use as inputs in the creation of the same.

There are several key items we will use to create the risk management plan. All these items will be listed as “inputs” in the “Plan Risk Management” process in the PMBOK guide. In this chapter, we are going to take a detailed look at these resources.

Before we begin, do you remember that in one of the earlier chapters, I said that the risk management plan is a subsidiary plan of the project management plan? Well, three of the inputs/resources we will use to create this risk management plan too are subsidiary plans of the project management plan as well.

Inputs/Resources used to Create the Risk Management Plan:

The input items or resources we will use in the creation of a risk management plan are:

1. Project Scope Statement – This provides a list of the projects deliverables as well as the important information about what the project is going to accomplish. This information will be used as the guideline as to how risk management will be conducted in our project. Also, the scope statement will contain details like the Project Constraints, Assumptions & Acceptance Criteria which will be vital for the risk management plan.

Trivia:

Can you guess why these constraints & assumptions are vital to the risk management plan? What if you assumed that your peer project manager will release one of his QA Testers after 3 months so that you can he can perform your projects QA activities and after 3 months your peer PM refuses to release that resource? Wouldn’t that be a risk? What about a deadline that the project has to go live by 31st Dec of this year? Wouldn’t that be a risk?

The reason why these constraints & assumptions are critical are because, these can contribute directly to risks.

2. Cost Management Plan – This provides us with information like the Risk Budget, Contingencies available as well as the Management Reserves (We will be learning about contingencies & reserves very soon)
3. Schedule Management Plan – This provides us with information on the Schedule Contingencies
4. Communication Plan – This defines how risks and risk responses will be reported, who should he keep in loop about the risk progress, who is responsible for sharing the information and when etc

Trivia:

In the previous paragraph I had said that 3 of the PM Plans subsidiary plans are used as inputs in this process. Can you guess which ones they are?

Answer – Points 2, 3 & 4.

5. Enterprise Environmental Factors – These are the Project Environment related factors like Risk Attitude & Risk Tolerance of the Organization as well as stakeholders. These are very important in planning the risk strategy and approach for your project.
6. Organizational Process Assets – This includes documents and templates for the Risk management plan, the risk register, risk categories, roles & responsibilities, authority levels, lessons learned etc.

A Word of Caution:

The Enterprise Environmental Factors & Organization Process Assets may seem like no-brainers but can have a direct impact on the quality of the RM Plan you create and most importantly on the overall risk management in the project. Since each organization has a different risk tolerance and procedures to handle risk, the environmental factors & process assets vary from org to org. So, if you are someone who just moved into a new organization, this is all the more important because the new company may handle risks in a totally different way when compared to what you are used to in your previous job.

Armed with all this information, we are all set to create a good quality risk management plan. But, just having these inputs is not enough. We need to know how to utilize them property in order to create a good risk management plan. This whole scenario can be compared to cooking a complex dish by seeing a celebrity chef’s cookbook. You can read it thoroughly and get all the ingredients ready on your kitchen table. But, the quality of the dish depends entirely on how you execute the recipe. Isn’t that right? Same is the case with the creation of the risk management plan. No matter how good your inputs are, if you don’t know how to utilize them properly your risk management plan will practically be useless.

Now that we know the inputs we need to create the risk management plan, in the next chapter we are going to look at the tools & techniques (the how-to) to create it.

Prev: Introduction to Risk Management Plan

Next: Creating the RM Plan

Risk Management Plan – An Introduction

The Risk Management plan is the heart and soul of Risk Management. It guides the project team in carrying out risk related activities in the project. In this section we are going to learn in detail about this valuable piece of document that will be used by the Risk Manager throughout the project’s lifecycle.

Let us start off with the Purpose of the Risk Management Plan.

The purpose of the Risk Management Plan is to define how risks will be managed, monitored and controlled throughout the project.

It details how risk management processes of the Project Risk Management knowledge area will be carried out, thereby increasing the chances of success of the project processes. The risk management plan is a subsidiary of the Project Management Plan which you might already know is a collection of various subsidiary plans and components. Do you remember the earlier chapter on the Project Risk Management knowledge areas?? The Risk Management Plan is created during the first process namely “Plan Risk Management”.

Trivia:

It is easy & fairly common to confuse the Risk Management Plan with the Risk Response Plan. The Risk Response Plan only explains how we are going to handle/respond to all the risks identified for our project. But, the Risk Management plan is the overall guide based on which all risk management activities are taken up in the project.

The Risk Management Plan defines the guidelines based on which we manage risks in our project. The Risk Management Plan is our treasure map for conducting all the risk management activities in our project. Having a good understanding of how to take-up risk related activities among all members of the project is vital for the success of the project. The risk management plan can be greatly useful in achieving this understanding.

The Risk Management Plan is created/developed during the early stages of the Project itself. Actually speaking, the earlier the better… The risk management plan creation begins almost immediately after the project is started and is usually completed during the early stages of project planning. Below is a simple illustration of this create risk management plan activity.



As you can see – there are 3 steps in this process:

1. Obtain Necessary Resources
2. Conduct Planning Meetings &
3. Generate the Risk Management Plan

By Resources, we are not only referring to people but also to all relevant items like standards, policies, templates etc. that will be used in creating the risk management plan.

The creation of the Risk Management Plan is a complex and critical activity and needs to be covered in greater detail. This chapter was just the introduction. Let us dig into the details in the next few chapters…

Prev: Section Summary - Understanding Risk Management

Next: Inputs to create the RM Plan

Section Summary - Understanding Risk Management

In this section we have learnt about the basics of Risk Management that will be useful on our journey towards the PMI’s Risk Management Professional Certification.
Let us summarize what have learnt so far:

• A Risk is an uncertain event or condition that if it occurs, has a positive or negative effect on a projects objectives
• Risk Management is the act of increasing the probability and impact of positive events & decreasing the probability and impact of adverse events within a project
• The goal of risk management is to identify the risks within the project and develop a response to either reduce the impact or the probability of a negative risk. If the risk is a positive risk (opportunity) then the goal is to increase the probability and impact of the same.
• The PMBOK Guide covers the Risk Management knowledge area extensively and it is the basis on which our preparation for the RMP Certification is going to proceed
• The Risk Management Plan and the Risk Register are two important documents that are vital to efficient Risk Management
• The Environment in which the Project is executed can have a direct influence on the Project and can be a source of risks for the project. These environmental factors can be grouped into two “Internal” and “External” factors.
• The Project Organizational Structure is one of the vital Internal Factors that affects a Project. An organization can be of 3 types – Functional, Projectized or Matrix. A Matrix Organization in turn can be either a weak matrix, a balanced matrix or a strong matrix
• An Issue is something that is occurring now in the present and is currently being dealt with
• Risk Triggers are signs or indications that is risk event is about to occur or has already occurred. They are also known as Risk Symptoms or Warning Signs
• Pure risk is a type of risk that can result only in losses
• The purpose of Risk Categorization is to systematically identify risks in a consistent manner and organize them so that they can be managed better
• Uncertainty refers to the lack of knowledge of future events whether these events are positive or negative to the project.
• In almost all cases, a risk is taken in pursuit of some kind of benefit
• Part of managing risk is, knowing when to accept a risk.
• The Standard 5 Step approach to managing project risk is widely used to manage project risks and we will use it too. The 5 steps in it are:

o Risk Management Planning
o Information Gathering & Risk Identification
o Risk Assessment & analysis
o Risk Response Planning
o Plan Execution

Prev: Five Step Approach to Risk Management

Next: Risk Management Plan - An Intro

Five Step Approach to Managing Project Risk

If you have read all the previous chapters, by now you have a good foundation level understanding of what Project Risk Management is. We have already covered the Risk Management Framework as well as PMBOK Guides Perspective of Risk Management. Now we are going to take a look at the “5 Step Approach to Managing Project Risk” which will enhance your high-level understanding of the whole area of project risk management.

Good Project Risk Management begins early on in the life of the project when the data & information availability is minimal. This is because, this is the stage where uncertainty is at its highest and applying effective Risk Management will be most beneficial.

In order for Risk Management to be effective, we need to ensure that:

a. We have a thorough and realistic understanding of the Project, the Project Goals and Project Scope. If we do not have this basic understanding, then we may end up fighting a losing battle. Think this way, can you effectively prepare for a boxing match when you do not who your opponent is, where it is going to take place and how he fights? Even if you manage to be prepared, what are your chances of success? What is your opponent is 7 feet tall and weighs 450 pounds?
b. Follow good Project Management Practices. This again is extremely vital to ensure project success. A good project manager is one that plans meticulously and ensures that all stakeholders are identified and the scope is clearly defined. The good project manager never leaves anything to be assumed and ensures that all stakeholders are kept at the ideal level of understanding for a smooth project progression. If we can ensure this, we are not only reducing project risk but also increasing the chances of our project’s success.

The Standard Five Step Approach to Managing Project Risk

The Standard 5 step approach to project risk management consists of the following steps:

1. Risk Management Planning – This is the first step. This is where we plan and strategize on how to manage all the risks in our project. This is where the Risk Management Plan is created. We define what a risk is and ensure that everyone is in the same page.
2. Information Gathering & Risk Identification – This is where we gather all the relevant information that will enable us to identify all possible risks that might affect our project or its outcomes.
3. Risk Assessment & Analysis – This is the step where we analyze all those risks identified in the previous step. We will shortlist only those important (high impact/probability) risks and move the lower priority/possibility risks to a watch list.
4. Risk Response Planning – This is the step where all those risks that were identified & analyzed are actually addressed. We work on minimizing the probability of the negative risks as well as on enhancing the opportunities. We create workaround plans, risk mitigation strategies, contingency plans etc. in this step.
5. Plan Execution – This is the step where we implement the Risk Response Plan, monitor all the identified risks, look out for new risks, check the watch-list to ensure that their priority/probability/impact haven’t changed etc.

The picture below explains the same



As you can see, the steps are iterative and occur multiple times during the projects lifecycle. If you thought risk management was a onetime activity, just erase that thought from your mind and re-write the fact that risk management is iterative and happens multiple times during the lifecycle of the project.

Documenting Risks:

Risk Documentation is a part of every single step in this standard 5 step approach to Risk Management.

After reading the above statement, are you wondering why I haven’t included it in the picture or in the explanation? The reason is because, Risk Documentation has to happen at every stage of this process. If I put it as a step then you might be misled into thinking that it happens only at that particular time.

A good Project/Risk Manager is one who documents all vital information at every step of the way. Right from the planning stage to the closing stage, a lot of valuable lessons and risk related data are uncovered. All these must be documented properly and archived towards the end of the project to ensure that all future projects can benefit from our experience or should I say Mistakes…

Prev: Managing Uncertainty

Next: Section Summary

Managing Uncertainty

Managing Risk is all about managing the uncertainty in your project. As I have said many times in the previous chapter, every project will have some level of uncertainty and it is this uncertainty that can lead to risks. The job of the Risk Manager is to handle all these uncertainties and the risks that arise due to them. Risk & Uncertainty go hand in hand. Uncertainty refers to the lack of knowledge on a future event which can be the source of a risk. This risk can either be a threat or an opportunity which arises out of this uncertainty.

As explained in the Types of Risks chapter, there are various types of Risks like Known risks, Known Unknown risks, Unknown Unknown risks etc… Each of these will contain varying levels of uncertainty. Our job in managing risk is to decrease the level of uncertainty, be prepared to handle the uncertainty and most importantly respond to the risk event if one occurs…

We have talked a lot about Uncertainty but we haven’t seen its official definition yet. So, here goes:

Uncertainty refers to the lack of knowledge of future events whether these events are positive or negative to the project.

These Uncertainties can lead to risks and therefore our project must plan for the potential situations to handle the risks that may affect our project objectives like scope, schedule, budget etc…

In a Majority of the cases, Risk arises from making decisions during uncertain circumstances. Let’s say your Project Teams technical architect is out on a personal emergency and won’t be returning for at least 10 more days and there is a huge design decision that needs to be taken right away. At this time, you are uncertain of which design to proceed with and ask the senior most developer to take the decision. Now, this is a risk. Though as managers we are doing the next-best-thing in consulting with the senior most developer, there is still some risk because, this guy may not be as knowledgeable as our Technical Architect and the design he chooses might create some problems in the future. However, this is a risk which was taken because of your decision during an uncertain situation.

While we cannot control the actual risk event, the whole idea behind risk management is to control the circumstances that can lead up to the risk. Let’s understanding this with a real-life example.

Let us say you need to drive your car from Chennai to Madurai to drop your grand-parents in their village home. They can’t take public transport so, driving your car is your only option. You know that en-route from Trichy to Pudukottai there is road-improvement work happening as a result there is a lot of debris on the road and might cause a flat tire. How will you handle the situation?

One alternative is to avoid that route and take the Trichy-Madurai bye-pass. Though it might take you an extra half hour of drive, the road is a highway and won’t cause any flat tires. Alternately, if you are very good at changing tires, you may carry a spare tire and take the risk to avoid driving the extra half hour…

This is exactly how we will react to Project Risks too…

Risks and Rewards

Go back to the driving to Madurai example. If you chose the second alternative of driving through the tricky stretch of road with a spare tire what was your reward? “Driving for lesser time”. The Risk you took was in pursuit of some sort of Reward. For starters you may think that this half an hour reward is too little. But, if you ask someone who has already driven nearly 350 kms from Chennai for over 5 hours, this half hour will mean a lot more.

In almost all cases, a risk is taken in pursuit of some kind of benefit. The situation is no different in our Project Scenario as well. We may take risks to achieve benefits like reducing costs, meeting a schedule deadline etc. The Rewards we obtain play a huge role in determining whether and more importantly which risks we take.


Accepting Risks

Part of managing risk is - knowing when to accept a risk. Go back to our driving to Madurai example. In case you get a flat tire while driving, what options do you have? You accept the risk, replace the flat tire and continue your journey. Isn’t it? But, in real-life project scenarios, things aren’t as clear and easy to decide. So, the decision to accept the risk is very tricky and difficult.

So, when should we accept risk? There are some general rules that can help us decide whether or not to accept a risk. This differs from company to company and so, you must check with your company’s policy on accepting risks. As a general rule of the thumb, ask yourself the following questions…

Based on your response to the above questions, you can decide whether to accept the risk or not. But, this is just the start. There is a great deal of analysis and information gathering that happens during the risk assessment phase. Only after this assessment/analysis will we be able to decide on how to handle a risk. But, the above section is here because you need to understand that “Accepting a Risk” is sometimes the only option you have and can’t ignore it as a risk response mechanism.

Risks and the Project Life cycle

Every project has a Project Life Cycle and it goes from the day it is initiated to the day it is wrapped up & closed. Risks have a direct relationship with the life-cycle stage the project is in at the moment.

The probability of a risk occurring is the highest at the beginning and reduces gradually as the project progresses through the phases. This is because, the level of uncertainty with respect to the Project Outcomes as well as what needs to be done is the highest at the beginning. As we progress through the life-cycle stages, clarity appears and the amount of uncertainty comes down. So, does the Risk…

Similarly, the impact a risk will have on the project will be the lowest at the beginning and will gradually increase as the project progresses. This is because, not much is completed at the beginning and as things get completed more and more, the impact a risk may have would also increase.

The progression of both Risk Probability & Impact through the life-stage of a project is explained in the picture below:



As you can see the probability starts at around 95% in the Initiating Stage and comes down as we move to planning, executing and so on. Similarly the Impact starts at around 5% (See from reverse for the red graph) and increases as we move towards the Projects closing phase.

Both the Risk’s Probability and its Impact determine how we will respond or handle that particular risk.

Prev: Risk Categorization

Next: Five Step Approach to Managing Project Risk

Risk Categorization

As explained in the previous chapter, the distinction between risk categories and risk types is pretty blurred. The distinction you find in this blog is what the majority of the project management world goes with. However, don’t be surprised if your organization goes by a different yardstick when it comes to classifying or categorizing risks.

There are way too many categories of risks and as I said before, every company uses its own risk categorization standards. As per the PMBOK guide the term Risk Category refers to “A Group of Potential Causes of Risk”.

Why do Risk Categorization?

Did you think of this? Why go through the pain of categorizing these risks when we are anyways going to list them all down in the Risk Register and handle them?

The whole purpose of Risk Categorization is to systematically identify risks in a consistent manner and organize them so that they can be better managed. It also helps to identify the root causes of these risks in a better way. A Risk Breakdown Structure or RBS is a classic example of this Risk Categorization idea. The RBS splits risks into categories and then splits them further into sub-categories thereby making our lives (The life of a Risk Manager) easier.



The above is a sample RBS where we have classified the risks for a project into 3 broad categories:

a. Internal
b. External &
c. Project Management

Each of these categories has been further split into 3 sub-categories. A typical RBS can have as many categories & sub-categories as you want. The 3 above is just an example…

How to Proceed with Risk Categorization? – For New Project Managers:

If you are a new Project Manager or new to the Organization where you are managing your projects and are not too sure of how to proceed with this Risk Categorization exercise, don’t worry. Check out previous projects that were similar to yours from the archives and see how the categorization was done. Or you could check with commercial templates based on which industry you work on. Or even better, check with other PMs in your company and check how they completed this activity for their project. This way you will have enough information to proceed with and perform a good quality categorization…

Practically speaking, there is no master list of categories that you can use for your project. It changes from project to project, from industry to industry and most importantly as I have said numerous times before, from company to company. Nonetheless, to get you started in the right direction, below are some broad categories that can be used in a majority of the projects that you may encounter in your life. A word of caution here is that, the list below is not complete and only the starting point for you to improvise on…

1. Internal
2. External
3. Environmental
4. Economic
5. Political
6. Market
7. Process
8. Third-Party
9. Business
10. Operations
11. Organizational
12. Infrastructure
13. Culture
14. Technology
15. Human Resources
16. Legal
17. Financial
18. Project Management
19. Security
20. Etc.

Prev: Types of Risk

Next: Managing Uncertainty

Types of Risks

Risks come in various types and categories. In many cases, the distinction between Risk Types and risk Categories is not very clear-cut. What some people may consider as a type others may consider that a category and vice versa. The important point here is that, in order to do our jobs well, we need to understand our organizations distinction between the Risk Types & Risk Categories. Nonetheless, we must understand all these classifications and must be able to apply them on the job.

In this blog, we will consider Risk Types & Risk Categories as two distinct entities based on my understanding of these topics.

Types of Risk:
Risks can be classified as follows:

1. Business Risks
2. Pure Risk
3. Known Risks
4. Known Unknown Risks
5. Unknown Unknown Risks
6. Risk Classification based on Impact to the Project Objectives

Business Risks

A Business Risk refers to a possibility of a gain or loss that may affect our project/business. This means it can either be a threat or an opportunity.

Pure Risks

Pure Risks are those risks that cause only losses. Typically, most of these Pure Risks are Insurable. They can be further sub-classified as:

a. Direct Property Damage Risks – Risks that arise out of property damage due to natural calamities like floods, fire etc
b. Indirect Property Damage or Losses. Ex: Business Operations are disrupted, Removal of Debris due to a direct property damage, inability to finance expenses etc
c. Legal Liabilities – Lawsuits for injury to people or damages claimed due to faulty design etc
d. Personnel Related – Injury and liability due to injury to employees which includes medical treatment, maintenance as well as replacement labor cost

Known Risks

Known Risks are those risks where the Risk is Clear and there is no unknown information about the risk. In other words No Uncertainty Exists

Known Unknown Risks

Known Unknowns are those risks where we are well aware of the risk but we do not know when it will occur or what the impact will be. For ex: When we buy a car, we know that it needs to be serviced regularly otherwise it will breakdown. This is a known risk. Just exactly when the car will breakdown is the unknown part of this risk. Isn’t it?

Unknown Unknown Risks

Unknown Unknowns are those where we are practically clueless about either the risk or its impact or its timeliness. What would happen if a Tsunami were to strike the coast tomorrow morning while we are jogging? Is this something we can plan or foresee?

Apart from the above types of Risks, we can also classify risks based on the Project Objective a risk would impact. They are:

a. Scope Risks – Risks that are related to changes to the Project Scope (Ex: Scope Creep)
b. Quality Risks – Risks that are related to the Projects Quality Standards (Ex: Missing Quality checks)
c. Schedule Risks – Risks that are related to the Projects Schedule (Ex: Missed Delivery dates)
d. Cost Risks – Risks that are related to the Projects cost (Ex: Budget Overruns)

Prev: Risk Definitions

Next: Risk Categorization

Important Risk Related Definitions

In the previous chapter we learnt about the Project Environmental Factors that may affect our project. Before we go any further, let us stop for a moment and take a look at some of the important definitions that we will be using henceforth throughout this series on the Risk Management Professional certification exam prep.

We may have some of these definitions already in the previous chapters. But, they are still here for the sake of completeness so that we cover all these important terms in one place.

Risk – A Risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on the projects objectives

Issue – An Issue is something that is occurring now in the present. You know about it and it is being dealt with. An Issue is a threat that has already materialized. They are kept track of using an Issue Log.

Risk Event – A Risk Event is the description of a scenario that may occur if the risk were to materialize

Risk Triggers – Risk Triggers are signs or indications that a risk event is about to occur or has already occurred. These are also known as Risk Symptoms or Warning Signs.

Risk Management Plan – The Risk Management Plan is the document that describes how the risk management processes will be carried out in our project. It describes how risk management will be planned; risks will be identified, analyzed & prioritized, responded, monitored and controlled.

Risk Register – The Risk Register is a document that contains all the identified risks, the results of risk analysis, the proposed risk responses and the current status of each of the identified risks

Risk Breakdown Structure – The Risk Breakdown Structure (Or RBS) is a hierarchical breakdown of risks organized by risk categories or impact

Probability – The term Probability refers to the chances that a risk may occur

Impact – The term Impact refers to the effect that a particular risk event will have on our project if it occurs

Prev: Project Environment

Next: Types of Risks