Overview of Tools & Techniques used in Qualitative Risk Analysis

In the previous section, we covered all the inputs we will need in order to effectively perform the Qualitative Risk Analysis step of Risk Management in your project. The next logical step is to apply some tools & techniques on these input in order to kick-start our Risk Analysis activities.

There are a total of 6 tools & techniques that we are going to learn in this section. They are:

1. Risk Probability & Impact Assessment
2. Probability & Impact Matrix
3. Risk Data Quality Assessment
4. Risk Categorization
5. Risk Urgency Assessment
6. Expert Judgment

Not all projects require us to use all of these tools or techniques. Projects vary in type, length, circumstances etc. Some tools that are very useful for a certain kind of project may not be so useful for a different kind of project. So, it is up to us to decide which tools are best suited for our project’s needs and utilize them effectively.

Trivia:

Do you remember that all risks are analyzed, assessed and prioritized based on the Stakeholder Risk Tolerance levels, probability & impact definitions etc that were defined in the Risk Management Plan? If you don’t, I strongly suggest you revisit the chapter titled “Creating the Risk Management Plan” and refresh your memory on the same.

Let me remind you that this chapter is just an overview of the tools & techniques we are going to use in Qualitative Risk Analysis. We will be taking a detailed look at each of these tools/techniques one by one in the following chapters in this section.

Prev: Inputs used in Qualitative Risk Analysis

Next: Risk Probability & Impact Assessment

Qualitative Risk Analysis - Inputs

In the previous chapter, we saw an overview of the Qualitative Risk Analysis process. As with any process, this one too takes some inputs, applies some tools & techniques and generates an output. As a first step, in this chapter, we are going to take a detailed look at all the inputs that this Qualitative Risk Analysis process uses.

To start off – Inputs here refers to all the documents and other sources of information that we will need to conduct an effective Qualitative Analysis. This process uses a total of 4 inputs. They are:

1. Risk Register
2. Risk Management Plan
3. Project Scope Statement
4. Organizational Process Assets

Let us take a detailed look at each of these input items.

Risk Register:

Remember the Risk Register we created just a couple of sections ago? This register is going to contain the most up-to-date information reg. all the risks that might affect our project. As of now this document is going to contain:
a. List of identified risks including their impact, consequences, root causes etc.
b. List of potential responses. This may not be available for all the risks but could be present for a few

The Risk Register is one of the key inputs to this process. Let’s face it, what kind of risk analysis can anyone do when they don’t have the list of risks that they have to analyze?

Trivia:

As suggested in the chapter titled Contents of the Risk Register the Risk Register is created as the output of the Identify risks process and is passed on as input to the next process in the risk management cycle for further updates. This qualitative analysis process if the first step after risk identification and the risk register will be updated in this process.

Risk Management Plan:

The Risk Management plan as you might have seen contains a truckload of information that will be useful in risk management & especially risk analysis. If you do not remember all of the contents then I suggest you revisit the chapter titled “Contents of the Risk Management Plan” to refresh your memory.

Of all the items that are present in a risk management plan, the qualitative risk analysis process uses the following:

a. Roles & Responsibilities
b. Budgeting Information
c. Timing Information
d. Risk Categories
e. Definition of Risk Probability & Impact
f. Risk Probability and Impact matrix
g. Stakeholder Risk Tolerance

As you might have noticed in the chapter titled “Contents of the Risk Management Plan” the risk management plan contains a lot more information than what is listed above. This is because we have listed down only those elements in the risk management plan that will be useful for us from the qualitative risk analysis process perspective.

The Risk Management Plan is yet another key input to this qualitative analysis process. Without details like who is going to do what, how much budget we have for this task, how much time we have for this task, the definition of risk impact & probability as per the project, the stakeholder risk tolerance etc. there is no way we can conduct an efficient analysis.

Project Scope Statement:

The project scope statement is another critical input component to this qualitative analysis process. This document is going to contain details about the projects deliverables and explains as to what the project is going to accomplish along with details like the project constraints, assumptions and acceptance criteria.

It also suggests if this project is going to create something new. Typically a project that is creating something new or is using something new (like a new technology) is more prone to risk as the same has never been done before in your organization. If what we are doing in our project is similar to any of the previous project executed by the project manager or the organization, things are a lot easier and the chances/number of risks come down too.

Organizational Process Assets

Organizational process assets refer to any and all process related assets like plans, policies, procedures and guidelines. Any document created by the organization for the benefit of the others in the same organization can be considered an Organizational Process Asset.

For this Qualitative Risk Analysis process the assets we can use are:

a. Lessons Learned document from previous similar projects
b. Risk Registers & sample response plans from previous similar projects

By taking into consideration how previous projects handled their risks, we can get a fair idea of how risks need to be handled in our project in the best possible way.

Prev: Introduction to Qualitative Risk Analysis

Next: Tools and techniques used in Qualitative analysis - an overview

Qualitative Risk Analysis – An Introduction

The Qualitative Risk Analysis process is the 3rd process within the Project Risk Management Knowledge Area in the PMBOK Guide. This chapter is just an introduction to this topic. We will be covering this topic in great detail in the subsequent chapters.

We have completed Risk Identification and have created the risk register which contains all the information we know about the risks we have identified so far. At this point the risk register contains only the basic details like what the risk is plus any potential response that you think might be feasible. But, apart from this information the register is empty. So, in this stage, we are going to analyze these identified risks and add as much information as possible about those risks into the risk register.

Purpose of Qualitative Risk Analysis:

