PMP Certification Study Guide

Below are the series of articles that are part of our endeavor to get PMP Certified.

The Chapters below are based on the different phases of a Project which begin with Project Initiation, then Planning, then Execution, then Monitoring & Control and then finally the Closing phase.

Hope you find it useful.

Articles Index:

1. About the PMP Certification
2. Tips to get PMP Certified
3. Main parts in Managing a Project

The Remaining Articles in this series will be classified broadly into 5 Parts as explained in Chapter 3.

Part 1 - Initiating the Project

Section 1: Introduction to Project Management

1. Main Parts in Managing a Project
2. Introduction to Projects
3. Understanding Projects
4. What is Progressive Elaboration
5. Understanding Process
6. Project Lifecycle
7. Project Management Knowledge Areas
8. Project Stakeholders
9. The Most Influential Stakeholder
10. Organizational Influence on Projects
11. Understanding the Organizational Structure
12. Environmental Factors & Process Assets
13. Relation Between Project, Program and Portfolio
14. Other Terms Related to Project Management
15. Project Management Office
16. Big Picture of Project Management
17. Summary
18. Important Terms & Definitions

Section 2: Project Initiation

1. Introduction to Project Initiation
2. Origins of Projects
3. Understanding Project Selection
4. Developing a Project Charter
5. Identifying the Project Stakeholders
6. Stakeholder Analysis
7. Stakeholder Management Strategy
8. Summary
9. Important Terms & Definitions

Part 2 - Planning the Project

Section 1: Project Scope Planning

1. Introduction to Project Planning
2. Developing the Project Management Plan
3. Managing Project Scope
4. Collecting Requirements For Projects
5. Requirements Collection Process
6. Defining the Project Scope
7. Creating Work Breakdown Structure
8. Before & After WBS
9. Section Summary
10. Important Terms from the Section

Section 2: Planning for Project Schedule & Communication

1. Introduction to Project Schedule
2. Defining Activities
3. Sequencing Activities
4. Estimating Activity Resource Requirements
5. Estimating Activity Duration
6. Developing the Project Schedule
7. Project Communication
8. Planning Project Communication
9. Section Summary
10. Important Terms & Definitions

Section 3 - Planning for Project Resources

1. Introduction to Project Resource Management
2. Developing the Human Resource Plan
3. Estimating Costs & Determining Budgets
4. Procuring Project Resources
5. Procurement Management Plan
6. Important Terms & Definitions

Section 4: Planning For Quality & Risk Management

1. Big Picture of Quality Management
2. Planning Quality
3. Big Picture of Risk Management
4. Planning Risk Management
5. Identifying Risks
6. Analyzing Risks
7. Qualitative Risk Analysis
8. Quantitative Risk Analysis
9. Planning Risk Response
10. Big Picture of Quality & Risk Management
11. Section Summary
12. Important Terms & Definitions

Part 3 - Executing the Project

Section 1: Managing Project Work

1. Introduction to Project Execution
2. Executing a Project - Big Picture
3. Directing & Managing Project Execution
4. Performing Quality Assurance
5. Conducting Procurements
6. Section Summary
7. Important Terms & Definitions

Section 2: Managing the Project Team

1. Introduction to Human Resource Management
2. Big Picture of HR Management
3. Acquiring a Project Team
4. Developing the Project Team
5. Managing the Project Team
6. Motivating your Team
7. Section Summary
8. Important Terms & Definitions

Section 3: Managing the Stakeholders

1. Introduction
2. Big Picture of Stakeholder Management
3. Managing Stakeholder Expectations
4. Distributing Information
5. Section Summary
6. Important Terms & Definitions

Part 4 - Monitoring and Controlling the Project

Section 1: Monitoring & Controlling Project Work

1. Introduction
2. Big Picture of Monitoring & Controlling Project Work
3. Monitoring & Controlling the Project Work
4. Integrating Change Control
5. Administering Procurements
6. Section Summary
7. Important Terms & Definitions

Section 2: Monitoring & Controlling Quality and Risk

1. Introduction
2. Big Picture of Quality Management
3. Controlling Quality
4. Monitoring & Controlling Risks
5. Performance Reporting
6. Section Summary
7. Important Terms & Definitions

Section 3: Monitoring & Controlling the Golden Triangle

1. Introduction
2. Big Picture of Monitoring & Controlling the Golden Triangle
3. Controlling Scope
4. Controlling Schedule
5. Controlling Cost
6. Measuring Performance
7. Section Summary
8. Important Terms & Definitions

Part 5 - Closing the Project

Section 1: Closing the Project

1. Introduction
2. Big Picture of Closing the Project
3. Verifying the Scope of Project Deliverables
4. Performing Project Closure
5. Performing Procurements Closure
6. The Finishing Touches
7. Section Summary
8. Important Terms & Definitions

Section 2: Ethics & Professional Responsibility

