Section Summary – Output of Plan Risk Responses

In this section we learnt about all the outputs of the plan risk responses process. Let us quickly summarize what we have learnt so far. 
• During the Plan Risk Responses process we formulated possible responses we could use to handle the risks identified in our project
• The following are the outputs/updates generate by this process: 

o Updates to the Project Management Plan
o Updates to the Risk Register
o Updates to Project Documents and
o Updates to Risk Related Contract Decisions

• The Risk Register is updated extensively during this process. We will be updating it with the response that has been agreed upon by the risk management team against each risk
• The owners of the risk, the symptoms & warning signs, budget & schedule requirements etc. are updated for each risk too 
• Fall back plans and contingency reserves formulated and updated 
• The following subsidiary plans in the Project Management Plan too will get updated as a result of this process: 

o Schedule Management Plan
o Cost Management Plan
o Quality Management Plan
o Procurement Management Plan
o Human Resource Management Plan
o Work Breakdown Structure 
o Schedule Baseline
o Cost Performance Baseline 

• The typical updates to general project documents that might result as an output of this process are: 

o Updates to the Assumption Log and 
o Technical Documentation Updates 

• Whenever a third party is involved in our project, it would be a prudent idea to sign a formal contract to ensure that both the vendor (providing us with the service) and our team know what is expected out of one another
• The purpose of the plan procurements process is to document project purchasing decisions including approach, identify potential sellers, types of contracts to use etc.


Prev: Risk Related Contract Decisions

Next: Monitor & Control Risks - An Introduction

Risk Related Contract Decisions

In the plan risk responses process, we covered the strategies we would use to handle negative and positive risks. In those response strategies, one of them was “Transfer” for Negative Risks and “Share” for Positive Risks. In either case we are going to involve a third party to handle the risk. In fact, even in case of Mitigate as a strategy for negative risks, we may involve third party to minimize the effects of a risk.

So, whenever a third party is involved in our project, it would be a prudent idea to sign a formal contract to ensure that both the vendor (providing us with the service) and our team know what is expected out of one another. This process of involving a third party vendor to share some part of our project work is achieved using the “Procurement Management” knowledge area.

The processes in the Procurement Management Knowledge Area that we will use are:
a. Plan Procurements
b. Administering Procurements
c. Conducting Procurements
d. Closing Procurements

It would be a good idea to revise the above 4 chapters and/or read the Procurement Management knowledge area of the PMBoK Guide once before the exam as there maybe a few questions from this area. For your quick review, I have summarized the process below.

Plan Procurements:

• The purpose of this process is to document project purchasing decisions including approach, identify potential sellers, types of contracts to use etc.
• The output of this planning process is the Procurement Management Plan
• A Statement of Work (SoW) is created outlining the scope of work that needs to be executed by the third party vendor
• Make or buy decisions are made
• Source selection criteria are defined (Based on which a vendor will be chosen)
• All documents related to Procurements are created
• At the end of this step, we are all set to actually transfer/share the subset of project work to the vendor

The inputs used in this process are:

• Scope baseline
• Requirement documents
• Teaming agreements
• Risk register
• Risk related contract decisions
• Activity resource requirements
• Project schedule
• Activity cost estimates
• Cost performance baseline
• Enterprise environmental factors and
• Organizational process assets

The tools and techniques used in this process are:

• Make or buy decisions
• Contract types
• Expert judgment

It would be a good idea to revise the 4 chapters on Procurement Management in this blog and/or read the Procurement Management knowledge area of the PMBoK Guide once before the exam as there maybe a few questions from this area

Prev: Updates to the Project Management Plan

Next: Section Summary

Updates to the Project Management Plan and Other Project Documents after Risk Response Planning

In the previous chapter, we took a detailed look at all the updates that happen to the Risk Register as a result of the risk response planning activity. In this chapter we are going to take a detailed look at the updates to the Project Management Plan. 

If you are a Project Manager by profession or have finished the PMP Certification already, you must have a very clear idea of what this Project Management Plan is. It is the heart of any project and contains details reg. almost anything and everything that is happening in our project. Though the title says updates to the project management plan, we will be covering updates to its subsidiary plans in this chapter as well. 