The purpose of this process is to prioritize risks in order to determine which risks require additional analysis. This helps the risk management team to focus on the higher priority risks.

The Qualitative Risk Analysis process asks questions like:

a. What is the probability of this risk occurring?
b. What is the impact to the project objectives, if this risk occurs?
c. How much time do we have, to respond to this risk?
d. Where should we spend our effort?
e. Etc.

The Qualitative Risk Analysis process uses the definition of Probability & Impact we set in the Risk Management Plan. Also, we will be using the Risk Probability & Impact Matrix. The purpose of using these set values is to reduce bias on how risks are assessed and ensure a consistent analysis of all risks. We covered this in one of our earlier chapters titled “Contents of the Risk Management Plan”. You can revisit that chapter to refresh your memory about risk probability and impact.

At the end of qualitative risk analysis, we may feel the need to further analyze a few of the selected high priority risks. These risks will be further analyzed in the quantitative risk analysis process. The image below summarizes the steps in qualitative risk analysis:

Prev: Section Summary - Overview of Risk Analysis


Next: Inputs - Qualitative Risk Analysis

Section Summary – Overview of Risk Analysis

In this section we took a very high-level look at the Risk Analysis domain of the PMI Risk Management Professional certification examination. Let us now quickly summarize what we have learnt so far.

• Analyzing Risks is the next logical step a risk manager has to perform after risks are identified
• Risk Analysis is used to gauge the impact and probability of the risk to shortlist a few critical risks that may affect our project so that we can concentrate on those risks
• Risk Analysis includes two sub tasks - Qualitative Risk Analysis and Quantitative Risk Analysis
• Risk Analysis increases the team and the managers confidence level in dealing with risks
• It allows us to control risks with a greater success rate
• It helps us to create better responses to the risks
• Risk analysis is not a onetime activity. It is repetitive and we can send a risk for further analysis from both the Respond to Risks process as well as the Monitor & Control Risks process
• Both Risk Analysis and Risk Management are an integral part of project risk management. That is why the PMI RMP exam gives this domain a 30% weightage in terms of no. of questions that appear on the exam

Prev: Risk Analysis & Project Management

Next: Qualitative Analysis - An Intro

Risk Analysis and Project Management

The purpose of this chapter is to understand how Risk Analysis and Risk Management fit into the overall scheme of things in Project Management. Actually speaking, risk management is an integral part of project management. Unless we identify risks and manage them effectively, there is no way we can manage our project properly, much less make the project a success. Since risk analysis is an integral part of risk management, we can safely say that risk analysis too is an integral part of project management.

Look at the image below:

This is a simple illustration of how the various items in a project are connected/related to one another.

1. The Project Management Plan and Scope are in the center – This is because the whole project revolves around these two entities. You can’t manage a project without the PM Plan or without knowing the scope of work to be done. So, they take their rightful place in the center.
2. Schedule, Budget, Resources, Procurements are all in the bottom because they are influenced by both the PM Plan and the scope
3. Communication, Quality and Risk are on top of the triangle. Can you guess why??? Many Project Managers feel that these items Communication, Quality and Risk are not so important or view them as additional no-value-add activities on the project and hence ignore them to a great extent. Unfortunately these activities are vital to the overall success of the project and that is why they intentionally placed at the top of the triangle. They can have a direct bearing on all aspects of the project and hence they are rightfully on top of everything else.

Risk Analysis & Management not only considers what is happening inside the project. They also consider outside elements that may influence/impact the project. As risks are analyzed, more details like “when we can expect an activity to finish?” become clear. This information is usually fed-back into other processes so that they will know when to start/stop. Risk Management is literally connected to every single activity that happens in a project. That is why Risk Management is so important.

To summarize – Risk Analysis & Risk Management:

• Help control project outcome
• Consider both internal and external factors
• Has a dynamic relationship with almost all elements of the project
• Have a direct bearing on the overall success of the project

In short – Improper Risk Analysis can directly result in Project Failure. Now, can you understand why the PMI has given the highest weightage to the Risk Analysis domain in the exam from the no. of questions perspective?

Trivia:

Risk Analysis contributes 30% of the questions in the exam. You can revise the exam objectives of the Risk Analysis domain by Clicking Here

Prev: Overview of a Risk Analysis Model

Next: Section Summary

Overview of a Risk Analysis Model

You may find a plethora of books on the topic of Project Risk Management. Each of these may portal the topic of risk analysis in a different way. For the PMI RMP Exam, we are more concerned about PMBOK’s interpretation of risk analysis and hence we are going to look at the risk analysis model as the PMBOK suggests.

Look at the picture below:

This is the high-level model for Risk Analysis.

As you can see, the output of the Identify Risks process (risks) are sent as the input to the Analyze Risks process. The analyze risks process has two sub components which are the Qualitative Risk Analysis and Quantitative Risk Analysis. Qualitative Risk Analysis deals with assessing and prioritizing a risk while Quantitative Risk Analysis deals with numerical analysis of the risk. At the end of the day, both these processes focus on the risk’s impact and probability and in almost all cases, both of these analysis steps happen if risk management is to happen in an efficient way in our project.

Once the risk analysis is over, as you can see the output is sent as the input to the Plan Risk Responses process. If you look at the image closely you can see an arrow going from the Analyze Risks process to the Monitor & Control Risks process. This is because, at the end of our analysis we will create a “Watchlist” which contains the list of low priority risk items which we feel are not significant at this juncture. So, we send this watchlist to the Monitor & Control Risks so that we can keep an eye on these low priority items.

