Risk and Issue are two words that are often confused when it comes to their usage. Actually there is some difference between them. The word ‘risk’ is used in the sense of ‘chance’. On the other hand, the word ‘issue’ is used in the sense of ‘matter’.
Uh-Oh! This is a show-stopper. We can’t complete the project on time because the server needed won’t be available for another month! What can we do now?
This is not a new problem for Project Managers to have encountered. Is this a risk or an issue? Does it matter? Think of it for a minute. A Risk is an uncertain event. There exists a Probability associated with any Risk (1-100%). An issue does not have this attribute. If something has already happened that affects the project, then it is called an issue. In the example given in the opening paragraph, we are certain that the server we need won’t be available when we need it. This is an issue. An example of a risk would be: “We may not be able to complete the project on time if the server we need does not arrive on time.” In this case, we are not certain that we have a problem yet. Risk versus Issue can be treated as the same as Potentiality versus Actuality.
Note that it is recommended that you treat any Risk that has a probability of over 80% as a fact and include it in your Project Management Plan and not Risk Management.
To be a project risk it must be something that might affect the cost, schedule, scope, or quality of the project. If a risk will not materialize until after the project is over, then again it is not a risk to the project. It may be a risk to the program or organization, but not to the project. The same is true of an issue. Does it affect the things that a project manager is responsible for? If not, then it should be handled by those responsible for the program or organizational area.
Being able to distinguish between these is one of the hardest things for project managers understand. It causes problems because risks and issues are dealt with differently and dealing with non-project risks and issues wastes a lot of a project team’s time and energy. The examples given so far are in the scope of the project. Here is an example of a non-project risk:
“The system we are building is designed for 1000 concurrent users, but if we get more than that it might run slow or even crash.”
If the project ends when the system is deployed, then this risk will never occur during the project. If the requirements for the system say that it must support 1000 concurrent users and it does, then it is not a project risk, it is scope creep. The risk of actually getting more users than that and the ensuing consequences is the domain of business operations, not the project.
The source of this confusion is usually failure to distinguish between a project, a product, and a program. A project delivers what is asked for, often a product. It does not make claims about the value or benefits of the product. That is the domain of the program or product owner. Sometimes the project manager, program manager, and product owner are the same person, but often they are not.
Risks are documented when they are discovered, most being at the beginning of the project. The probability and impact are assessed and mitigation tasks are added to the project plan. A contingency plan may be created to document what we plan to do should the risk occur. These risks are monitored and updated as needed throughout the project. Should they actually occur, they become issues.
Issues are problems right now that the project team has to do something about. The actions that we take might involve adding tasks to the plan, extending the schedule or increasing the budget. Issues are tracked and actions are taken until they are resolved and no longer affect the project.
Handling Risk and Issues appropriately will help the Project team communicate more effectively
Hence Risk Management is Proactive while Issue Management is Reactive.
A Risk, once realized could be turned into an issue and tracked. It is important to note that not all Risks are Issues since there will be some Risks that are actually absorbed into a project or program with negligible effects.
A risk has no effect in its current state, while an issue may be problematic.
Sometimes project managers have to take the risk deliberately because there are greater chances that the organization will benefit from. These are also referred to as Opportunities.
Question: Then why do companies use Issue Tracking software products for their Risk Management needs?
Simple answer-To achieve greater project success, they simply should NOT. Issue tracking software is different from Risk Management Software.
The tools out there for Project Risk Management are of 2 types;
- Quite complex and there is never enough time in the day to understand them well enough to effectively implement good Risk Management practices.
- The same old one-dimensional Excel spreadsheet."
In either case, one of the most critical process areas in Project Management (Risk Management) gets neglected. The need of the hour is to find a project risk management solution that is simple to use yet effective to address this deficiency.
Vue-Matrix™ is a proprietary web-based Project Risk Management application that utilizes state of the art technologies to help companies manage their project risks. Vue-Matrix™ helps companies understand their Risk impacts in a tangible form so mitigation or contingency action can be recorded and implemented, thus increasing the chances of project success and saving the company money.
Unlimited Users always and all plans include all features
Click here for a free 30 day trial (no credit card required).
Anand Chittoor, PMP, CSM.
Comments