Updates happen to the Project Management Plan directly as a result of the Plan Risk Responses process. 

Trivia:

Are you wondering why the PM Plan would get updated as a result of planning responses to our risks? Think of it this way – if you have to handle a risk, you need to implement a response. To implement the response you need to spend time, resources (people) as well as cost. Technically speaking, any activity or work done by our team resources must be captured in the PM Plan including the time and cost spent in it. So, your risk response planning activity directly will cause updates to the PM Plan. Get the picture??? 

The following are the updates that happen to the Project Management Plan as a result of Risk Response Planning: 

• Agreed upon actions submitted into Integrated Change Control process, to be mentioned and traced as the project progresses
• Risk Response Strategies are fed into the impacted project management processes – esp. the schedule and cost related processes 

The following subsidiary plans in the Project Management Plan too will get updated as a result of this process: 

• Schedule Management Plan
• Cost Management Plan
• Quality Management Plan
• Procurement Management Plan
• Human Resource Management Plan
• Work Breakdown Structure 
• Schedule Baseline
• Cost Performance Baseline 

Trivia: 

Updates to subsidiary plans related to cost, time and quality are straight forward to understand. Can you guess why the Work Breakdown Structure would get affected? 
Remember that, if you try to memorize all these updates, chances are that you won’t be able to recollect them easily in future. Understand the purpose of the activity and its impact to easily recollect these things in future. 

Updates to Project Documents 

Apart from the Project Management Plan, there are many other project related documents that may get updated after we finish planning responses to the identified risks. Whatever actions we have formulated to handle risks must be updated in the respective plans and documents. Just because we are not updating a high profile document named a Risk Register or a Project Management Plan does not mean that we can take this set of outputs lightly. Any update, no matter how trivial it might seem must be documented and stored appropriately for future reference. The typical updates to general project documents that might result as an output of this process are: 

• Updates to the Assumption Log and 
• Technical Documentation Updates 

Trivia: 

A lot of people think of the Project Management Plan, as soon as we use the term “Project Documents”. In fact, if you say updates to project documents, people invariably assume that you are updating the PM Plan. Unfortunately project documents are a totally different set of documents. If you want to know the difference between the PM Plan and project documents, refer to Page 350 of the 4th edition of the PMBOK Guide 

Updates to the Assumptions log: 

Assumptions are a major source of risk to any project and we know that right? Assumptions can result in uncertainty which can directly result in risks. As we complete analysis and gather more and more information, many of the initial assumptions that were made during the start of the project may seem irrelevant now. When we started planning, for all practical purposes, we assumed that they were true. But, by this stage in our planning (after completing risk response planning) there would be a lot of clarity as to whether those assumptions still hold good or not. Any changes to the status of the assumptions must be updated into the assumptions log for future reference. 

Technical Documentation Updates: 

As we implement responses, we may make changes to the project deliverables, technical approaches etc. all these must be captured accurately for future reference. All documents related to the technical aspects of the project like WBS, Technical Design etc. must be kept up to date at all times. 
Lastly, every organization will refer to documents by different names. Remember to follow your organizations standard while tracking and updating your project documents.

Prev: Updates to the Risk Register

Next: Risk Related Contract Decisions

Updates to the Risk Register – After Risk Response Planning

In the previous chapter we took a high level look at the possible updates that could be created by the Risk Response Planning process to the various project documents. In this chapter we are going to take a detailed look at all the updates that happen to the Risk Register.

The following are the updates that happen in the Risk Register:

1. Agreed Upon Risk Strategies

These are the strategies that will be utilized to handle the risks that are outlined in the Risk Register. Strategies for both negative and positive risks are available here. Remember the strategies – Avoid, Mitigate, Exploit etc.?

Remember that the strategy we choose will depend on the stakeholder and project risk tolerance and threshold.

2. Risk Owners and Responsibilities

Every Risk must have an owner and this information is captured in the Risk Register. Note that here; we are not assigning owners for the activities that are taken up to handle the risks. Instead, we are talking about the person who is in-charge of the risk as a whole.

Trivia:

A large project could have hundreds of risks and assigning the same individual to track all of them may result in gaps that may hurt the project. So, it is a good idea to assign a manageable number of risks to each individual.

3. Risk Symptoms and Warning Signs

These symptoms and warning signs are also known as “Triggers”. It would be a good idea to document them so that we know when we need to respond to any risk. It also will help the team in responding to a risk if it materializes. Risk owners must stay on top of the triggers for their respective risks…

Trivia:

Without knowing the risk trigger, how will you or anyone respond to a risk???

4. Budget and Schedule Requirements

To handle a risk, some actions may be required from people in our team. So, that would involve spending time and money. The cost and time required to implement the risk responses must be outlined in the risk register.

5. Contingency Plans and Triggers

As explained in the chapter on Contingency Reserves, we accept a certain number of risks. Along with this, we also need to take into account all of the Residual Risks as well as those in the Watchlist. So, listing out those risks, their contingency plans as well as triggers that will cause us to use the contingency plan must be clearly specified in the risk register.

6. Time and Cost Contingency

By this stage in Risk Analysis & Planning, we must have a clear idea of how much reserves we need – in terms of time and cost to handle those risks that were accepted or residual risks or those from the Watchlist. During the Monitor & Control risks phase, we will keep a close lookout for risks during our project activities to ensure that we have enough reserves to handle the risks appropriately

7. Fall-back Plans

You might remember that a fall-back plan is the “Plan B” we are planning on executing if our original (Plan A) fails. So, noting this too in the risk register will be useful in future in the unfortunate event of our original plan failing.

8. Residual Risks

When we plan the responses for our risks, we will get a clear idea of any risks that may remain even after we implement our responses. These must be noted down clearly in the risk register so that we can utilize the contingency reserves to handle them appropriately in case they materialize in future.

9. Secondary Risks

Secondary Risks are those risks that are created as a direct consequence of us implementing our planned risk responses. If such a risk is caused by our response, we must make sure that they are also captured accurately in the Risk Register.

Remember that the Risk Register is the most up to date information of all risks that were/are/will be handled by the project. Any risk related activity either uses this document or results in updates to this document. So, keeping it accurate is vital for successful risk management in our project.


Prev: Introduction - Outputs of the Plan Risk Responses Process

Next: Updates to the Project Management Plan

Introduction – Outputs of the Plan Risk Responses Process

In the previous section we took a detailed look at the Plan Risk Responses process. We covered the inputs used by the process, the risk response strategies for negative risks and positive risks as well as other techniques used in the process like Contingency Reserves. Once all this is complete, just like any other process, a bunch of outputs are created by this process. Actually speaking this process creates nothing new but, it makes updates to a lot of documents related to our project.

The following are the outputs/updates generate by this process:

a. Updates to the Project Management Plan
b. Updates to the Risk Register
c. Updates to Project Documents and
d. Updates to Risk Related Contract Decisions

We are going to be covering each of these updates in details in the following chapters. For now, let us just take a high level look at the updates that this process causes in the Risk Register. They include:

a. Agreed upon response strategies
b. Risk owners and assigned responsibilities
c. Risk symptoms and warning signs
d. Required budget and scheduled activities to implement the risk responses
e. Contingency plans and triggers
f. Time and cost contingency reserves
g. Fallback plans
h. Residual risks
i. Secondary risks

So, at the end of this process, the risk register now contains:

1. List of Identified Risks including the risk owner, people responsible to implement the response, the response etc
2. A prioritized list of risks
3. Outputs of the qualitative and quantitative analysis

Prev: Important Terms - Plan Risk Responses

Next: Updates to Risk Register

Important Terms - Plan Risk Responses

The Plan Risk Responses process was fairly complicated and is extremely vital in successful risk management in our Project. So, before we move on to the next topic and start looking at the outputs of the process, let us quickly cover the important terms we learnt in this section. 

The purpose of this chapter is to prevent or rather avoid any confusion or misunderstanding to anyone who is reading this series because some of these terms may be quite confusing. 

Risk Triggers: 

• Are warning signs or symptoms
• Provide a warning that  a risk is about to occur
• Provides a heads-up to the risk management team to handle the risk
• Tells the team when to execute the risk response or contingency plan