Another thing you might have noticed in the image is that, you can see arrows going from both the Monitor & Control Risks process as well as the Respond to Risks process. This means that the risk analysis process is iterative and happens multiple times during the course of a projects risk management activities.

Are you wondering if both Qualitative & Quantitative analysis happen for all risks?

If you are, the answer is No. Not all risks go through both analysis phases. We typically first do the Qualitative Risk Analysis and if we need to analyze it further we send it to the Quantitative Risk Analysis process. Look at the image below:

Once Quantitative Risk Analysis is complete, the output of the overall analysis is sent to the Respond to Risks process. Let me repeat – NOT ALL RISKS ARE ANALYZED BOTH QUALITATIVELY AND QUANTITATIVELY.

The PMBOK says that if we need any further details while formulating responses for the risks in the Respond to Risks process, we can send those risks back to the risk analysis process. Remember that I said risk analysis is iterative just a few paragraphs ago?

Look at the picture below:

Lower priority risks are usually put into a watchlist and sent as input to the Monitor & Control Risks process where they will be constantly monitored to ensure that their priority or impact hasn’t changed since we put them there. This is done to ensure that, any changes to the probability or impact or priority of the risk does not take the project by surprise.

To Summarize – A Standard Risk Analysis model will involve the following steps:

1. First you Assess the risks
2. Then you prioritize them
3. Then you determine which risks are urgent
4. Then you determine which risks are low priority and need to be placed in a watchlist
5. Then you analyze certain high priority risks on a numerical level (Quantitative Risk Analysis)
6. Then you determine the probable outcomes of those risks that you analyzed quantitatively and plan a response for those risks.

This is just a high level overview of the risk analysis model. We will be covering more details of the individual steps of risk analysis in the subsequent chapters & sections

Prev: Goals & Benefits of Risk Analysis

Next: Risk Analysis & Project Management

Goals and Benefits of Risk Analysis

Risk Analysis as you might have seen in the previous chapter is very vital to efficient project risk management and as you might have guessed will have loads of benefits. The purpose of this chapter is to elaborate on Goals and Benefits of this process.

Goal of Risk Analysis

The goal of risk analysis is to analyze a risk and gather more information about the risk like its probability, impact, priority etc. so that we can appropriately address them.

The above is a very generalistic goal description of this process.

But, before we can analyze risks, we must first define the standard for risk impact and probability. This activity is called Risk Assessment. Everyone in the team including the stakeholders must be on the same page on how we gauge a risks probability or impact. We should not proceed to the risk analysis stage without this information.

Trivia:

I have used the term “Should Not” instead of “Cannot” in the previous statement about proceeding to risk analysis without risk assessment. Are you curious why I did that? Well, you can always proceed to risk analysis without this information. Nobody can stop you. But, how effectively you can analyze risks without this information is a very big question mark here. That is why I have said “Should Not”

Since Risk Assessment is a distinct subset of this risk analysis activity, let us first take a look at its benefits and then we will list down the benefits of risk analysis.

Benefits of Risk Assessment:

1. Allows the risk management team to focus on higher priority risks
2. Makes sure that everyone is on the same page in terms of dealing with risks
3. Forces organizations to define the guidelines for risk assessment and analysis
4. It considers risk impact and probability jointly
5. Etc.

Benefits of Risk Analysis:

The benefits of Risk Analysis include everything we saw as benefits of risk assessment plus

1. Provides clarity on the damage or the opportunities about the risk
2. Increases the confidence level of the team in dealing with risks
3. Arms us with enough information to deal with those risks in the best possible way
4. Allows us to control risks with a greater success rate
5. We can take better informed decisions about handling risks
6. We can create better responses for the risks
7. Helps us foresee what may happen in future which can help us decide better
8. Etc.

Do you remember that I talked about “Uncertainties” and their correlation to risks in one of our earlier chapters titled “Managing Uncertainty”? Uncertainties directly result in risks. Risk Analysis deals with reducing this uncertainty by analyzing and identifying more and more information thereby reducing the uncertainty about things which in turn reduces the risks.

Prev: Introduction to Risk Analysis

Next: Overview of a Risk Analysis Model

What is Risk Analysis?

In the previous sections we have taken a detailed look at the Risk Management Plan, Risk Register and almost everything else that you do in the starting stages of your projects risk management. You have identified the risks and have communicated it with your stakeholders. So, as per the risk management process flow, what will you do next?

“Analyze those Risks”

People easily confuse risk analysis and risk management. They think that analyzing risks is all risk management does. Unfortunately, they fail to realize that analyzing risks is only a part of risk management and there are a lot of activities after we actually finish analyzing the risks. In a majority of cases, people don’t do any dedicated risk management activity at all. So, I would say that, those who confuse these two activities and at least do perform risk analysis are better than those who don’t perform any risk management activities at all.

What is Risk Analysis?

If you ask this question to someone who has been working on multiple projects in their career, the will answer in either of the below ways:

a. It involves numerical analysis
b. It heavily revolves around the risk’s impact and probability
c. It requires expert judgment
d. It relies on stakeholder tolerance of risks
e. Etc.

Actually speaking all of these responses above is correct.

Yes, risk analysis involves numerical analysis. The person is probably referring to the Quantitative Analysis part of risk analysis. During the course of risk analysis we are always concerned about the chances as to whether a risk will happen or not and the impact of a risk if it happens. So, point no.2 is right as well. The whole risk analysis activity is not stand-alone. The project or the risk manager cannot do risk management by himself. He will enlist the help and expertise of SMEs both internal and external to the organization (as required) along with the help of risk experts who may be either within or outside the project. So, all in all, the whole risk management activity utilizes the expertise of numerous experts and hence point no.3 is right as well.