1. Introduction
2. Ensuring Individual Integrity
3. Contributing to the Knowledgebase
4. Enhancing Individual Professional Competence
5. Promoting Interaction among Stakeholders
6. Dealing with Unprofessional Conduct
7. Big Picture of Code of Ethics and Professional Conduct
8. Section Summary
9. Important Terms & Definitions

Apart from these articles, there will be some more articles that will help you gain more expertise in order to get the elusive PMP Certification. Watch out for more articles in this blog soon!!!


Thank you to all future PMP's

The Risk Management Processes

The Practice Standard for Risk Management actually covers the same set of processes that you could find in the PMBoK but there is a subtle difference. The PMBoK is all about Inputs, tools & techniques and outputs. Whereas, the Practice Standard adds more than just that, it adds a lot of details that you wouldn’t find in the PMBoK guide.

Ok, the six risk management processes that are part of the PMBoK Guide and the Practice Standard have been covered in great detail in our blog in the preceding sections. But, let us quickly summarize what the Practice Standard has to say about those processes.

1. Plan Risk Management – Define the Scope and Objective of Project Risk Management knowledge area and ensure that risk processes are fully integrated into wider project management.
2. Identify Risks – Identify as many known risks as practically possible
3. Perform Qualitative Analysis – Evaluate the key characteristics of individual risks so that they can be prioritized for further action
4. Perform Quantitative Analysis – Evaluate the combined risk on the overall project
5. Plan Risk Responses – Determine response strategies and actions for individual & overall project risks and integrate them into a plan
6. Monitor and Control Risks – Implement the approved response strategies, review changes, identify additional risk management actions required and assess the effectiveness of overall risk processes

Lastly, the Practice Standard mentions something that we have gone over multiple times. It says that the risk management processes are iterative and dynamic in nature. They must be tailored to suit the needs of your respective projects.

This wraps up all the articles in the series on PMI-RMP Exam Preparation. All the very best for your Exam. You can view the whole series in the Index Page by clicking here.

Prev: Risk Management Foundation

Risk Management Foundation

In this chapter, we are going to cover the foundational concepts of Risk Management.

Let us start with the official definition of the term “Risk” - A Risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives. The term uncertain means we are not sure whether the event will happen. There is a likelihood that the event will happen and if it does, there will be consequences.

The practice standard for risk management says that – Dealing with threats and opportunities together typically leads to a gain of synergies and efficiencies.

While handling project risks we typically use two terms:

Individual Risk – A risk that may have an impact on project objectives
Overall Risk – Reflects the overall uncertainty of the project as a whole

During the course of the chapters on the PMI RMP Exam series, I have said this numerous times and since the concept is so important, I don’t mind saying it again. Risk Management is an iterative activity and must start at the early stages of a Project Lifecycle.

Who is Responsible for Risk Management?

This is a million dollar question which you already know the answer, don’t you?

Everyone

Yes, everyone in the project including all the stakeholders are responsible collectively to manage the risks in the project. But, the key people who drive the risk management effort for the whole project are the Risk Manager and the Project Manager. It would be a god idea to have a Risk Manager for every project but, in most cases there is no dedicated risk manager for a team and the Project Manager doubles over as the risk manager as well.

Common Risk Management Mistakes

As said in the previous section, without a collective effort from everyone in the team, risk management could fail very easily. But, this isn’t the only problem in most projects. Some of the common mistakes that people do in projects are:

• Conducting no risk management activities at all
• Even if risk management activities are conducted, it is done by one or a select few people only
Responsibilities of the Project Manager & Risk Manager with respect to Project Risk Management:
The following are some of the responsibilities of the Project Manager and Risk Manager:
• Getting the senior management’s support and carrying out as well as encouraging strong communication
• Determining risk tolerance levels & tailoring the risk management activities in the project to suit the needs of the project as well as the risk tolerance levels
• Generating an approved Risk Management plan that reflects the project’s risk management processes
• Carrying out and overseeing the Risk Management Plan activities and processes
• Reporting as required
• During project closure – determining what went well and where there are areas for improvement.
• You document lessons learned so that future projects could use them

Remember, just earlier on in this chapter I said that risk management is everyone’s responsibility but according to the practice standard for risk management though risk management is everyone’s responsibility, the project manager will be held accountable for successful completion of risk management activities in the project.

Prev: Introduction to Practice Standard for Risk Management

Next: The Risk Management Processes

Introduction to the Practice Standard for Project Risk Management

The Project Management Institute (PMI) has a dedicated practice standard for Project Risk Management that is available for all PMI Members to download. The Current PMI Standards can be found by Clicking Here. You can click on the link titled “Practice Standard for Project Risk Management” to download your copy as a member benefit. The file is password protected and you cannot print or share it with anyone and is strictly for personal use.
Coming back to our PMI RMI Exam Preparation perspective, going through the practice standard for Project Risk Management would be a good idea before you actually go for the exam. It is only around a 100 pages in size and not as big as the PMBoK.

About the Practice Standard for Project Risk Management:

• It serves as a guiding role to the use of tools & techniques and processes for Project Risk Management
• Does not explain how a process is to be executed
• Expects your experience to fill-in the gaps