Residual Risk

• Those risks that are expected to remain after the planned responses have been executed
• May include risks that have been accepted

Trivia: 

Even when a risk is accepted or placed in a watchlist, we must never forget them. They can be considered residual risks and must be handled as and when required.

Secondary Risks

• Those risks that emerge as a direct result of implementing a planned risk response
• It is not the same as a new risk that may be uncovered during the project’s life 

Fallback Plan

• Is planned in advance 
• Is used/implemented when the original planned risk response proves ineffective
• Is typically the “Plan B” in common lingo
• Is created typically for very high priority/impact risks to minimize impact in case the original plan fails
• Is created also for cases where we are not too confident about the response that has been formulated or about the impact of a risk 

Prev: Reserve Management

Next: Introduction - Outputs of the Plan Risk Responses Process

Reserve Management

One of the most important outputs of the Plan Risk Responses process is the creation of Reserves. The term Reserve is something that we use in our day to day lingo and hence most of us must be familiar with it. If you can’t exactly recollect what a reserve means, think of it as a “Buffer”. Now, are you able to figure out what a reserve could mean?

Definition of a Reserve:

A provision within the Project Management Plan that is meant to get in front of cost and schedule risks.

In other words Reserve refers to cost or time buffers that we will utilize if we fall back in schedule or overuse the available funding.

Trivia:

Reserves is something we use in real life even without explicitly knowing that we are using it. For ex: If your boss asks you for a report that you know will definitely need 9 days and may get extended by a few hours, you don’t tell your boss that you will give him by EOD 9th day. Instead you add a little buffer for safety and tell him that it will be done in 10 days to account for the risk of delay. In case your report isn’t ready by the 9th day, you utilize the 1 day extra you added to finish the report. As per proper project management practices, we are expected to inform our management of such reserves so that they will know that, unless required the reserve will not be used and the report will be available for them at the end of the 9th day if it is ready.

Definition of Contingency Reserves:

The amount of funds, budget or time needed above the estimate to reduce the risk of overruns of project objectives to a level acceptable to the organization.

Trivia:

When we use Accept as a strategy for risks, it means that we are planning to use these contingency reserves to handle them if the risk event occurs.

Realistically, we are going to use the reserves to handle the result or impact of whatever has happened as a result of the risk instead of trying to prevent the risk from happening or minimizing its impact. Though this may not sound like a bright idea – trying to address the situation after the damage has occurred, this is usually the response we give risks that are pretty low down in the priority list or those risks that have little impact but require a huge cost to address them. Remember the example from the last chapter where a $1000 damage required us to invest $5000 to prevent it?

Calculating Contingency Reserves for Risks:

The contingency reserve is technically the sum of the EMV of all the risks that have been identified. We multiply the probability with the impact (in $ terms) to arrive at the individual risk numbers and then sum them all up to come up with the overall Contingency Reserve for the Project.

Trivia:

If your project has 100 known risks each with a varied impact of losses, after you calculate the reserve number, you may begin to wonder if the reserve will be enough. Remember that not all of those risks are going to occur. Only a few of them will occur. If we consider the reserve requirements for all the risks, then it should be practically enough to handle the few risks that eventually materialize.

On important point we need to consider while coming up with these reserve figures is the “Stakeholder Risk Tolerance”. If your stakeholder has a low tolerance for risks, you may have to come up large reserves to minimize or nullify the impact of certain risks and vice versa. Once the numbers are calculated, they are updated in the Project Cost Baseline.

Trivia:

A lot of people think that the contingency reserves are not part of the Project Budget or the Project Cost Baseline. But unfortunately they are wrong. Contingency reserves are planned in advance and factored into the overall cost of the Project.

Management Reserves

The Management Reserves are for the management as the Contingency Reserves are for the Project Manager. The PM is managing only one project and hence has crated his contingency reserves. Whereas, the Organization Management is probably executing multiple projects and hence they will keep some sort of reserve in their end for emergency requirements.

Management Reserves are:
• Used for unknown-unknown risks
• Not part of the Project cost Baseline
• Approved by the Senior Management if any project needs to use it

