A Primer on project Risk, Issue, and Change Request and their interdependencies

Project Management processes are highly integrative in nature. Processes Interact, are interdependent and influence each other. PMP exams use this characteristic of Project Management processes to set highly situational and scenario-based Questions to evaluate PMP exam aspirants' process knowledge and project management experience.

The Relationship between Risk, Issue, and Change Request is an exciting topic in Project Management. Risks are uncertain events anticipated to occur in the Future. Issues are roadblocks, impediments, and obstacles bothering the project in the Present. Change Request is used to change things we did in the Past based on valid project needs. They are interwoven, so organizations usually integrate Risk management and Change management into a singular methodology.

In this blog, we will learn how Risk, Issue, and Change Requests interact and influence each other. This will help you to understand their dynamics so you can answer complex scenario-based Questions confidently in the exam.

Let’s start with Risk.

According to PMBOK 6 Edition, an individual Risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more Project objectives.

Risk can be both positive and negative. A Positive Risk is an opportunity that benefits the project by cost saving, optimizing the schedule, increasing customer satisfaction, improving quality, etc. Negative Risk is called Threat which impacts the project objectives negatively like cost overrun, increased rework, Schedule delay, etc.

Risks need to be appropriately managed in Projects to avoid chaos. Organizations use Risk Management in projects to create and protect values.

Now we know that there are two types of Risk based on whether they create a positive or negative effect on project outcomes or objectives. If we go one level above to know the classification of Risks based on their nature, there are two kinds of Risks.

1. Known-Unknown, otherwise called Classic Risk or Risk.

2. Unknown-Unknown, otherwise called Emergent Risk or Issue.

If we understand what Classic and Emergent risks are and how they originate, we will slowly realize the fundamental difference between them.

Difference between Known-Unknown and Unknown-Unknown

To learn the difference, one needs to understand the first and second parts of both Known-Unknown and Unknown-Unknown.

According to the PMI Risk Management standard, there are fundamentally two variables that define a Risk. The first Factor is "Awareness of the Risk.” Risks are things that we anticipate could happen in the future. To anticipate something, first, we must be aware of its existence.

The second Factor is the "Weightage of a Risk," which is a function of the Risk's Probability of occurrence and the Impact the Risk can create if it occurs (Threats will erode the project’s value, and Opportunities will improve the project’s value). Since Risks are future events, we cannot be sure about their probability of occurrence and how much impact they will create, but these things can be estimated. Estimations are guesswork, but we make educated guesses using Techniques like Expert Judgement, consulting Lessons learned Repository, Brainstorming, and other Risk Quantification Techniques like Expected Monetary Value and Monte Carlo Analysis.

For both Factors, Awareness of the Risk and Weightage of a Risk, we have two definite states, "KNOWN" and "UNKNOW.” With this, there are four possible combinations if we put them in a 2D grid, keeping each Factor on one axis.

Out of the four possibilities, KNOWN-KNOWN (Facts) are scope and requirement and UNKNOWN-KNOWN (Hidden Facts) are knowledge gaps. These two are outside the scope of our discussion so let's pay attention to the remaining two.

Both Risk and Issue are the children of Project uncertainties. Uncertainty is inherent in all projects.

According to PMBOK7, Uncertainty means a lack of understanding and awareness of issues, events, paths to follow, or solutions to pursue.

When it comes to Risks, we know that Risk exists but are not sure of the chances of its occurrence and how much impact it will create, so the uncertainty lies in the approximation of the weightage of the Risk.

Risk Weightage is an f(Probability, Impact)

Let's learn this with an example.

Assume you are planning a Construction Project. The duration of this project is one year, and you anticipate the Construction work will go on and has to pass through the upcoming rainy season. Based on the weather report and your construction management work experience, you foresee moderate to heavy rainfall in August and September.

Isn't that sound like a Risk? Yes, indeed.