The PMBok Guide gives us information on all Project Management Processes. The Practice Standard gives us principles of specialization in Project Risk Management. In this section we will be covering the Practice Standard for Project Risk Management at a very high level. I repeat, this is a very high level summarization of the RMBoK (As I call it) and I strongly urge you to download and browse through it before you sit for the PMI RMP Examination.

Critical Project Success Factors:
According to the practice standard, there are 6 key/critical success factors that could affect the success of our project and its risk management activities. They are:
1. Recognition of the value of Risk Management – As project managers it is our responsibility to explain the importance of risk management to everyone (in our project) and make them realize that risk management activities are not an overhead but can have great benefits on the overall success of the project.
2. Individual commitment – Unless we explain the importance of risk management to all our stakeholders, we will not get their commitment/support which may hinder the risk management activities. As I have said before, risk management is a collective effort and requires the participation from all involved parties.
3. Communication that is open and honest – every project has multiple stakeholders and each of those people could have a different agenda. So, unless we keep the project communications open & honest they wouldn’t have a clear picture of the projects status and this could result in problems in the future.
4. Organizational commitment – A lot of organizations still do not understand the value of risk management activities and hence making them realize the benefits of implementing risk management processes will help us gain their commitment which could go a long way in successful risk management in our project
5. Risk effort tailored to the project – Every project is different. What would be a good idea for one project could be a disaster for another. So, all our risk management effort must be in accordance to the size, complexity and needs of the project.
6. Integration with project management – Risk Management efforts in our project must be closely integrated with the overall project management effort.
Before we elaborate on these key points, think this way – You could be an amazing risk analyst and could identify all risks that could affect your project within hours. You also have access to the most amazing tools that can aid in risk management. So, does this mean that your risk management effort on the project will be a success?

Did you say “Yes”, if so, you are greatly mistaken. Unfortunately, if you do not communicate effectively with the project stakeholders, then your project risk management effort will not succeed. In fact, if you do not take up any of the above mentioned 6 factors properly, there is a high probability that your effort in project risk management may end up a failure.


Prev: Section Summary - Monitor & Control Risks


Next: Risk Management Foundation

Section Summary – Monitor and Control Risks

In the previous few chapters in this section, we had taken a detailed look at the Monitor and Control Risks process, its inputs and the tools and techniques used in this process. Let us quickly recap what we have learnt so far:

• The purpose of this process is - To implement risk response plans, track identified risks, monitor residual risks, identify new risks, evaluate the effectiveness of risk response plans and of the risk management process.
• An important point to remember here is the fact that, during this process, we could uncover new risks as well. In such cases, we typically go back and analyze those risks and then take those risks through the full risk management process cycle
• As risk responses are implemented and risks are tracked, any corrective actions required are submitted through the monitor and control risks process
• This process uses a total of 4 inputs. They are:

1. Risk Register
2. Project Management Plan
3. Work Performance Information
4. Performance Reports

• There are a total of 6 tools and techniques that we will be using in this process. They are:

1. Risk Reassessment
2. Risk Audits
3. Variance and Trend Analysis
4. Technical Performance Measurement
5. Reserve Analysis
6. Status Meetings

• There are three aspects of Risk Reassessment that you must remember for the RMP Exam. They are:

1. Identifying New Risks
2. Closing Risks that are no longer applicable
3. Keeping tab on existing risks to figure out if any further action is required

• Risk Audits are concerned with:

1. Measuring the effectiveness of the risk responses
2. Measuring the effectiveness of the risk management processes in the project

• Workaround is - An unplanned response to a negative risk that has occurred/materialized
• The key difference between workarounds and the contingency/fallback plans is the fact that – Workarounds are unplanned and utilized on the fly whereas we meticulously plan contingency and fallback plans
• Reserve Analysis is an analytical technique to determine the essential features and relationships of components in the pm plan to establish a reserve for the schedule duration, budget, estimated costs or funds for a project
• If the Risk Management team was inefficient in calculating the reserves or if the numbers they calculated were insufficient, the reserve analysis can identify such gaps and help salvage the project
• The purpose of Variance & Trend analysis is to forecast any potential cost and/or schedule deviations in the project at completion
• We will be using Earned Value Calculations during Variance & Trend Analysis
• Though Estimation Techniques and Cost Benefit Analysis are not explicitly listed down as tools and techniques for this process, we need to be aware of them to apply the other actual tools and techniques for the process
• There are three types of Estimation – Analogous, Parametric and Bottom up
• Cost benefit analysis compares the cost of producing a service, product or result to the benefits that the organization (doing/creating it) receives as a result of it.
• The purpose of Technical Performance Measurement is to uncover any deviations that may exist, such as differing functionalities, than what was planned for the Project.
• Any team meeting that addresses risk management in the project as an Agenda Item for discussion would be considered a Status Meeting from Risk Management perspective
• The more often risks are addressed, the easier we can identify and deal with them
• The amount of time we spend discussing risks in our status meetings, depends on the number of risks, their complexity, their probability and impact etc.

