Uh-oh. This is a show-stopper. We can’t complete the project on time because the part that we need won’t be available for another 3 months! What will we do?
If you have managed projects for very long, you have run across a situation like this. Is this a risk or an issue? Does it matter? A risk describes an uncertain event that might happen. It is something that people are worried about. 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 part 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 part we need does not arrive on time.” In this case, we are not certain that we have a problem yet.
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 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 100 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 100 concurrent users and it does, the 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 we have 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. These get a lot of attention in most projects.
That is the difference between risks and issues. Handling each appropriately will communicate more effectively and make management much easier.