All said and done, the analysis we do and the steps we take to manage risks will all be guided by the “Stakeholder Risk Tolerance”. If your project sponsor or customer is old-school and doesn’t like taking chances, then in all probabilities you won’t be taking any major risks in your project. So, point no.4 is correct as well.

Risk Analysis typically involves:

a. Risk Identification
b. Risk Assessment and
c. Numerical Analysis of Risks

In the previous chapters we learnt about the creation of the Risk Register and the Risk Management Plan. Do you remember that the Risk Management Plan contains the Probability & Impact Matrix? This probability and impact matrix will be used in risk analysis. It is those risks that we identified and added to the Risk Register that will be analyzed in this stage. Risk Analysis tells us what areas of the project are prone to be affected by risks. It guides us in developing better responses. It also helps us understand which risks require a response, if so when along with details on how drastic a response is required for the risk. Unless we do proper risk analysis, there is no way we can come up with a proper response that can actually help us manage the risk.

Prev: Section Summary - Communicating Project Risks

Next: Goals & Benefits of Risk Analysis

Section Summary – Communicating Project Risks

In the previous few chapters in this section we learnt about project risk communication process. Let us now quickly summarize what we have learnt so far.

• After we identify risks, the next logical step is to communicate those identified risks to all stakeholders and this is the purpose of this communicate project risks process
• Though project communications management is not directly a part of project risk management knowledge area, communicating risks and regular updates to all key stakeholders is an integral part of risk management
• Psychological factors can influence peoples attitude towards risk which in turn can affect their risk tolerance
• Peoples risk attitudes can be broadly classified into 4: Risk Averse, Risk Tolerant, Risk Neutral and Risk Seeking
• People usually resist change (risks) when it threatens their level of comfort or control or if they are unfamiliar with the change
• Risk Tolerance is defined as the degree, amount or volume of risk an individual or organization will withstand
• The Stakeholder Register and Stakeholder Management Strategy can help us greatly in managing stakeholder expectations in terms of risk communications
• We cannot please or satisfy all stakeholders. So, a smart manager will classify stakeholders and identify the high influence/power category and keep them satisfied as much as possible
• Most stakeholders will require only high level information
• The information that we share with different categories of stakeholders will depend on their interest in the project, influence on the project and a variety of other factors. Simply put “Not everyone wants everything”
• Risk Management Plan usually contains templates and reporting formats that we must use for the different categories of stakeholders

Prev: Communicating Risks to Stakeholders

Next: Introduction to Risk Analysis

Communicating Risks to Stakeholders

So far, in the previous chapters, we learnt about risk attitudes and have analyzed the stakeholder risk tolerance. So, the next thing for us to do is “Start communicating” to keep our stakeholders informed of the project progress in terms of risk management.

The PMBOK guide defines a separate process that covers the topic of Managing Stakeholder Expectations. This topic was covered in our PMP prep series in a chapter with the same title Managing Stakeholder Expectations. If you check this process, you will see that the Communications Management Plan which is the output of the Planning Project Communication process is an input. This communications management plan is going to define how we are going to communicate with all our stakeholders.

If you are wondering how, then maybe you forgot about the contents of the communications management plan. I suggest you go back to the chapter on Planning Project Communication and revise the contents of the same. The communication management plan contains stakeholder communication requirements which we will be using along with the Stakeholder Management Strategy to effectively communicate about our project risks.

Most stakeholders will require only high level information regarding risks. They will be typically looking for information like:

a. How accurate the presented information is?
b. Whether there is a potential for gain or loss?
c. Can the risk be managed?
d. What are the recommended responses?
e. What is the impact?
f. Etc.

Along with the above mentioned information you must also be able to provide certain additional information like:

a. Who holds the responsibility for the risk and the related events if the risk were to occur?
b. How often will the risk event occur?
c. What alternates do we have?
d. Etc.

But, as with every communication, there is a problem here. Not everyone wants everything. This is where the Stakeholder Management Strategy and the Communications Management Plan come to our rescue. In these documents we contain details like “Who needs what information” and using that we can try to cater to the varying needs of the different stakeholders in our project.

One last thing about communicating project risks is that, the Risk Management Plan usually contains templates and reporting formats that we must use for the different categories of stakeholders. So, we need to take that into account and ensure that the right reports are sent to the right target audience.

Prev: Stakeholder Risk Tolerance

Next: Section Summary

Stakeholder Risk Tolerance

In the previous chapter we learnt that psychological factors can affect an individual’s attitude towards risk. This attitude directly influences their risk tolerance and as part of managing our project risks, we need to understand stakeholder risk tolerances effectively in order to do our jobs well.

According to the PMBOK guide

Risk Tolerance is defined as the degree, amount or volume of risk an individual or organization will withstand

Simply put, the more risk tolerant you are, the more risks you will take. You can understand this concept of risk tolerance with a real life example. Let’s say that you and I are planning to invest 10,000 dollars each in some stock. The world renowned billionaire Warren Buffet too plans on investing 10 million dollars on the same stock. After a month we see that the stock price has tanked by over 50% and our investment is worth less than 5000 dollars. Can we afford this loss? Probably not because we don’t have millions of dollars of cash in our vault and this 5000 dollars is a lot of money for us. Whereas, Warren Buffet can afford to lose this 10 million dollars probably a 100 times even before he starts to feel money missing in his cash pile… So, we have a much lower financial risk tolerance than Mr. Buffet. Similar to this, every individual has a different level of tolerance when it comes to project risks as well.