Prev: Technical Performance Measurement & Status Meetings

Next: Introduction to Practice Standard for Risk Management

Technical Performance Measurement and Status Meetings

In the previous chapters, we have covered many of the tools and techniques used in the Monitor and Control Risks process. In this chapter we are going to take a look at last two items in the series namely “Technical Performance Measurement” and “Status Meetings”

Technical Performance Measurement

Purpose: To uncover any deviations that may exist, such as differing functionalities, than what was planned for the Project.

This technique compares the actual technical accomplishments in the project to the planned technical achievements. It helps us to identify and forecast the degree of success in achieving the scope of work taken up as part of the Project. Practically speaking, every project is taken up to accomplish some scope of work and in this process, we are just checking to see if the risk of any deviations from the planned accomplishments exists.

In order to use this technique, we must have quantifiable objectives that can be measured on a technical level. This can be done only when project work (Execution) is underway and we are in the Monitor and Control phase of the Project. In real life, you may see this activity taken up during significant project milestones.

As we complete this activity and as deviations are identified, they are documented with all supporting information. Once this information is available the Risk Management team could suggest corrective actions to keep the project on track with the original plan.

A project where the risk management team fails to identify deviations from plan early and fails to implement corrective actions on time, will almost always fail.

Trivia:

I have used the term almost always because – Miracles too happen in real life but I believe in hard work more rather than miracles.

Status Meetings

Before we begin, a Status Meeting is technically not a tool or a technique but is something that can greatly help address project risks. So, logically, as it is used in monitoring and controlling risks, it has been given a kind of honorary technique status for this process.

Any team meeting that addresses risk management in the project as an Agenda Item for discussion would come under this category. In real life, getting everyone in the team to gather in a meeting is not so easy esp. if the people who are to attend the meeting are senior in the org hierarchy. So, once we assemble the key participants, we must utilize the time available effectively.

Benefits:

The more often risks are addressed, the easier we can identify and deal with them.

Risk management is an ongoing activity and is not something that happens say once in a quarter. But, unfortunately this is how risk management happens in real life. People feel that risk management is yet another process/activity that has to be done just because the people higher up say so. So, the effectiveness of this whole activity is greatly depleted.

How we educate our team and stakeholders about risk management and make them understand its benefits will greatly help set the agenda and objectives of the meeting. At the end of the day the key stakeholders and senior management want us (Project Managers) to execute a successful project which finishes on time and within budget. Risk Management is not an overhead; instead it can help achieve the project objectives without any last minute surprises. This is something that must be understood by everyone participating in these meetings to make the most of the gathering.

The amount of time we spend discussing risks in our status meetings, depends on the number of risks, their complexity, their probability and impact etc. We typically will examine all the risks in our Risk Register, their response plans and then gather feedback from the meeting attendants about them. An open floor could give way to newer and smarter suggestions which may not come out if everyone does not understand the importance of the activity or if everyone is not given an opportunity to contribute.

As project managers, it is our responsibility to utilize the knowledge and inputs that our team members may have to get the best out of our Project.

Prev: Estimation Techniques & Cost Benefit Analysis

Next: Section Summary

Estimation Techniques and Cost Benefit Analysis

Though Estimation Techniques and Cost Benefit Analysis are not explicitly listed down as tools and techniques for this process, we need to be aware of them to apply the other actual tools and techniques for the process. That is the reason why we have this chapter here amidst all the tools and techniques for this monitor and control risks process.

Estimation Techniques:

As part of examining project performance information and monitoring & controlling risks, we will be using/evaluating many estimating techniques and we need to know them at least at a high level in order to assess the project performance as well as to assess the status of the risks. The following are some of the major estimation techniques that we may use in our projects:

1. Analogous Estimating – This is a technique where we estimate the cost of the current project by applying our expert judgment on the actual costs from previous projects. This is a fast and cheap estimation technique but is not very accurate because the parameters considered while estimating the old project may or may not be applicable for our current project and so the estimates may not be accurate. This technique is typically used when resources to do the estimation are low and we are only looking for a high-level or ball-park kind of estimate.
2. Bottom-Up Estimating – This is a technique where we estimate the individual work packages (From the Work Breakdown Structure) and then the individual numbers are rolled up to the project level for the overall estimate. This kind of estimation is time consuming is much more accurate when compared to the Analogous technique. This technique is typically used when we have abundant budget and time to take up estimation at a detailed level.
3. Parametric Estimating – This is the third technique where we use historic data along with other information to arrive at the estimates for our project. For ex: If one person can build a wall in 10 days alone, how long would it take for 3 people to do? This technique is typically used for repetitive activity where the parameters affecting the work and estimate are well known.


Cost Benefit Analysis

Cost benefit analysis is a common technique that we apply at various stages in the lifecycle of our project. It compares the cost of producing a service, product or result to the benefits that the organization (doing/creating it) receives as a result of it.

