Difference Between Issue, Risk, and Change in a PMO

palmspringschairs640x80

Your Project Risks, Project Issues, and Project Change are key controls to establish in a PMO and your Projects. I like to call these your exception controls because they control the exceptions to your plan. In this article I will explain the differences of each, how they relate to each other, and how best to use them. To start out, I first want to give explain the relationship between each control:

  • Risk is a problem that could happen
  • Issue is a problem that has happened
  • Change fixes the problem that happened

Project Risk
is a problem that could happen in the future and effect your time, cost, scope, or quality. All  your risks should be managed in a central repository usually called a Risk Register. A risk is broken down to three main parts which is probability, impact, and mitigation. Probability is the likelihood that the risk will happen. Is there a 20% that the risk might happen or 70%? Impact describes how your project will be effected if the risk was to happen. Impact can further be broken up into four parts. This would be your time, cost, scope, and quality. Mitigation are the actions you take to eliminate or reduce the probability and impact of the risk. When you have taken all reasonable actions to mitigate a risk, what you have left is your accepted risk. Risk acceptance is key as you are saying you have done as much as you reasonably can and if the risk happens you will deal with it (in the Issue process). To end, here some questions to ask in Risk Analysis:

  • What is the Risk?
  • What is the probability the risk will happen?
  • What is the impact if the risk was to happen?
  • What actions can we take to mitigate the Risk?

Project Issue
is a problem that has happened. Think of it as an open question or decision that needs to be made in order to move forward with one or more deliverables. I like to manage my Issue in a matrix where I list all the potential options vertically and then the analysis horizontal. Below is a simple example of the matrix I would use:

Your Issue Name Here:

optionbenefitscostrisk
Your first option hereCheapestSome features lostThe issue could come up again
Another option you haveFastest to ImplementExpensiveNo additional risks
Option from the BobsImproves performance of deliverable, Has best featuresMost expensive and most effort to implementAdds risk to meeting next milestone

Start out with a straw man and then review with your subject matter experts and relevant project team to review and update the matrix. Once everything looks correct, have the owner(s) review and approve.

Project Change
Fixes the problem that happened. The Change Request is where you review the changes you want to make to the approved Charter and Project Plans. Change can effect four areas: Cost, Time, Scope, and Quality. Once the impact of the change is reviewed, a decision is made to move forward with all or part of the change. The people that approve the change should be based on the severity of the change. Simple changes could be approved by the Project Manager, a significant change could require a Project Steering Committee that includes people from Finance, Risk, and the Business. To end, here are some questions to ask in a Project Change Request:

  • What is the change?
  • How will your cost change?
  • How will your scope change?
  • How will your schedule change?
  • How will your quality be effected?
  • What risks will be introduced or mitigated?
  • What are the benefits of the change?

As you can see, your Project Risks, Project Issues, and Project Change are key controls to establish in a PMO framework and your Projects. These exception controls ensure that your Project Plans do not get out of control.

Note: This is not to be confused with a production change which makes changes into production. A project will do a a production change (Request For Change) at each release into production.

One thought on “Difference Between Issue, Risk, and Change in a PMO

  1. TJ

    When managing risk mitigation and looking at lessening the impact of the risk, consider actions that can be taken both in advance of the risk occurring and post occurrence. Ask the question “What actions can we take if the risk occurs?” Yes, this overlaps with issue management, but the key here is timing. Creating a risk contingency plan in advance of the risk occurring means that you can react in a controlled fashion by implementing a prescribed plan to resolve the issue. This is all towards lessening the impact of the risk once it occurs.

    Reply

Leave a Reply