Depending on the risk tolerance of our key stakeholders and the risk tolerance of our organization, as project managers we can decide on the level of risks/threats we take in our project. Existing information about stakeholder and organizational risk tolerance can be found in the following places:

1. Enterprise Environmental Factors – Org standards and strategies can give us a fair idea of our organizations risk tolerance
2. Organizational Process Assets – Documents from previous projects like the Lessons learned document or the Risk Management Plan or the Risk Register of a previous project can give you a very good idea of the risk tolerance of both the organization as well as certain key stakeholders

It is important that we understand the stakeholders risk tolerance well because of the following reasons:

1. It helps to correctly assess risks
2. It helps to correctly determine the priority levels of risks
3. It helps to develop contingency plans & reserves
4. It helps to quantify the cost & time contingency reserves
5. It helps to develop acceptable risk response plans
6. It helps monitor risks

So, by now you have got a good understanding of the fact that knowing stakeholder risk tolerance is vitally important in managing our projects risks. So, the next question that must arise in our mind is “How will we assess stakeholder risk tolerance?”

A part of the answer was covered in just the previous paragraph. Enterprise Environmental factors and Organizational Process Assets can help give you a fair idea of the risk tolerances of the key stakeholders and your organization as well. But, where can we find the comprehensive information on this subject?

The full answer is as follows:

During the Project Initiation Phase, we did some activities that fall under the “Project Communication Management” knowledge area which created two important artifacts that will contain extensive information about all stakeholders and their risk tolerance. Those documents are:
a. Stakeholder Register and
b. Stakeholder Management Strategy

The processes that helped us create these documents are:

1. Identifying the Project Stakeholders
2. Stakeholder Analysis and
3. Stakeholder Management Strategy

To Summarize:

The stakeholder register contains the following information about all stakeholders:

1. Identification Information – Things like name, designation, project role etc.
2. Assessment Information – Their primary expectations, requirements, influence levels, what they want, who they are etc.
3. Stakeholder Classification – Classification based on whether they are Internal or External to the Organization/project. Or based on their support level of the project etc.

The Identifying the Project Stakeholders process is going to create this document that will contain the list of all possible stakeholders in our project.

“YOU CANNOT PLEASE OR SATISFY EVERYONE”

Don’t forget the above saying. It is just a general saying but it is 100% true from a Project perspective as well. The everyone in the above statement refers to the project stakeholders. So, essentially we mean here that, we cannot possibly please or satisfy all our stakeholders. But, our aim should be to please as many of them as possible starting with the most influential ones. If you were had to choose between pleasing either your team lead or the Program Manager of your organization who would you choose? Don’t worry, I already know the answer. The Program Manager wins hands down because he is the boss of your project manager who in turn is your team leads boss. So, you tried to please the more influential/powerful stakeholder. This is exactly what we try to do during our project as well. But, how will we know which stakeholder is more powerful or influential?

The Stakeholder Analysis process helps us with that. Based on the outcomes of our analysis we will create the Stakeholder Management Strategy which is going to contain the strategy of how we should go ahead and handle the various stakeholders in our project.

This strategy is vital for the Risk Communication process because, you cannot share everything with everyone. Every stakeholder has a certain information requirement and you can’t be sending out insignificant emails to senior management. The stakeholder management strategy is going to help us with this so that we share only what is required and asked for by each stakeholder.

Last but not least, understanding stakeholder requirements is critical to the success of the Project. So, don’t overlook this activity.

Prev: Psychological Factors that affect Risk Communication

Next: Communicating Risks to Stakeholders

Factors that Influence Risk Communication

Before we actually start communicating about risks to our stakeholders we need to first understand the factors that can influence this whole activity of Risk Communication. They are:
a. Risk Attitudes and
b. Psychological Factors

Let us take a look at each of these one by one.

Risk Attitudes

Risk Attitudes refer to the individual’s attitude towards risk. The term risk here not only refers to project risks but also those daily risks that we may face in real-life. The whole idea here is to correlate an individual’s attitude towards risk and the influence it will have on the risk communication activity.

In General:
a. A Majority of the people resist change and
b. People usually over-estimate an unfamiliar risk

Given these two facts, it becomes extremely important that, as project/risk managers we factor in these considerations before we actually start managing risks in our project.

You may be wondering why we are worrying so much about people’s risk attitudes. Are you? If so you will be surprised to know that “Risk Attitudes are directly intertwined with Stakeholder Risk Tolerance” and this is exactly why we are talking about risk attitudes. Effective Risk Management involves dealing with stakeholder risk tolerances which means that that you should understand and know the needs of your stakeholders and influence them accordingly.

People’s risk attitudes can be broadly classified into 4 categories. They are:

1. Risk Averse – These are people that are uncomfortable with any form of risk and try to stay away from risks as much as possible
2. Risk Tolerant – These people are generally not concerned about risks and they don’t allow risks to influence their decision. But, they become surprised when the risk becomes an issue. (Remember the term issue we introduced in the chapter on Important Risk Related Definitions)
3. Risk Neutral – These people embrace risks and look at them as potential opportunities if they have something to gain out of the risk situation
4. Risk Seeking – These people view risks as a challenge and actively look forward to taking risks. These people are the total opposite of the Risk Averse category.