Your construction work will be affected if you don't plan the work considering the rain and take precautions. You will complete excavation and steel erection work before the rainy season, construct a temporary warehouse to store construction materials like Cement to safeguard them from wetness, avoid doing exterior work like painting and majorly work on interior work like plumbing, electrical, and carpentry during the rainy season. Won't you?

So, in this example, you anticipate the Risk event of Rain. This is the KNOWN part of KNOWN-UNKNOWN. Remember, Risks are KNOWN-UNKNOWN.

Now let's talk about the UNKNOWN part of the risk. In this example, can you precisely say which dates it will rain? How long it's going to rain? Will it record 7 cm or 25 cm in the rain gauge? Will the rainy season show up a little earlier this time due to Global warming? No. These questions cannot be answered even with advanced Weather forecast systems and years of experience.

The reason why we can't know exactly answer these Questions is Ambiguity. In Risk management, ambiguity is described as unclear and not knowing what to expect or how to comprehend a situation. There are two categories of ambiguity: Situational ambiguity, which is about more than one possible outcome, and conceptual ambiguity, which is about a lack of adequate understanding.

The only known way to kill ambiguity in our example is to experience the rainy season, record rain poured, and measure the cost and time impact it created on the Construction project using lagging metrics. Because when an anticipated risk occurs, the Probability becomes 100%, it is also possible to measure the impact precisely, as uncertainty ceases to exist.

No Uncertainty means No Ambiguity.

But in real Projects, you can't let risks happen because you are not fully aware of their Probabilities and Impact. We do risk management using assumed or predicted Probability and Impact for every anticipated Risk, and that's how we cover the UNKNOWN part of the KNOWN-UNKNOW.

All right, now let's learn what UNKNOWN-UNKNOWNs are

This is all about "Issue.”

UNKNOWN-UNKNOWNs are unforeseeable or unimaginable events and situations that could impact the project and can only be sensed after they occur and become real.

Why can't certain situations and events that impact the project be foreseen or imagined?

Because we are unaware of their existence, and they are entirely outside our existing knowledge and experience. Since we don't know their presence, there's no point in talking about their probability and Impact. Therefore, they are UNKNOWN-UNKNOWNs.

UNKNOWN-UNKNOWNs Risks are emergent in Nature. We can only sense them after they occur.

In Risk Management, the Risks are identified as much as possible either in Identify Risk Process during Project Planning Phase or periodically in the Monitor Risk Process in the Monitor and Control phase.

There will still be some Risks that will go unidentified in both Identify Risk and Monitor Risk Process.

Reasons:

1. Situational: It is uncommon to see an aggregated effect created by interactions between project elements such as Requirements, Stakeholders, Enterprise Environments Factors, Project context, Project Phase, Elements in Project Governance Framework, etc.

2. Ambiguity: The Project Team could have undertaken a project they have less or no experience with. Significantly less know-how, project dynamics awareness, and less or no subject matter expertise. This could lead to cause-and-effect confusion, unclear or misleading events, and situations open to more than one interpretation.

How to Manage UNKNOWN-UNKNOWNs?

There are two ways.

1. Probe-Sense-Act: Sometimes, there is no way to proactively identify UNKNOWN-UNKNOWNs and manage them as KNOWN-UNKNOWNs (Risks). When an UNKNOWN-UNKNOWN has happened, you won't see it until it emerges and shows up with some indications which are not beneficial for the Project. Now you have no other way than to react to the problem. These emergent Risks are called "ISSUES.” Issues occur during the project execution phase. The project manager has to check the project work performance data generated in the Direct and Manage Project Work process; this is probing. We can sense open issues with probing and create "workarounds" to resolve them. It won't be hard for the project team to probe and sense Issues because issues are roadblocks, impediments, and obstacles, that affect project progress and objectives and demand immediate attention for resolution.

Unprecedented absenteeism in your project due to Pandemic, Internet outrage in your organization due to under ocean Fiber optic link bitten by a shiver of Sharks, Customer comes up with a new feature for which JAVA skill is required, which is not available in your team, sudden rise in warranty claims due to a component failure in your product in the field are some of the examples of project issues.

