Key Features of Issue Management System

The actual details of the issue management system are not complicated, and in most situations will share many similarities with your change control system and risk tracking system. While issue management systems will vary in complexity and sophistication depending on your organization and the needs of your project, there are key features that they should all possess.

• Clear Process Clearly define and communicate how issues are submitted, how they will be resolved, how and when outstanding issues will be reviewed, and what is needed to officially close an issue. Not complicated; generally very common sense stuff here.
• Escalation Procedures Part of the overall issue resolution process, but not always thought about in advance. Define the types of issue that warrant escalation to higher levels of management. Generally, there is a single escalation process for a project that is leveraged for anything impacting the critical success factors (issues, changes, risks).

  While the spreadsheet approach to an Issue Log has limitations, just the fact that you are documenting issues and actively managing them will put you light years ahead of many project environments.

• Issue Log The mechanism used to document and track project issues. Most common mechanism is a spreadsheet, but there are limitations to this method. Other options include database systems and collaboration tools. There are pros and cons to each choice. The important thing is to use a tool that matches the needs of your project. We'll discuss this in greater detail.
• Issue Log Administrator Someone needs to serve as the central control point for the issue log. Usually, this will be you, the project manager.
• Issue Data Points While the specific mechanism used for the Issue Log and the exact information needs will vary across projects, there are a core set of data points that should be considered for any issue logged. The recommended data points are listed in Table 13.1.

  Table 13.1. Recommended Issue Log Data Points

  Element	Definition	Notes
  Issue ID	Unique ID that can be used to clearly track this issue.	Best practice
  Issue Type	Category of issuedomain values will vary depending on project.	Example setTechnical, People, Business, Supplier
  Issue Name	The short name for the issue.	Generally less than 40 characters
  Issue Status	The current state of the issue. This should be aligned with the process workflow established for issue resolution.	Example setOpen, Assigned, Resolved, Closed In some settings, Open and Closed values may be sufficient
  Issue Priority	Summarizes the importance and severity of the issue.	Typical domainCritical, High, Medium, Low
  Issue Details	The full details of the issue.
  Potential Impact	List the potential impact to the project critical success factors if issue is not resolved.
  Date Submitted	Date issue is identified and accepted.
  Submitted By	Person who originated the issue.
  Date Assigned	Date issue assigned to someone for follow up.
  Assigned To	Person assigned to take action on the issue.
  Target Due Date	Target date for issue resolution.
  Date Updated	Date that issue log entry was last updated.
  Date Resolved	Date that issue is resolved.	This field may not be needed in many cases. Date Closed may suffice.
  Date Closed	Date the issue is closed.
  Progress Notes	Contains updates and information regarding actions items, findings, and steps to resolution.
  Related Items	In many cases, one issue is associated with other issues or spawns other issues/action items. It is good to track this association.	May also be used to link to supporting documents.