For ex: If I were to own a supermarket. If the cost of buying a product is X and the cost of keeping it in my store, taking care of it etc. is Y then, the price at which I sell it to you must be greater than X+Y otherwise there will be no benefit (profit) in selling that product.

Cost benefit analysis must also consider initial costs, marketing and advertising expenses, maintenance and support of the product/service for cost benefit analysis. If I were to consider only the purchase and selling price to do cost benefit analysis of my items and ignore my store rent, electricity bill, worker wages etc., then even if I sell my products at a price greater than the cost I bought it, I might end up losing money.

Trivia:

In real life cost benefit analysis is used in various places. For ex: if the project is facing an issue and we are to implement a fix, we need to understand the cost of the fix, the benefits we gain out of implementing the fix before we go ahead. If the benefits I gain are more than the cost I incur then the fix is beneficial and it makes sense in going ahead with the fix.

Prev: Variance & Trend Analysis

Next: Technical Performance Measurement & Status Meetings

Variance and Trend Analysis

In the previous chapters we took a look at some of the tools and techniques used in monitor and control risks process like Risk Audit, Risk Reassessment, Reserve analysis etc. The topic for discussion in this chapter is “Variance and Trend Analysis” which is a valuable tool for any Risk Manager.

Purpose: To forecast any potential cost and/or schedule deviations in the project at completion

In the chanter on inputs for the monitor and control risks process, we saw that we will be need performance related data like Work Performance Info and Performance Reports for this process. We will be using those inputs in this process. We take all the performance data related to our project so far and then:

• The risk management team examines trends in the team’s performance
• Identifies variances by comparing planned vs. actual data
• Identifies any potential delays or bottlenecks with respect to the completion of the Project.

So, the next logical question here would be – how will we analyze the data gathered so far?

We will be using Earned Value Analysis to do all that. Though Earned Value isn’t an actual topic as part of the PMI RMP syllabus, it would be a good idea to revisit the following two chapters to refresh your memory:

a. Cost Management during Monitoring & Controlling the Project
b. Measuring Project Performance

I am pretty sure that you did not revisit those chapters because; I would’ve probably done the same. So, let’s quickly cover the basics of Earned Value Analysis so that we know what we need to know for the PMI RMP Exam.

The basic idea of Earned Value Analysis is to integrate project, cost and scope measures to assess the project performance and progress as of date.

The following are the EVM Terms we will need to know:

Planned Value (PV) – The value that signifies how much work must have been completed so far
Earned Value (EV) – The value that signifies how much work has actually been completed so far
Actual Cost (AC) – The value that signifies how much money/cost we have spent on our project so far

Based on these 3 numbers we can calculate the following:

Schedule Variance (SV) – The deviation between the actual schedule progression and the planned schedule
Cost Variance (CV) – The deviation between the actual cost spent on the project and the planned project budget

Cost Performance Index (CPI) – The Numeric Representation of the Project’s cost performance – A number between 0 and 2.
Schedule Performance Index (SPI) – The Numeric Representation of the Project’s schedule performance – A number between 0 and 2.

In either case we would expect the performance index value to be greater than 1 which means we are ahead of schedule or within cost.

Estimate To Complete (ETC) – The amount of funds required to complete the project from the current status/point

Estimate At Completion (EAC) – The amount of funds the project is expected to utilize as a whole, throughout its life when the completion stage is reached.

If you are already a PMP certified manager, you must remember those confusing formulas EV/PV, EV/AC etc. that we would’ve memorized for the PMP Exam. Thankfully, for the RMP Exam, we need not remember all those formulae. That is why; I haven’t given any of the formulas in our quick recap. For the exam, we need to understand the concept and what each of these Earned Value terms signify which I believe, we do by now, don’t we??


Prev: Workarounds and Reserve Analysis

Next: Estimation Techniques & Cost Benefit Analysis

Workarounds and Reserve Analysis

In the previous chapter, we took a look at two of the tools and techniques used in the monitor and control risks process. In this chapter we are going to cover some more – Workarounds and Reserve Analysis. Though workarounds aren’t listed as a distinct or explicit tool and technique used for this process, we are covering it here because, it is very useful in real life and more importantly it is part of the exam syllabus.

Workarounds

The literal meaning of the word workaround is applicable in project risk parlance as well. In real life, every successful or even failed projects would have tried & implemented multiple workarounds to unexpected risks while the project was being executed.

Definition: An unplanned response to a negative risk that has occurred/materialized

In real life, it is not practically possible to capture or identify all of the risks that may occur in our project. Nor is it possible to identify/spot risk warning signs every time. It is also possible that the status of a risk in the watchlist changed from low to high and you completely missed it. In such cases, the risk can suddenly materialize into reality and affect your project.

The workaround is the project team’s response to these types of risks.

Remember contingency and fallback plans that we covered during the “Plan Risk Responses” process? You may be wondering how different is this workaround from those plans?