The project manager does not know if any management reserves are present and if so how much. So, for all practical purposes, the PM has to work with the idea that his cost budget is final. Though the Management will be willing to pitch in when required, as PM’s it is our responsibility to come up with numbers that are accurate and going to the management stating that you have overrun your allocated budget makes you look bad because you messed up the calculation of budget figures during the planning phase of the Project.

Contingency Planning

Contingency Planning is one of the tools and techniques in the Plan Risk Responses process and is part of the Contingent Response Strategy.

While developing a response to a risk, we usually determine when the risk response should be implemented. For ex: When warning signs and symptoms occur we will apply the contingency plan to try to eliminate the risk, provided we have enough time before the risk actually occurs. The warning signs can also tell us if a risk has occurred. In such cases we will use the contingency plan to try to minimize the impact of the risk.

The Contingency Plan is:

• The planned response to a risk
• Executed when the predefined risk trigger occurs
• Part of the overall risk response plan
• Documented in the Risk Register
• Meant to offset a threat or an opportunity

Example:

As per the project schedule, you can see that Activity X in your network diagram is on the critical path and if we miss its deadline, the projects schedule milestone will be missed. In this case, a response is not required unless we actually miss the deadline for Activity X. If we finish activity X as planned, then we don’t need to utilize our contingency plan at all.

The actual response (from the contingency plan) may not be viable until the trigger event actually occurs. Think this way - Why would you want to apply a contingency plan when activity X is on track and will be completed on time? Responding to risks involves utilization of time and resources. So, the logic here is – why waste them when not required.

Prev: Strategies to Handle Positive Risks

Next: Important Terms - Plan Risk Responses

Strategies for Handling Positive Risks

In the previous chapter, we took a look at all the strategies we could use to handle Threats or Negative Risks. The next set of strategies we are going to cover are to handle Opportunities or Positive Risks. Before we begin, let me start off by saying that “Accept” is one of the strategies to handle opportunities and we already covered it in the last chapter. So, we will be covering only the other strategies we can utilize to handle opportunities. 

Trivia: 

Most project managers are accustomed to dealing only with negative risks or threats. In fact most managers don’t even consider opportunities as risks and hence don’t address them at all. If you want to capitalize on any good opportunities that may come up during your projects lifetime, you would not want to ignore this activity.

Just like for Threats, Opportunities too have multiple strategies. Let us look at them one by one. 

Trivia: 

Each strategy to handle an opportunity has a corresponding strategy to handle a threat. You can compare & relate them in order to understand them better. 

Exploit

Exploit is the opposite strategy of Avoid for negative risks. 

Definition: To Alter the Project in some way in order to make sure that the risk (opportunity) occurs 

Can you see that the definition is extremely similar to the Avoid strategy we saw in the previous chapter? Avoid was aiming at ensuring that the risk does not occur while Exploit is aiming at ensuring that the risk occurs. 

Why the difference – Because by avoiding the negative risk we are minimizing losses whereas by exploiting the opportunity we are maximizing gains. 

Pause for a moment and go back to the Performance Bonus example from the previous chapter. If you hired an additional guy in the team upfront before execution to ensure that your team finishes work by September that is referred to as exploiting the opportunity as a strategy

Just like the Avoid strategy, the exploit strategy results in changes to the Project Management Plan. If you have to hire and utilize an additional guy in the team that involves to changes to the Schedule Management Plan, Cost Management Plan, Human Resource Management Plan etc. Is this Right? 

Also, another important consideration here is that, the earlier we utilize this strategy the easier it is because, changes to the Project Management Plan are easier to implement and integrate during the planning or the early execution stages of the project when compared to when you are towards the fag end of your project. 

Share 

Share as a response to opportunities is similar to the Transfer strategy for handling threats. Here, a third party is involved and the responsibility of handling the opportunity is *fully or partly” given to them. 

Definition: To share the responsibility or ownership of the risk with a third party who is better able to take advantage of the opportunity

