Description | Related Tools | |||
Toggle All | Print Page |
Issues vs. Risks
There is often confusion between Issue Management and Risk Management and how the activities of each interface and interact with each other. According to the Project Management Body of Knowledge (PMBOK):
- A risk is an uncertain event or condition that, if it occurs, has a positive or negative impact on a project's objectives.
- An issue is a point or matter in question or in dispute, or a point or matter that is not settled and is under discussion or over which there are opposing views or disagreements. Often project issues are first identified as a risk and through the risk management planning process may already have a planned approach to managing the issue.
Project risk management includes the processes for conducting risk management planning, identification, analysis, responses, and monitoring and control of a project. The objectives of project risk management are to increase the probability and impact of positive events and decrease the probability and impact of events adverse to project objectives. Project issue management includes utilizing the outputs from the project risk management planning if the issue was identified as a risk during the risk planning processes.
As issues arise during the course of managing a project and a project team, an issue log is commonly used to document these issues. This log includes a description of the issue, the assignment of each issue to one or more individuals for resolution, a target date by which the issue needs to be resolved, and other related information. The log helps the project team monitor and control issues until closure is reached.
Requirements
In general, all projects, regardless of type or size, should have an issue
tracking system or log where issues are regularly managed and monitored on a
regular basis by the project manager. As issues are identified and resolved, the
issue log provides historical documentation of concerns that have been addressed
throughout the project life cycle.
- Escalation Process – An issue escalation process should be determined as a part of the overall issue management planning activities and should be documented.
- Documentation – All issues, regardless of how minor they seem, should be centrally documented using some type of issue tracking system or log. An issue log template is provided at the end of this guide for use in the absence of something more sophisticated.
- Minimum Requirements - Tools used to manage issues should contain (at a minimum) a unique identification number, priority, issue description, impact summary, action steps, current status, and issue owner.
- Resolution Statement - Issues should be stated in such a way that it is clear how they can be resolved.
Example: Instead of “The project needs resources”, use “The project requires two mid-level Java developers before the first week of January to meet the project delivery date in April”. - Prioritization - Issues should be prioritized, assigned specific owners, with next steps and due dates documented. Issue ownership should be communicated clearly to those responsible for action items.
- 80/20 Rule - Be mindful of the “80/20 rule”, which says that 80% of the project impact will come from approximately 20% of the documented issues. Concentrate the majority of mitigation efforts on issues that pose the greatest potential threat to project success.
- Regular Review - Regular review of issues and the issue log is a highly recommended practice. The review process should occur daily for complex projects and at least weekly for simple projects. Open issues should be reviewed at each project team status meeting and progress made on the issues should be recorded in the issue log.
- Issue History - Closed issues should remain in the issue log as a historical record and to facilitate lessons learned activities.
- Review Issues - Regularly review (at least weekly for a simple project; perhaps daily for a complex project) existing project issues and identify new ones.
- Issue Log - Establish and maintain an issue log. Instructions for using the issue log should be provided within the template.
- Resolve Issues - Work towards issue resolution, maintaining close collaboration with stakeholders.
- Regular Updates - Regularly update (at least weekly for a simple project; perhaps daily for a complex project) the issue log with current information.
- Communicate - Regularly communicate (at least weekly for a simple project; perhaps daily for a complex project) with stakeholders about the status of open issues.
- Once an issue has been resolved, an official communication should be sent to stakeholders communicating how the issue was resolved.
- Documentation - When an issue is resolved, record the resolution in the issue log. Instructions for recording issue resolution should be provided within the issue log template.
- Escalation - If an issue remains unresolved for a lengthy period of time (we may want to specify a time range here), the issue should be escalated using the agreed upon escalation procedure.
- Lessons Learned - The issue log should be reviewed at the end of the project in a timely fashion so that lessons learned, can be documented and included in the project's lessons learned analysis.