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
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?
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:
|Your first option here||Cheapest||Some features lost||The issue could come up again|
|Another option you have||Fastest to Implement||Expensive||No additional risks|
|Option from the Bobs||Improves performance of deliverable, Has best features||Most expensive and most effort to implement||Adds 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.
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.