The idea here is to bring in someone else (mostly an expert from outside the team) on board, who is a specialist in the area in order to capitalize fully on the opportunity that has come up. Just like the Transfer strategy, we cannot ensure that the opportunity will materialize. Instead, we are just enlisting the help of someone who can improve the chances of the opportunity materializing because he is more equipped to deal with the situation than we are. 

Example: 
IT Outsourcing is a very common example where organizations share some responsibility in maintaining/developing their IT systems with IT consulting companies instead of doing it all by themselves. They do it because, in a majority of the cases, they do not have the capabilities in house to cater to their IT requirements. So, they share the opportunity with someone who can do it better than them. 

Just like with the Transfer strategy, a contract is usually created and signed by the involved parties in order to share the responsibilities. The contract will contain details on who is responsible for what and how much responsibility each party will own, plus the financial & timeline aspects as well. 

Enhance

The Enhance strategy is similar to the Mitigate strategy for threats. 

Definition: Increasing the probability and/or the impact of a risk. 

The resemblance with the mitigation strategy is striking isn’t it? There we tried to reduce the probability and/or the impact of the threat whereas; we are trying to increase them for this opportunity. 

Enhance is considered a more proactive and effective strategy than hoping that the opportunity occurs. Just like Mitigate, Enhance as a strategy when Exploit is not a feasible option. In this case we identify those factors that may result in the risk occurring and then try to maximize them. 

Example: 
Hiring a senior guy to the team may be a good way to enhance opportunities related to using latest technologies and improving project quality. But, this does not guarantee that fact. Isn’t it? 

As a general rule of the thumb with respect to all opportunities, we typically are forced to work within the projects scope, schedule and cost constraints. Only when the opportunity is large or its benefits are substantial that we actually change the project’s scope or schedule parameters to accommodate it. In majority of the cases, the original scope and schedule is rarely altered. 

Prev: Strategies to Handle Negative Risks

Next: Reserve Management

Strategies for Handling Negative Risks

In the previous chapter, we covered a high level overview of the tools and techniques that we would use in order to arrive at risk responses. The first of them being “Strategies for Negative Risks”

Before we can go ahead with strategies to handle negative risks, can you recollect what a Negative Risk is?

A Negative Risk or a Threat is something, as its name suggests, that could have negative consequences on our project. A delay in the project end date or a cost overrun or anything that could impact the project objectives could be considered a Negative Risk.

So, how would you handle such a risk? There are 4 strategies as outlined by the PMBOK Guide:

a. Avoid
b. Transfer
c. Mitigate and
d. Accept

Let us see what is meant by each one of these strategies mean…

Avoid:

As per the PMBOK, whenever possible and feasible, Negative Risks must be avoided. However, in real life it may not be feasible all the time. That is exactly why we have other strategies. Anyways, clarifying on the first statement, PMBOK does not say we must always Avoid risks, instead it says that whenever it is practically possible, we must choose Avoid as the strategy for our Risk.

Definition: Avoid is the strategy by which – We alter the Project in some way in order to remove or eliminate the risk altogether

Remember that this is easily possible if risks are caught early on the project life-cycle. The later in the project’s lifecycle a risk or threat is uncovered the lower are the chances of using Avoid as a strategy to handle it.

A Real Life Example: Let’s say you are just starting to work and turn on the radio of your car before starting. The guy on the radio says that the CTE (Central Expressway) is jammed due to a huge accident and traffic is extremely slow moving. You usually take the CTE to work. So, this is a potential risk that could delay your travel. But, now that you heard this, you change your route and took the PIE (Pan Island Expressway) thereby you avoided the “Risk” of reaching work late. This is what we try to do with risks by using the Avoid Strategy.

Trivia:

In almost all cases where you use the Avoid strategy, you are altering the project in one way or another which will result in updates to the Project Management Plan. For ex: If you realize that your project’s deadline may be missed, you can add more people to finish the work soon or get the end date moved by a few days. Either ways the response to the risk of missing the deadline will be avoided by making some change to the project attributes which in turn will result in updates to the PM Plan.

Transfer:

As per the PMBOK, the liability or the impact of a risk can be transferred to a third party if they are willing to take ownership/responsibility of the same.

Definition: Transfer is the strategy by which – We transfer the responsibility or ownership of the risk to a third party.