The stakeholders in your project could fall under either of the above 4 categories and as you must have guessed by now, a strategy you can use to satisfy a risk seeking stakeholder will totally back-fire if you try the same on a risk averse stakeholder. So, as the risk managers of the project, it is our responsibility to carefully classify our stakeholders and communicate with them as required. Remember “One Universal Communication Idea” will never work when your stakeholders fall have varying levels of risk tolerance.

Psychological Factors:

Psychological factors are actually the factors that influence how people view or react to risks. In other words, the psychological factors directly influence peoples risk attitudes. Unfortunately this information is not readily available. But, in order to be successful in our job we need to try to gauge the risk attitude of at least the important and most influential stakeholders.

Some psychological factors that might influence people and their risk attitudes are:

• People usually resist change when it threatens their level of comfort
• People usually resist change when they feel they are entering unfamiliar territory
• People are influenced by whether this risk may affect their level of control
• People are influenced emotionally when something brings about a feeling of dread or uncertainty (even if they are misguided)

Different people react differently under the same scenario. Especially when there is loss of control or unfamiliar territory involved. In some cases people’s behavior may be because of a misguided understanding of the risk which has caused an incorrect or unwarranted fear. We need to try to build trust with stakeholders. If we improve their level of trust on us and increase their level of familiarity on the project, it would be easy to explain the various scenarios you may encounter in your project. After all, a well-informed stakeholder who understands the project well and trusts the project manager can always tolerate more risks than one that doesn’t have a clue on what is happening in the project and doesn’t know much about the PM as well.

Prev: Overview of Communicating Project Risks

Next: Stakeholder Risk Tolerance

Overview of Communicating Project Risks

In the previous section we covered the “Risk Identification” process in our Risk Management Framework. So, you have identified all the risks that can impact your project. What would you do next?

Take a moment and think logically before you read on…

After we identify all possible risks that may affect our project, the next logical step would be communicate to all people involved in our project that we have identified risks and here they are. Isn’t it?

This is exactly what we are going to cover in this section which deals with “Communicating Project Risks”.

Do you remember that we spoke about Risk Tolerance in one of our earlier chapters? If a project or organization is tolerant to risks, then they tend to take up high-risk activities whereas if the tolerance is low, only guaranteed outcome activities are taken up. Part of being an effect project manager as well as a risk manager is, understanding the stakeholder risk tolerance and the organizational risk tolerance. Though stakeholder risk tolerance and organizational risk tolerance can have a great deal of impact on your day to day decisions, do you think that your own risk tolerance will not play any part in those decisions? Well, if you thought so, am sorry to say that you are sadly mistaken. No matter how hard we try to concentrate on the stakeholder or organizational risk tolerance, unconsciously we will let our own tolerance levels to influence our decisions at least to a slight level. So, it is important that we gauge our own tolerance levels up front to avoid any surprises…

Trivia:

Analyzing our own risk tolerance is not part of the RMP Exam syllabus and nor is it covered in this blog. It is just something I thought you should know because it plays a decent role in our decisions and is something many people overlook as a non-existent factor.

Factors that Impact Risk Communication

Risk Communication is a fairly complicated topic because there is no set baseline as to what is or is not part of communication. One of the senior managers in my company once told me “The job of a PM is 80% communicating and 20% everything else”. Something that is so critical always has factors that impact it and risk communication is no different. The factors that can impact the communication of risks are:
a. Risk Attitudes and
b. Psychological Factors

Before we can go any further, I want to quickly provide a few pointers about the Communications Management knowledge area.

Though Project Communications Management is not directly part of the Risk Management knowledge area, communicating risks and regular updates to stakeholders is an integral part of risk management. So, it is extremely important that we have a good understanding of the communications management knowledge area. So, I suggest you go through all the topics related to project communications management in the PMBOK at least once before you finish your RMP Exam preparation. You can also revisit the chapters that were focusing on communications management during our series on the PMP Exam preparation. They are:

1. Project Communication
2. Planning Project Communication
3. Project Communications Management as part of Project Initiation
4. Communications Management as part of Project Planning
5. Communications Management During Project Execution
6. Communications Management during Monitoring & Controlling the Project

Armed with all this information, let us now dive into the factors that affect risk communications one by one.

Prev: Section Summary - Identify Risks

Next: Factors that Influence Risk Communication

Section Summary – Identify Risks

In this section we took a detailed look at one of the key activities in project risk management which is “Risk Identification”. Let us quickly summarize what we have learnt so far:

• The purpose of the risk identification process is to identify all possible risks that can affect our project
• The outcome of this step is the Risk Register
• Documents and artifacts that contain details reg. the project are one of the key inputs to this process along with the Risk Management Plan which outlines how we are going to conduct this activity
• Uncertainties are sources of risks and in this step we are going to analyze every aspect of the project to uncover those uncertainties
• There are 7 different tools & techniques that we can use in this risk identification process. They are:

o Documentation Review
o Information Gathering Techniques
o Checklist Analysis
o Assumptions Analysis
o Diagramming Techniques
o SWOT Analysis and
o Expert Judgment

• Information Gathering Techniques include – Brainstorming, Delphi technique, Interviewing and Root cause analysis
• Diagramming Techniques include – Cause & Effect diagrams, flowcharts, influence diagrams etc.
• SWOT Analysis intends on analyzing our project from the different perspectives like Strengths, Weaknesses, Opportunities and Threats to widen the reach of risk identification
• The 7 basic tools of quality are not directly part of the PBMOKs list of tools that we can use in risk identification but they are very relevant both from proper risk management perspective as well as the RMP Examination perspective
• These 7 basic tools of quality are:

1. Cause & Effect Diagrams
2. Control Charts
3. Flow Charts
4. Histograms
5. Pareto Charts
6. Run Charts and
7. Scatter Diagrams

Prev: Other Tools & Techniques

Next: Overview of Risk Communication

Other Tools & Techniques we can use in Risk Identification

In this section we set out with the idea of looking into the Risk Identification process. We saw all the inputs used in this process and then on the chapter on tools and techniques we saw that 7 different tools will be used and we covered them all one by one. At this point in time, you must be wondering that, we listed down 7 tools and we covered them all. So what is the purpose of this chapter?

Do you remember that I used the term “7 basic tools of quality” a few chapters ago? We use these tools in the “Perform Quality Control” process of the PMBOK guide and we covered them in the chapter on Controlling Quality in our PMP Exam Prep series. All of these 7 tools, though primarily used in quality control can also help us in Risk Identification as well as Risk Management. That is exactly why we have this chapter. These 7 basic tools of quality are:

1. Cause & Effect Diagrams
2. Control Charts
3. Flow Charts
4. Histograms
5. Pareto Charts
6. Run Charts and
7. Scatter Diagrams

I repeat – these are called the 7 basic tools of quality and are featured here because they are relevant from both an overall understanding of risk management perspective as well as from the RMP Exam perspective. We have already seen the cause & effect diagrams and flowcharts. So, let us quickly cover the basics of the rest of these tools.

Control charts

Control charts gather data to show when a process experiences an out of control condition. These are called “Special Cause Variations”. Basically we will use the control chart to determine whether a process is stable with predictable performance or not. It helps us understand how a process performs/behaves over time. Ideally we would expect a process to be stable and consistent and the control chart can help us confirm the same.

A typical control chart has 3 lines:
a. The Mean or Median line
b. The Upper Control Limit or UCL
c. The Lower Control Limit or LCL

Data points are gathered and plotted within these 3 lines. If all your data points lie between the UCL and the LCL then you can safely assume that your process is “In Control”. Every process will always have some variance and it is inevitable but, as long as all our data points lie within the control limits then we are good. If you see no variance and all points lie on the median, then either the data collection was wrong or something else is majorly wrong which is yet to be identified. There is no way that all data points lie on the median line.

The difference between the UCL/LCL and the mean is called the sigma value of the project. In other words it signifies the level of quality in the project. Don’t worry too much about sigma right now. Just know that higher the quality the better it is. If you are really keen on understanding about Sigma values and better quality, to visit the blog on Lean Six Sigma quality improvements.

Spotting a process that is out of control (cases where the data points are either above the UCL or below the LCL) is critical. There could also be cases where all data points are within the UCL and LCL but still the process is out of control. Those cases are identified using the “Rule of 7” wherein if 7 consecutive points fall on the same side of the control chart then it suggests that something is wrong and needs to be investigated.

Look at the sample control chart above. There is a data point above the UCL and one below the LCL which signifies that this process id definitely out of control. By analyzing the control chart we can identify potential risk points. If a process is in control then practically speaking we need not do anything. But, if it is out of control then we definitely need to take remedial actions.

Histograms

A Histogram shows a distribution of variables in a bar-chart format. Each column represents an attribute or characteristic of an issue. The histogram usually shows a frequency of distribution for a set of measurements. Look at the sample histogram below:

As you can see, the frequency of occurrence of various issues is plotted in a bar-graph format. The frequency of occurrence is visible in the height of each of the bar. A sub-set of histograms known as the “Pareto Charts” are widely used in risk management which is what we are going to cover next.

Pareto Chart

A Pareto chart is a type of histogram where the bar-chart is ordered by the frequency of occurrence. It can easily help us identify those issues that have the highest frequency. Look at the sample Pareto chart below:

Here as you can see, the occurrences due to the “Slow Page Load” problem result in “Page Errors” the most number of times and then the other outcomes too are plotted based on the number of occurrences. So, if I were in-charge of quality or risk for this project I would probably concentrate on the first one or two problems which should help be address a bulk of the issues.

Trivia:

Pareto’s law is something that is commonly used in quality parlance. It is also called the 80-20 rule which says that 80% of the problems are because of 20% of the causes. So, if we address those 20% causes, we can eliminate 80% of the problems.

The idea behind Pareto Chart is similar. We want to concentrate on those issues that have the highest frequency so that we can nail those that can give us the most benefit.

Run Charts

A run chart shows a pattern or trends of variation over time. It also shows a history of declines and/or improvements within the process. The Run chart is nothing but a line graph that has data points plotted in the order of occurrence. It is used to monitor two main things:
1. Technical Performance – Ex: How many defects were identified & fixed in a time-period
2. Cost & Schedule Performance – Ex: Total no. of activities completed per time period without significant variances

Run charts are very useful in trend analysis which is a mathematical technique that is used to forecast the future outcome of the process based on historical information. These are extremely useful in risk analysis. Look at the sample run chart below:

Here we have plotted the number of times we had to perform an activity every month and seeing this we can safely say that trend here is improved performance and that the number of instances has steadily declined and is at a much lower level when compared to what it was at the beginning.

Scatter Diagrams