2. Effective Risk Monitoring: According to PMBOK6, Project Risk Management Chapter, Monitoring Risk is an iterative process to identify new risks and evaluate the condition of already identified Risks. These newly identified Risks are the ones the project team failed to recognize during project planning due to ambiguity and situational conditions they couldn’t comprehend.

How come the team can identify them now, not during planning? During project execution, the team's understanding of the project improves, so they can now see how project elements interact with each other better and use Project work performance data from the Direct and Manage Project Work process to provide telltale signs about issues to happen.

The project team put these newly identified Risks (which would have become issues if not identified in the Monitor risk process) in the risk register. The team will manage the new Risks proactively by creating risk responses and contingency reserves and avoiding addressing them as issues with reactive approaches.

Project Management loves Proactiveness and averses Reactiveness.

Monitor Risk Process is an effective Instrument to convert many or some UNKNOWN-UNKNOWNs to KNOWN-UNKNOWNs so they can be managed as Risks proactively and not as Issues reactively.

Issue Management is crisis Management. The Team has to create a Workaround to resolve the issue and request Time and Money to execute the Workaround. For this, the Team has to raise a Change Request (CR) and await CR approval to incorporate the requested time and money into the Schedule and Cost baselines. Don't forget the Team has to do all these despite the issue is still open, bothering the Project and demanding a resolution sooner.

Let’s Compare Risk and Issue

By now, you would have a fair understanding of Risks and Issues.

Risk is the Future tense of an Issue, and Issue is the Present tense of a Risk.

If an uncertain condition or event is anticipated and identified, you have prevented or prepared to mitigate a future Issue by managing the identified uncertain event or situation as Risk.

Conversely, if you fail to identify or are unaware of project risk and let it happen, now you have an Issue. Issues are real as they have already occurred—otherwise, present tense of Risks that we couldn't or missed to foresee earlier.

The Probability of Risk is 0 < P < 1, whereas the Probability of an Issue is P = 1 as it has already occurred.

For both Risk and Issue, the Impact or consequence is always > 0. Risk will impact the project positively if it is an opportunity and negatively if it is a threat. For the PMP exam, remember Issues will always affect the project negatively.

How are Risks identified, and do Issues show up in Projects following the Predictive Development approach?

Risks are identified as part of Identify risk process conducted during project planning using tools and techniques like Expert Judgment, SWOT analysis, Assumption and Constrain analysis, Prompt list, and Risk workshops.

Next, Risks are identified as part of the Monitor risk process during project execution using project learnings, analyzing work performance data produced by Project management processes to probe and sense potential issues by establishing cost, technical performance, and schedule management indicators, using leading metrics and forecasting tools like Trend chart and improved stakeholder engagement. Monitor Risk is an iterative process conducted at regular intervals across project duration. This will help the project team to identify Risks or, in other words, potential issues the team missed, couldn't imagine, or foresee in the initial Risk Identification process conducted during project planning.

The Team does its best to convert as many Issues as possible into Risks and proactively manage them using Contingency reserves and planned risk responses. However, some issues may remain unidentified in the Monitor Risk and Identify Risk processes, emerging later and hindering project progress. The Team will notice them after they happen. Now the Team cannot use Risk Management to manage them proactively. They have no choice other than to get into crisis management mode. The Team will work on creating a workaround to resolve the open Issue and uses Management Reserves to execute the workaround.

How Risk and Issue are managed in Projects following the Predictive Development approach?

Once Risks are identified, the project Team will have adequate time to assess and rank them and plan for appropriate Risk responses along with suitable strategies. These responses will be executed to mitigate if the anticipated risks happen in the future. Nothing is for free in project management, including Risk Responses; hence the Team has to estimate the time and money needed to execute the planned responses and keep them inside Project Schedule and Budget. These Time and Money dedicated to Risk responses are called Contingency reserves.