Depending on the level of risk and its complexity, all or part of the risk may be transferred to the third party. The Transfer strategy is typically used to deal with risks that deal with financial risk exposure or losses.

Ex: We could buy any of the following in order to Transfer financial losses:
a. Insurance
b. Bonds
c. Guarantees
d. Warranties
e. Etc.

Recollect the concept of Pure Risks that can result only in a loss and hence we could insure them, like a Flood or an Accident? By buying the Insurance policy, you are transferring the risk to the third party who is selling you the insurance policy. Typically this service is provided by the third party in return to some form of payment that you do.

An important point to remember is that, the transfer strategy does not eliminate risks. Instead, it just moves the liability of damage to the third party. Often times, a contract is signed with the 3rd party with details on who takes on how much risk/liability which is followed in case the risk materializes.

A Real Life Example: Buying Automobile or Property Insurance

Trivia:

Let us say a Bank wants to come up with a website for its customers but, it has no technical personnel who can build the website. So, losing customers who want internet banking is a risk to the bank. As, the bank itself can’t do anything, they may outsource the activity of building the website to an IT Company. So here, the risk is transferred to the IT Company which is responsible for the timely completion of the website.

Mitigate:

Mitigating Risks is a strategy that we would use when it is not possible to avoid a risk.

Definition: Mitigation is a strategy by which – We reduce the Probability and/or Impact of a risk to an acceptable level.

This definition is kind of vague. What is meant by acceptable levels? This acceptable levels thing could vary from organization to organization and from project to project. So, a risk mitigation strategy you used in your last project/organization may or may not be applicable in your current project/organization. This acceptable level depends on your Organizational and Stakeholder Risk Thresholds.

So, the success or rather effectiveness of your mitigation plan depends on your organization and whether or not you have clear & well defined Stakeholder Risk Tolerance/Threshold information.

Trivia:

Now you must have realized the importance of identifying Stakeholder Risk Tolerance. if you kind of skipped that topic in a hurry, I suggest you revisit the topic and read it again. Click Here to visit that chapter.

The whole idea about this Risk Mitigation strategy is to be proactive and dealing with a risk before it actually occurs. This would be much cheaper and cost effective than handling the risk once it occurs. Remember the age old saying “Prevention is better than cure”. Though we aren’t preventing or eliminating the risk altogether, we are at least preparing ourselves to handle it in the best way possible instead of just reacting once the risk event actually occurs.

Examples:
a. Choosing a Stable vendor – to minimize delays in shipment
b. Conducting more quality tests – to minimize risks related to quality of the end product
c. Getting a buy-in from the team on the task estimates before assigning them tasks – to minimize schedule slippage
d. Etc.

Remember that it may not be possible to reduce both the probability and impact of a risk at all times, when you are applying the mitigation strategy. However, in such cases, we may just recue one and have plans to handle the risk in case it materializes.

Accept

Accept is the last strategy we are going to cover as part of this chapter. This strategy can be used for both Negative and Positive Risks.

In some cases it is not feasible to deal with the risk. In such cases we just accept to live with the risk and move ahead.

Definition: Accepting is a strategy wherein – We do nothing to alter the probability or impact of a risk. Nor do we do anything to ensure that the risk does not occur.

Simply put, we aren’t doing anything useful to handle the risk.

There are two types of acceptance. They are:

a. Passive Acceptance – Where you do practically nothing about the risk or its consequences. We just decide to deal with the risk once it materializes.
b. Active Acceptance – Where you do nothing about the risk but are ready to deal with its consequences. You prepare a contingency reserve which you will use to handle the risk when it materializes.

The contingency reserve may include time, funds etc. to deal with the risk when it materializes. For now, just don’t worry too much about the reserves as we will be looking at it in detail shortly.

Let us say, you have just taken over a project and realize that one of the senior members of your team is planning to get married this year and may request a release from the team or a transfer if the groom happens to be from a different city. In case of Passive Acceptance you just ignore this whole situation and then start worrying about it if she actually asks for a transfer or resigns. Whereas, in case of Active Acceptance, you actually create a contingency reserve to hire senior person into the team in short notice so that, you can get someone on board during a one or two month period and have them transition over to take this position in the team.