The key difference is the fact that – Workarounds are unplanned and utilized on the fly whereas we meticulously plan contingency and fallback plans. Another big difference is that, workarounds are formulated and implemented during the monitor and control phase of the project, while contingency or fallback plans are formulated during the planning phase of the project.

The following are some key characteristics of Workarounds:

• They are unplanned responses to negative risks
• They are the usually used to handle unknown or accepted risks
• Is implemented to deal with the consequence of a risk
• Is similar to the contingency plan, except they are unplanned
• Is used when no other response plan exists for this particular risk
• Typically more costlier than planned responses
• Is part of the monitor and control risks process
• Is part of the monitor and control phase of the project

Trivia:

Are you wondering why a workaround would be costlier than a planned response? The answer is pretty straightforward – when you are implementing a workaround, you are literally in fire-fighting mode. You do not have the liberty of looking for multiple alternatives and choose the best/cheapest. All you are worried about now is to minimize the impact/damage caused by the risk that has suddenly materialized and not so much about cheaper alternatives.

Reserve Analysis

Reserve Analysis is yet another important technique that we use in the monitor and control risks process. As the project execution continues, risks begin to materialize and we start implementing the planned responses. In cases where we haven’t planned a response, we use the contingency reserves. So, as we start using the reserves, it becomes necessary to monitor the usage of the reserves to ensure that we still have enough remaining to handle the other risks that may materialize in future.

Definition of Reserve Analysis: An analytical technique to determine the essential features and relationships of components in the pm plan to establish a reserve for the schedule duration, budget, estimated costs or funds for a project

The main idea here is to compare the amount of reserves remaining with the risks remaining to see if the reserves available will be sufficient to handle the rest of the risks. The reserves we analyze will include schedule, cost and budget reserves.

If the Risk Management team was inefficient in calculating the reserves or if the numbers they calculated were insufficient, the reserve analysis can identify such gaps and help salvage the project.

Trivia:

If you are wondering why we need to do this activity – think of the following scenario. Let us say your contingency reserve was 100k USD and you have utilized 90K so far. There is still 3 months’ worth of project work to be completed. Suddenly today you realize that the license for one of the key software components that you use for your project work has expired and it costs around 5K per 3 licenses. Your team has 12 developers and so you will need 20K to acquire 4 fresh licenses. You go and check your contingency reserve to get the shock of your life – you have only 10K and are 10K short.

If you had done reserve analysis last month, you would’ve realized that your project was running low on reserves.

The idea here is simple – if you do not have sufficient reserves, how will you handle risks if they materialize?

Prev: Risk Reassessment & Risk Audits

Next: Variance & Trend Analysis

Risk Reassessment and Risk Audits

In this chapter, we are going to look at two of the tools and techniques in the monitor and control risks process, namely – Risk Reassessment and Risk Audits.

Risk Reassessment

The word reassessment is something that you would’ve heard frequently in real life. The meaning of Risk Reassessment is in the same lines as the literal meaning/purpose of the word and focuses on Risks specifically.

There are three aspects of Risk Reassessment that you must remember for the RMP Exam. They are:

1. Identifying New Risks
2. Closing Risks that are no longer applicable
3. Keeping tab on existing risks to figure out if any further action is required

Points 1 & 2 are pretty self-explanatory. Point 3 is where a bulk of the action is. We will keep checking if the impact and/or the probabilities of risks are the same now (As compared to when they were planned before). The level of impact of a risk or its probability could change when project execution begins. Even some risks that are in the watchlist could have changes to their probability and/or impact. In such cases, we take these risks through the risk management cycle and then formulate a response. The whole idea is to reassess and re-strategize those risks where we feel our existing response strategy may be inadequate.

Trivia:

When a new risk is identified during this process, we take that risk through the full risk management cycle in order to formulate a response strategy for the newly identified risk.

As the project progresses:
• The probability of a risk occurring comes down
• The impact of the risk (if it occurs) goes up

Remember the chapter on Risk & Uncertainty titled Managing Uncertainty? Risks always move with uncertainty. The greater the uncertainty, the greater the risk. So, as the project moves forward and more and more work gets completed, the uncertainty comes down and so does the likelihood of the risk materializing.

Projects vary and not all projects are similar. So, when we do this risk reassessment activity too would vary from case to case. As a general rule of the thumb, risk reassessment should be scheduled regularly, especially where projects have schedule or cost slippages. The whole idea here is to reassess the situation to take remedial actions to bring the project back on track.

Risk Audits

Risk Audits is another tool and technique that we use during the monitor and control risks process. It is also part of the overall process improvement of the project.

Risk Audits are concerned with:
• Measuring the effectiveness of the risk responses
• Measuring the effectiveness of the risk management processes in the project

When we perform Risk Audits, we examine the risk responses (that were implemented) to determine if they were effective in handling the risks and their root causes. The output of this audit is always documented. Similarly, we can also audit and gauge the effectiveness of the risk management processes in the project as a whole too.

The idea behind these kinds of activities is to be more proactive than be reactive. We are constantly trying to refine and improve our processes and efficiency and this risk audit can greatly help the risk management practices in not only the project but also the whole organization as well (If we properly capture the results of our audits and create lessons learned documents)