Scatter Diagrams show the pattern of relationship between two different variables. The purpose of these diagrams is to analyze the relationship between identified changes within the two variables. The dependent and independent variables are plotted on a graph with a diagonal line passing through. The closer the variables are to each other, the closer they are linked/related to one another. Look at the sample scatter diagram below:

Before we wrap up this chapter let me reiterate the fact that, you need not be an expert in these tools in order to pass the RMP examination. But, understanding them well is vital in being a good risk manager. So, take some time and understand them before proceeding further.


Prev: SWOT Analysis

Next: Section Summary

SWOT Analysis

In the previous chapters we took a look at the various diagramming techniques we utilize to identify risks. In this chapter we are going to learn about a technique that is extremely common and crucial in identifying the Organization level risks that may affect our project along with project level risks.

SWOT stands for:

S – Strengths
W – Weaknesses
O – Opportunities
T – Threats

SWOT Analysis intends on analyzing your project and organization from each of these perspectives to widen the reach of risk identification. SWOT Analysis typically goes through the following steps:

1. Identify Org/Project Strengths and Weaknesses
2. Identify Opportunities that arise as a result of the strengths
3. Identify Threats that arise as a result of the weaknesses
4. Examine the degree to which the strengths can offset the weaknesses

Practically speaking, these steps are done using a brainstorming session but let me add a caution here that, this brainstorming session is totally different than the one that we saw a few chapters ago. The purpose of that session was to identify project risks alone. The purpose/scope of this analysis/brainstorming is far wider than that. The main difference is that SWOT analysis can help uncover those risks that are generated internally within the organization along with the other project risks you may uncover from other areas of risk analysis and identification.

Look at the sample SWOT Analysis result below:

The Organization has many strengths like an experienced top management, quick hiring capabilities and a good pay structure. So, as a result of these strengths an opportunity is that, whenever a new project is to be taken up in short notice, the organization can do it because they have the capability to hire people quickly…

On the downside, the organization follows a heavy workload working culture along with low bench strength. So, the threats here are “Attrition possibilities” which is very common in high-pressure working culture environments. If attrition happens in a high scale, the organization may have to increase their pay packages in order to attract lateral hires at a faster rate.

Prev: Influence Diagrams

Next: Other Tools & Techniques we can use in Risk Identification

Influence Diagrams

In the previous chapters we took a look at Cause and Effect diagrams as well as Flowcharts. In this chapter we are going to cover the third diagramming method which is “Influence Diagrams”

Influence diagrams are diagrams that show potential influences that elements or situations in our project can have on one another. An influence diagram can show:

a. Causal influences
b. Time ordering of events &
c. Other relationships among variables and outcomes

Within our existing project decisions, we can determine where uncertainties exist based on the potential scenarios. You can compare these influence diagrams to a decision tree but they are slightly different. Using influence diagrams we can look at a situation and how a decision can be arrived. It can be used to identify the uncertainty in the potential paths as well as to identify potential risks.

Look at the image below which is a sample influence diagram

There are multiple boxes with arrows going from-to one another. An arrow starting at Economy and ending at Education signifies the fact that economy has an impact on education. So, more number of arrows arriving at a box means that it is impacted/influenced by many factors. Similarly, more number of arrows starting from a box means that it impacts/influences many factors.

If there is a problem in the Economy it can impact almost every aspect in this influence diagram. So, a hiccup in the economy may cause uncertainties in every aspect of this situation which is a potential risk which we can identify based on this diagram.

An important point here is that, the example above is just a general one and does not deal with any specific project or its risk. The influence diagrams we may end up creating/using for our project will all be concerned with risk management only. After all, that is the whole purpose of this RMP certification isn’t it?

To Summarize – Influence Diagrams:

• Are diagrams that show potential influences that elements or situations can have on one another
• Reflect relationships among variables and their outcomes
• Can be used to view the order of potential events
• Help to spot uncertainty and therefore potential risks
• Are used to make decisions

Prev: Flowcharts

Next: SWOT Analysis

Process Flow Charts

In the previous chapter, we learned about the first diagramming technique that we can use in risk identification which was “Cause & Effect Diagrams”. In this chapter, we are going to look at the second diagramming technique that will be very useful in risk identification. It is called “System or Process flowcharts”

Just like the Cause & Effect diagram, the process flow chart too is part of the “7 basic tools of quality” that are 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.

A flow chart is a graphical representation of a process from the beginning to the end including order of processing, decision points etc. it shows us how the various items in a system are interrelated. Using this information we can analyze as to how a problem may have occurred. Once again, we are going in search of the problem causes as a way of resolving them along with preventing any such issues in future. The Risk Management team will take this flowchart and analyze it find out where a risk may occur and based on that information we try to figure out the root cause. Another important use of these flowcharts is that, they can also help us in identifying potential responses.

Let us look at a real life example as to how a process flow chart can help us nail a risk and its cause. Let’s say you are going to paint your house and the last two times you did, the paint started peeling off within months and by the end of 2 years it looked as though there was literally no paint on the wall. So, if you want to paint your walls again there is an imminent risk that the paint is going to peel off again. Isn’t it?

Let’s create a flowchart of the whole painting process. By analyzing the flowchart, we can pin-point two problem areas that might result in our risk which are highlighted by the red ovals around them.

As you can see, this paint peeling off can happen if we did not clean the painted surfaces properly or if we did not scrape off all the old paint. After we identify the cause we can even create a potential response that says that we must clean the paint surface and scrape off all old paint before beginning the paint-job.

Can you understand how useful this flowchart analysis can be now?

Prev: Cause & Effect Diagrams

Next: Influence Diagrams

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