By now, you may be wondering, why would I choose “Accept” as a strategy? Are you?

Frankly speaking, you wouldn’t choose “Accept” as a strategy just because you are lazy or don’t know how to handle it. In fact, there could be legitimate reasons as to why you chose this strategy. For ex:

a. When the response is either impossible or impractical
b. All other strategies are ineffective
c. The cost involved in either avoiding or mitigating is too high when compared to the actual impact
d. Etc.

In real life project scenarios, every activity in the project equates to either time and/or cost. So, if the impact of a risk is $1000 and you spend $5000 to avoid it, does that sound logical? I would rather absorb the risk impact of $1000 than spend $5000 to fix it. Isn’t it? This is a perfect example where I would choose “Accept” as a strategy to handle this particular risk.

The example for handling a Positive Risk (a.k.a Opportunity) would be slightly trickier. Let us say you are executing a large multi-million dollar project for your client that is scheduled to complete in Dec 2012. During the planning phase last year, you had a hunch that you will be able to finish the project ahead of time and if that happens you and your company may get a fat performance bonus. As a smart manager, you did not start building castles in air but you did keep a small contingency reserve to ramp the team up by 2 people if the need arises and then started the project execution. During May this year when you checked your project performance you are ahead of schedule and are scheduled to finish the project by end of October. But, as per the client agreed contract, if you finish by September 2012, you get the performance bonus. You utilize that contingency reserve you set aside last year, hire a couple of techie guys and fast-track a few processes and try to complete the project by end of September.

This would be an example of Active Acceptance wherein you did not do anything up front to handle the opportunity but you were prepared (with contingency reserves) to grab the opportunity if it actually presented itself. In case of Passive Acceptance, you would’ve just ignored the whole performance bonus thing and tried finishing the project before December and that’s all.

Trivia:

In real life a good project manager will never let opportunities pass by unless it is inevitable. So, Passive Acceptance is not a strategy that I would use in real life to handle a positive risk. But, for the exam perspective you need to know that this too is a viable strategy.

Prev: Introduction to Tools & Techniques used in Plan Risk Responses

Next: Strategies for Handling Positive Risks

Introduction to the Tools & Techniques used in Plan Risk Responses Process

In the past couple of chapters, we have taken a high level look at the plan risk responses process as well as the inputs used in the process. So, the next logical step, as in any process is, to apply some tools and techniques on the input data in order to generate an output. The output in this case would be the “Risk Responses” which we are going to use for each of the risks that have been identified so far.

Let me start off by saying that, this is just an introductory chapter on the tools and techniques used in the Plan Risk Responses process. Each of these tools and techniques will be covered in detail in the following chapters excluding Expert Judgment because; we already know what Expert Judgment is, don’t we?

The biggest challenge in this process is how to differentiate between the various response strategies given a particular scenario. The PMBOK guide outlines a number of strategies to handle risks and all our discussions in the forthcoming chapters will be based on them.

At the end of the day, our aim is to select the Best Strategy to handle the risk at hand.

Trivia:
In real life, a combination of strategies may be collectively applied to handle a particular risk. We don’t always choose only one strategy. However, from the exam perspective, we can select only one answer and hence the use of “The Best” strategy from the PMI’s perspective

The following are the tools and techniques we are going to cover in the following chapters:

a. Strategies for Negative Risks or Threats which include:

a. Avoid
b. Transfer
c. Mitigate &
d. Accept

b. Strategies for Positive Risks or Opportunities which include:

a. Exploit
b. Enhance
c. Share
d. Accept

c. Contingent Response Strategies and
d. Expert Judgment

Did you notice that “Accept” is a strategy for both Negative and Positive Risks? If you did not, pause for a moment, go back and read this chapter again.

As mentioned at the start of the chapter, Expert Judgment refers to the expertise of the individuals involved in risk management related decisions and hence we won’t be covering it as a separate chapter. The following chapters will be covering these tools one by one.

Prev: Inputs used by the Plan Risk Responses process

Next: Strategies to Handle Negative Risks