Contingency reserves are part of Schedule and Cost baselines, which means the Project Manager can use them without management’s approval when the anticipated Risks happen. No Change Request is needed to get the necessary money and time to mitigate the Risk. So Convenient! Isn’t it?

This is why Project Managers and Teams prefer to identify as many risks as possible and use the Risk Management process to handle them proactively.

Then how about Issues?

The Project has to manage them reactively.

Issues are uncertain events that were unforeseeable or unimaginable to the Team until they show up and become a reality and need immediate attention of the team to resolve them.

Unlike Risks, the Project Team won't have either planned risk responses (Action items to attack the Risk) or Contingency reserves because they were unaware of the issue's existence.

Therefore, the Team will create a "Workaround" to resolve the issue and estimate how much time and money is needed to execute the workaround. Since the workarounds are unplanned works, the team will not find Time and budget inside the Schedule and Cost baselines.

The Team will raise a Change request to get the required time and money. The Management will review and approve the Change Request (CR) to move the requested time and budget inside the baselines from Management reserves.

Management reserves are meant for "unplanned, in-scope" project activities that appear during project execution.

Management Reserves are controlled by the Management, mainly in the control of the Sponsor. PM can't use them without the approval of the Management, for which the PM has to follow the integrated change control procedure and raise CR.

Projects will have both Schedule and Cost Management Reserves. Management reserves are outside the project's Schedule and cost baselines and calculated as a percentage (roughly 5% - 15%) of the original project schedule and cost.

For example, after the planning, it is estimated that the project Schedule is 100 days and costs 1 million $. Assume the Management decides 10% of the entire schedule and cost (baselines) as Management Reserve. If so, the Schedule Management reserve will be 10% of 100 days which is 10 days, and the Cost Management reserve will be 10% of 1 million $ which is 0.1 million $.

Project Schedule = Schedule Baseline + Schedule Management Reserve (110 Days = 100 Days + 10 Days)

Project Budget = Cost Baseline + Cost Management Reserve (1.1 million $ = 1 million $ + 0.1 million $)

Okay, I know we have taken a tangent to learn about Management Reserves. Now let's go back to issue management.

After creating the Workaround, the estimated time and money needed for executing the workaround will be allocated from the Management reserve based on the respective CR approval.

The project Manager and Team have reacted to the emerging issue and resolved it after its occurrence. Is this convenient? No, but inevitable.

We need to acknowledge that identifying every future Issue (that is, Risk) is impossible due to ambiguity and situational conditions, which are beyond comprehension. But the team can reduce the number of project Issues by periodically performing Risk identification throughout the project through the Monitor risk process.

Key differences between Risk and Issue

During Project execution, the Team will face many Issues such as Roadblocks, Obstacles, and Impediments. There can be even more than a hundred Risks identified, and it is hard for the Team to remember all of them. To find whether the occurred is an Issue or Risk, the Team has to refer Risk Register. If the Issue occurred is located in the Risk Register, Team would follow the Risk management procedure else the Issue Management procedure.

I hope we are now clear about the relationship between Issue and Risk.

Next, Let’s see the relationship between change Request, Issue, and Risk.

Issues are what happens at the "PRESENT,” and Risks are what we anticipate in the “FUTURE" if so, are Change Requests have something to deal with the "PAST"? The answer is Yes.

What is a Change Request?

Change Requests are native to the Predictive/Plan-driven project development approach. In Predictive, first, we plan almost everything and then execute the work. As part of planning, we create all the subsidiary management plans, project baselines, and other project documents and integrate them to make the Project management plan.

The project planning process ends after the Project management plan, and the project scope, schedule, and budget are reviewed and agreed upon by key stakeholders like the Sponsor and customer. This usually happens during the project kick-off meeting.

In the Planning phase, we can make any number of changes to the Project Management Plan, the subsidiary Management plans, Project Baselines, and other project documents without any restriction and don't have to follow any change management procedure. After all, in planning, we are in the process of creating Project plans and baselines.

