The actual details of the issue management system are not complicated, and in most situations they share many similarities with your change control system and risk tracking system. Although issue management systems vary in complexity and sophistication depending on your organization and the needs of your project, all issue management systems should possess the following key features:
- 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. This is not complicated; generally, it’s very commonsense stuff here.
- Escalation procedures—This is 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, which is leveraged for anything affecting the critical success factors (issues, changes, or risks).
- Issue log—This is the mechanism used to document and track project issues. The 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.
NoteAlthough 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 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—Although the specific mechanism used for the issue log and the exact information needs vary across projects, there is 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 issue—domain values will vary depending on project. | Example set—Technical, People, Business, Supplier. |
| Issue Name | The short name for the issue. | Generally fewer than 40 characters. |
| Issue Status | The current state of the issue. This should be aligned with the process workflow established for issue resolution. | Example set—Open, Assigned, Resolved, Closed. In some settings, Open and Closed values might be sufficient. |
| Issue Priority | Summarizes the importance and severity of the issue. | Typical domain—Critical, High, Medium, Low. |
| Issue Details | The full details of the issue. | |
| Potential Impact | Lists 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 might not be needed in many cases. Date Closed might suffice. |
| Date Closed | Date the issue is closed. | |
| Progress Notes | Contains updates and information regarding action 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. | Might also be used to link to supporting documents. |
Note
The details of the issue log depend on the intended audience and general communication needs of the project.
Leave a Reply