It is the responsibility of the Project Manager to conduct periodic risk audits. How frequently risk audits happen, who does them, and how the output is captured etc. is specified in the risk management plan. Typically risk audits are scheduled at significant project milestones. For smaller or low-complexity projects, we can even take up risk audit as a onetime activity towards the end of the project.

Steps in Risk Audit:
a. Identify who will participate
b. Follow the risk audit specifications documented in the risk management plan
c. Collect, analyze and document all relevant information
d. Use recommendations to improve the process

As we conduct the audit, the participants may have several questions. All these questions will help us measure the effectiveness of the response that was implemented. In order to achieve maximum benefits out of this activity, all the participants must be in the same page before the meeting and understand the project clearly.

Prev: Overview of Tools & Techniques used in Monitor & Control Risks

Next: Workarounds and Reserve Analysis

Overview of Tools & Techniques used in Monitor & control Risks Process

The monitor and control risks process is instrumental in the success or failure of a project. You may have come up with elaborate and comprehensive plans to handle risks in your project but, if you do not monitor your risks and take controlling actions as required, all your planning effort isn’t worth even one penny. So, every good project manager has to ensure that he/she spends adequate time and effort in this process to reap the best rewards for the project.

There are a total of 6 tools and techniques that we will be using in this process. They are:

• Risk Reassessment
• Risk Audits
• Variance and Trend Analysis
• Technical Performance Measurement
• Reserve Analysis
• Status Meetings

There will be no need to reassess or audit risks if the actual project execution hasn’t started. So, as of now the project status is the same as what we had at the end of the Planning phase and hence none of the risks or their statuses would’ve changed. In fact, the other processes too may not add much value to the Project’s Risk Management if we haven’t entered the Project Execution Phase. All of these processes analyze the risk related data that is available with us now. So, unless we actually start executing project work, the data is not going to be any different to warrant any analysis.

Variance and Trend Analysis uses Earned Value. Remember Earned Value? Though Earned Value isn’t an actual topic as part of the PMI RMP syllabus, it would be a good idea to revisit the following two chapters to refresh your memory:

a. Cost Management during Monitoring & Controlling the Project
b. Measuring Project Performance


The last and final point we will cover as part of this introductory chapter on the tools and techniques used in Monitoring and Controlling risks process is about “Workarounds”. Almost all junior PM’s and even some senior ones easily confuse workarounds with contingency or fallback plans. Remember that workarounds happen during the monitor and control phase of the project while contingency or fallback plans are created during the planning phase itself.

Armed with all the information above, we are now ready to dive into these tools and techniques in detail. Note here that, in the following chapters we will be covering Workarounds as well as some Estimation techniques and Cost Benefit Analysis. Though these aren’t explicit tools and techniques in this process, they are part of the exam syllabus and will be useful in real life too.

Prev: Inputs to Monitor & Control Risks

Next: Risk Reassessment & Risk Audits

Inputs to the Monitor and Control Risks Process

In the previous chapter, we took a high level look at the monitor and control risks process. By now, you must be accustomed to the fact that, every process has a set of inputs and uses a set of tools and techniques to generate an output. This process – Monitor and Control Risks is no different.

Before we actually take a look at the actual inputs used in this process let us look at the purpose of this process. The idea here is to give you another opportunity to try to guess what inputs you may require for this process. If you read the purpose statement carefully, you can get a fair idea of what artifacts from our Project you may want to use for this activity.

Purpose of the Process:

To implement risk response plans, track identified risks, monitor residual risks, identify new risks, evaluate the effectiveness of risk response plans and of the risk management process.

This process uses a total of 4 inputs. They are:

1. Risk Register
2. Project Management Plan
3. Work Performance Information
4. Performance Reports

Trivia:

People easily confuse work performance information and performance reports. So, be cautious and understand them properly before you move on to the next chapter.

Let’s take a detailed look at each of these inputs…

Risk Register

This one is a no brainer, isn’t it? What process in Risk Management does not use the Risk Register as an input? The answer would be – Plan Risk Management and Identify risks where you actually create this document. Isn’t it?

The monitor and control risks process will make use of all of the Contents of the Risk Registerthat is available till date. However, for easier understanding, the following elements of the Risk Register are used in particular for this process:

1. Agreed Upon Risk Responses - This is a key input because, these responses are what we will be implemented during this process. We created them during the plan risk responses process. During this process, after we implement the responses, we also try to find out the effectiveness of the response and see if the response was sufficient. This is required because, if the risk still exists, we need to take actions to prevent any further impact on our project. Right?
2. Implementation Actions - Implementation Actions refers to - what exactly needs to be done in order to implement a response. For ex: In case our strategy to handle a risk is “Transfer” whereby we entrust the responsibility to handle the risk to a third party, a common implementation action would be – Get a formal contract signed with the 3rd party.
3. Risk Owners – People who own the risk and have been assigned the responsibility of tracking this risk
4. Symptoms and Warning Signs – Indications that can tell us if a risk event is about to occur or has already occurred. This is important because; if you do not know what warning signs suggest if a risk is about to occur, how would you handle it?
5. Residual Risks – These are risks that remain after you implement your response. Typically we will use contingency plans and reserves to handle residual risks.
6. Secondary Risks – These are risks that were created as a direct consequence of us implementing a risk response. Here again, we may utilize contingency reserves to handle them.
7. Watchlist – A list of low priority risks that we have kept aside. You may be wondering why this is an input to this process. Actually, when we place a low priority risk in this watchlist, it means that this risk isn’t relevant now but its status could change in the future. During the monitor and control risks process, we will be actually checking the status of each of those watchlist risks so that we will be prepared to handle them in case any of their probabilities or impacts have changed
8. Contingency Reserves for Time & Cost – as contingency plans are put into action, we need to continuously track them in line with the reserves that were put in place during the planning phase.

Project Management Plan

Actually speaking, the Risk Management Plan is the key input that we will be using for this process. But, since the RM Plan is a subsidiary of the PM Plan and also since we may need to refer to other subsidiary plans inside the PM Plan, the PMBOK chose the use the holistic term “Project Management Plan” instead of “Risk Management Plan”.

The following items from the Risk Management Plan are used in this process:

• Roles and Responsibilities
• Protocols
• Risk Tolerance Levels
• Time and Resources set aside for Risk Management Activities

Work Performance Information

Work Performance Information is generated by the Directing and Managing Project Execution process which is part of the Project Integration Management in Project Execution Phase.

As the project progresses, a lot of information is collected about the project like:

• Status of the deliverables
• Schedule Progress
• Cost incurred
• Etc.

A point to note here is that, all of the above mentioned information is collected as of the current date. Naturally, this information will not be available until we actually start doing project work (In the Project Execution Phase) and may vary as our work progresses.

Performance Reports

Performance Reports are generated as part of Report Project Performance process and is part of Communications Management during Monitoring & Controlling the Project.

Performance reports contain an analysis of the Work Performance Information collected during Project Execution. We will need this information to perform variance analysis, earned value analysis etc.

Performance reports include:

• Analysis of Past Performance
• Status of Risks & Issues
• Work Completed (So Far)
• Work that was to be Completed (So Far)
• Summary of Changes
• Variance Analysis Results
• Forecasted completion information (date & cost)

As suggested earlier, all of these items are generated using the Work Performance Information. To recollect, Work Performance Information is generated by the Directing and Managing Project Execution process which is part of the Project Integration Management in Project Execution Phase.


Trivia:

You may be wondering why PMBOK has used both Performance Reports and Work Performance Information as inputs. If the performance reports are generated using the work performance information, why not use just the performance reports?

The performance reports actually take the status of the project collected (the work performance info) and provides us with reports that give us valuable insight on how the project work is progressing. However, as with any other process, we don’t just use the output. We also store the basis of our findings and hence without work performance information we wouldn’t be in a position to confirm the fact that the report is indeed correct. We are doing risk management here. So, we need to take into account of the fact that, incorrect reports could be a source of risks for the project.

Prev: Introduction - Monitor & Control Risks

Next: Overview of Tools & Techniques used in Monitor & Control Risks

An Introduction to Monitor and Control Risks Process

In the previous sections we have successfully completed majority of the Risk Management Processes. By now, we have thoroughly analyzed our risks and even formulated responses for those risks. So, the last step in the Risk Management knowledge area is the “Monitor and Control Risks” process. This is what we are going to learn in this chapter.

Purpose of the Process:

To implement risk response plans, track identified risks, monitor residual risks, identify new risks, evaluate the effectiveness of risk response plans and of the risk management process.

The purpose looks pretty lengthy and is not too clear, isn’t it? This is the official definition as per the PMBOK so I have put it here. Practically speaking this process is responsible for:

• Tracking identified risks
• Monitoring and analyzing residual risks
• Identifying new risks
• Executing risk response plans
• Evaluating the effectiveness of the risk response plans
• Evaluating the effectiveness of the risk management plan
• Checking the validity of project assumptions
• Closing out risks that are no longer valid/applicable
• Monitoring contingency reserves and modifying them as and when required

During the previous process in risk management, we actually created a lot of plans and formulated a lot of actions that were to be implemented as required. This is the process where we actually get to implement those plans and actions.

An important point to remember here is the fact that, during this process, we could uncover new risks as well. In such cases, we typically go back and analyze those risks and then take those risks through the full risk management process cycle. This is done to ensure that we are well planned & prepared to handle risks that may affect our project.

As risk responses are implemented and risks are tracked, any corrective actions required are submitted through the monitor and control risks process. A lot of lessons learned too are picked up in this process. As practitioners of good and proper project management practices, we would document these lessons learned appropriately as well.

Prev: Section Summary - Outputs of the Plan Risk Responses Process

Next: Inputs - Monitor & Control Risks

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