But once the Project Management Plan, the subsidiary management plans, project baselines, and other project documents are created, reviewed, and approved by the key stakeholders, then changes to these artifacts are restricted. Usually, this is after the Kick-off meeting. This means the project has entered the Execution Phase.

Why are Changes controlled to Project Management plans and Project baselines in the execution phase?

Because to measure Project Performance, references are needed to compare actual work performance data generated during project execution. Scope, Schedule, Cost baseline, and Project Management Plan act as these references. They make the projects more predictable and controllable.

Remember, during the execution phase, Changes to the Project management plan and Project Baselines are controlled, not forbidden. Necessary changes to retain and achieve planned project objectives must be reviewed and incorporated into planning artifacts spite the project being in the execution phase. This is where the Perform integrated change control (PICC) process comes in.

PICC helps the Project team to incorporate necessary changes to Planning artifacts in a controlled, informed, and holistic manner. The needed change shall be raised as Change Request (CR) by filling up a Change Request form with information like Description of the Change, Reason for Change, Impact on Project deliverables, possible options to implement the change, CR number, CR initiator name, etc.

Once raised, the Change Request Form will be reviewed and approved, deferred, or rejected by the Change control board (CCB). CCB is a formally chartered group of qualified stakeholders with the authority to review and approve CRs. Usually, Sponsor and Subject matter experts will be part of CCB.

What causes Change Requests?

When Project work is done, we may end up in situations to make changes to our project artifacts like Project baselines, Project Management plans, Project documents, and sometimes deliverables.

Scenario 1: Work performance data are analyzed for performance measurement during project execution by Variance and Trend analysis. Corrective and Preventive actions are taken to address identified Project performance issues. Corrective and Preventive actions need additional time and budget as these are unplanned work but essential.

Scenario 2: We tend to find defects in product testing, verification, and validation processes. To fix the defects, the team needs additional time and money. Without fixing the defects, the deliverables will not be accepted.

Scenario 3: We tend to modify the project plan and project documents during the execution phase. For example, Changes in Requirement documents due to the availability of new or modified features, baselines may change due to changes in customer expectations, etc.

Considering all three scenarios, we need Change Requests to manage Corrective actions, Preventive actions, Defect repairs, and modify formally managed project plans and documents.

The interdependencies between CR, Risk, and Issue

The flow chart below summarizes the CR, Risk, and Issue interdependencies.

Start from the top and go through every possible branch to understand how CRs, Risks, and Issues interact and influence each other. This will make you create a mind map that would help you to take real exam questions from CR, Risk, and Issue processes confidently.

Pointers from the above Flow chart

1. Poorly managed CR may trigger many Risks and create Issues. For example, a new Feature is added to the Scope baseline without considering the additional cost and time needed to implement it. This means no changes done to the cost and schedule baseline. The Team shall not have adequate time and budget to implement this new feature and is not aware of the impact this feature will have on other aspects of the projects. This may result in chaos.

2. To implement an Issue's Workaround, a change request (CR) is needed to move the required fund and time from Management Reserve to the Cost and schedule baselines.

3. Risks Identified during the execution phase in the Monitor Risk process get their Contingency reserves (cost and schedule) inside cost and schedule baselines through CR.

4. Once a CR is approved by the CCB, a thorough Risk review is required before implementing the approved CR to understand whether the CR brings in any inherent Project Risk.

5. CRs created for implementing corrective actions, defect fixes, and changes to project documents are workarounds developed to address open Issues.

6. CRs in the form of Preventive actions created during project execution are, in essence, Risk responses to address Risks identified in the Monitor Risk process to prevent future Issues.

7. If a CR has been raised for implementing corrective or preventive action. The Project Manager has to check the Risk Register to see whether the CR has already been identified as a Risk. If so, the new CR can be rejected, and the corresponding risk response will be executed.

All right, folks! By now, you should see how Change, Risk, and Issue Management are interdependent and influence each other. That is why organizations integrate and have a singular approach to managing them effectively.

