Duraideivamani Sankararajan, PMP: Based on my experience in project and program management, I admit there are many project managers who do not understand the difference between risks and issues. Such a scenario heavily impacts the project and stakeholders, as the responses to risks and issues differ.
The key difference is an “issue” already has occurred and a “risk” is a potential issue that may or may not happen and can impact the project positively or negatively. We plan in advance and work out mitigation plans for high-impact risks. For all issues at hand, we need to act immediately to resolve them.
NK Shrivastava, PMI-RMP, PMP: Risk is an event that has not happened yet but may; an issue is something that already has happened. The main differences are related to timing and probability. Because of these differences, the language used to describe risks is future tense: “If this happens, then this will be impacted.” For issues, the language used is in present tense: “We have this problem. How should we deal with it?”
Mr. Sankararajan: Issues are recorded separately from risks in the issues register. In it, we track the issue, issue owner, open date, target date for closure, with whom the issue is pending, intermediate updates available on issue closure, criticality of the issue and its impact.
Mr. Shrivastava: I call the issue register the “issue log” because it denotes logging of something that already has happened.
In the risk register, I include the probability, impact, response strategy and also the timeframe for the risk event.
Mr. Sankararajan: It's also important to determine if issues occurred from an identified risk. If the source of an issue is tracked and known, project managers can determine the percentage of issues that were identified earlier at risk stage. For issues not identified as risks, project managers can analyze how they were missed in the first place and if they merit inclusion in the risk identification process.
Mr. Shrivastava: When a risk is materialized, I move it to the issue log and the person who was assigned to the risk now works on the issue. I don't flag issues that were identified as risks differently in the issue log, but I do keep track of the risks that were materialized in the risk register. As part of lessons learned, I review these risks to better plan future projects.
Mr. Sankararajan: Issues typically do not need a mitigation plan, since most already are at hand and need to be acted upon immediately. But if an issue is not impacting any of the project attributes for now but could in the future, a mitigation plan is a possibility.
Mr. Shrivastava: There is no such thing as “mitigating an issue.” Rather, issues are resolved. Mitigation plans are all about reducing the impact or probability of a risk event.
For issues, you need an action plan that has action items listed in priority. For example, consider when someone leaves the project team. This is an issue, since the event has happened already. The list of action items could include hiring someone quickly, hiring someone on contract, delaying the project or outsourcing the project. These action items are discussed, and action is initiated right away.
Issues recorded in the issues register should be discussed almost every day; risks recorded in the risk register should be reviewed periodically—weekly or less frequently during status review meetings.
— Duraideivamani Sankararajan, PMP
Duraideivamani Sankararajan, PMP, is a program manager at IBM in Bangalore, India, who has 22 years of experience in software development and management.
NK Shrivastava, PMI-RMP, PMP, is a project management consultant and CEO of RefineM in Springfield, Missouri, USA.
Mr. Sankararajan: Issues recorded in the issues register should be discussed almost every day; risks recorded in the risk register should be reviewed periodically—weekly or less frequently during status review meetings.
Mr. Shrivastava: We review the open issues on the issue log every week. Generally, we don't review the risk register as often. But how often you review risks depends on the nature and size of the project.
For example, if the project is two years long, it would be overkill to review risks every week. If a project is three to six months in duration, it's good to review risks every month. If a project is less than two months, you might review risks every one to two weeks. If a project has a lot of uncertainty and things change quickly, you might review the risk register every week.
It also depends on timing of the project. You should be more focused on the risk register at the beginning of the project when you have a lot of uncertainty and risks are highest. You should be more concerned with the issue log toward the end of the project when you are trying to close outstanding issues. PM