Remember this for the exam; Risks are uncertain events anticipated to occur in the Future. Issues are roadblocks, impediments, and obstacles bothering the project in the Present. Change Request is used to change things we did in the Past for valid project needs.

If you worry about yesterday's failures, then today's successes will be few. The future depends on what we do in the present - Mahatma Gandhi.

Key Takeaways for your Exam

• Risk is the Future tense of the Issue identified during the Planning phase/Monitoring risk process.

• Issue is the Present tense of the Risk encountered during the Execution phase.

• For Risk, create Risk responses and use the Contingency Reserve.

• For Issues, create workarounds and use the Management Reserve.

• PM doesn’t need any approval to use the Contingency reserves but requires management's approval to use Management reserves.

• An unidentified Risk is an Issue and needs to be handled by creating a workaround if it occurs.

• If a CR has been raised or an Issue has occurred, check the Risk Register to find whether they are already part of it and, if so, use corresponding planned Risk responses.

• Poorly managed CRs may create many Issues and trigger Risks.

• Monitor Risk Process is an Instrument to prevent many or some Issues by identifying them earlier as Risks and helping to manage them proactively.

• CR is needed to get contingency reserves for newly identified Risks in Monitor Risk Process. Risks identified during the Planning phase have contingency reserves already inside the cost baseline.

• Risks can be both Positive and Negative. Issues are always Negative.

• Project Documents: Change log, Risk Register, Issue Log for Change Requests, Risk, and Issue, respectively.

• The Risk owner is responsible for managing the identified Risks if they occur using the planned Risk Response. The Issue owner is responsible for resolving the issue using the Workaround.

If you’re a PMP exam aspirant, remember, “VICTORY LOVES PREPARATION.”

And we are glad that you’re doing the right thing.

Happy learning!

Please let us know your feedback. Kindly drop them in the comment section below.

References and citations

1. A guide to the project management body of knowledge (PMBOK guide) / Project Management Institute – the 6th Edition.

2. A guide to the project management body of knowledge (PMBOK guide) / Project Management Institute – the 7th Edition.

3. Managing Change in organizations: A Practice Guide/ Project Management Institute.

4. The standard for Risk Management in Portfolios, Programs, and Projects / Project Management Institute.

5. Navigating Complexity: A Practice Guide / Project Management Institute.

6. Project Management: A systems Approach to planning, scheduling, and Controlling, by Harold Kerzner, the 12th Edition.

7. Piney, C. (2012). Integrated project risk and issue management. Paper presented at PMI® Global Congress 2012—EMEA, Marsailles, France. Newtown Square, PA: Project Management Institute.

8. Love, M. L. (2002). Risks, issues, and changes—help, I’m drowning in logs! Paper presented at Project Management Institute Annual Seminars & Symposium, San Antonio, TX. Newtown Square, PA: Project Management Institute.

9. Baker, E. (2007). You've got way too many issues! Paper presented at PMI® Global Congress 2007—North America, Atlanta, GA. Newtown Square, PA: Project Management Institute.

10. Harris, E. (2008). Project risk and uncertainty: a longitudinal case study. PMI Global Congress—EMEA.

11. Thamhain, H. J. (2013). Managing risks in complex projects. Project Management Journal, 44(2), 20–35.

All rights reserved.

Copyright and License to use

This blog is an intellectual property of Ezbrain Edutech Private Limited. Readers can use it for their individual learning needs and share it with others for personal use. It is prohibited for other companies and legal entities who intend to use this blog for training purposes or to benefit themselves, their clients, and customers in any possible way. To republish or reproduce our content, you must obtain our written permission.

Disclaimer

The views, facts, and opinions expressed in this blog are based on the author's professional experience, beliefs, and facts collected from reference materials mentioned under References and citations. We did our best to ensure the content's correctness to make it reliable. Learnings from this blog help the learners, in general; however, we neither guarantee this blog will make the learners clear any project management certification exam nor its correctness. We are not liable for any consequence of applying this blog's learnings and advise readers to do things at their discretion.