Appendix B: Issue Tracking Process

Systematically identifying and tracking project issues facilitates the efficient resolution of critical problems and is therefore necessary for good project management. In fact, many people say that driving issue resolution is one of the most important responsibilities of the project manager. This process discusses a basic method for efficiently tracking issues, as well as clarifying the confusion that often exists in distinguishing an issue, task, or risk. An electronic copy of this process and template can be downloaded from http://www.xocp.com.

Definitions

Overview	When you mention the term issue to a group of people, each person may be imagining something different, and in a certain context, each of them is probably correct. Therefore, it is critical to proper communication that everyone uses the same definition. This process uses the following definitions.
Issue: Category 1	A technical or business situation with no known solution that is negatively affecting a project.
Issue: Category 2	A technical or business situation that is negatively affecting a project for which there is a proposed solution that hasn't been fully implemented yet.
Issue: Category 3	A technical or business situation that is out of your control and negatively affecting a project.

Common Confusions

Tasks versus issues	Confusing tasks and issues is a common mistake. Tasks have these common characteristics: They can be and should be planned (whereas issues are unplanned). You mostly know how to complete tasks (issues may have unknown solutions). They are in your control to complete (issues may be out of your control). For example, an overdue task is not an issue per se, but rather a symptom of an issue. The real issue might be that resources were diverted from your project to a higher-priority one (something out of your control), or you encountered an unexpected obstacle for which there is no obvious way to circumvent (an unknown solution). Project managers should be on the lookout for symptoms, but they need to dig down and identify the root issue.
Risks versus issues	Risks are forward looking, whereas issues are real-time. A risk may, and often does, turn into an issue; however, project managers should strive to not let this happen. By definition, a risk is an unplanned future event that either positively or negatively affects your project. While the risk event is not officially planned (as part of your WBS and Gantt chart), it has been identified (how else would you know about it?). Once a risk is identified, project managers should create contingency plans for the risk. Then, if and when the risk event does happen, it does not turn into an issue but rather triggers the contingency plan, which should neutralize the unplanned risk event. See the Risk Management Workflow in Chapter 8 for further details on risks.

Why We Track Issues

Issues need visibility until they are resolved	One of the most valuable contributions that a project manager can make is simply to keep all key project indicators visible. Once projects leave the planning phase and enter the execution phase, things can start to get very chaotic. Priorities can change rapidly and issues that are receiving appropriate attention one minute are shuffled below others the next. This does not necessarily mean that an issue is no longer important, just that it's become old news. The project manager must give attention and visibility to even aging issues until they are fully resolved.
Issues are often interrelated	Issues tend to lead to more issues. As complications increase, it is important that the project manager be able to rise above the dust and understand how the many issues and plans are interrelated. If issues are simply handed out to various individuals to handle, they may never see how what they are working on affects what someone else is working on until it is too late.
Issues are a leading reason why projects fall behind schedule	It's no surprise that issues are a leading reason that schedules are not met. Ideally, better upstream planning will minimize downstream issues; however, some issues will always persist. To keep your project on track, you need to systematically track and resolve issues.

Integration

Status reporting	A summary of the issues captured in this process should be integrated into the project's periodic status reports.
Action items	An issue is not a task or an action item. However, as part of your issue resolution plan, one or more action items may be assigned. These should be added to the action item list, while the core issue should remain on the issues list. See the Action Item Tracking Process in Appendix C for details.

Using the Issue Tracking Template

Done	Put a checkmark in the Done column and gray-out the row when an issue has been resolved. Move the whole row to the bottom of the table to keep only open issues visible at the top.
Issues	Provide a name and short description of the issue.
Priority	Assign a priority to the issue, such as High, Medium, or Low. This will enable the reader to quickly identify the high-priority issues. If needed, you can sort the entire list of issues by priority.
Owner	Assign ownership for resolving the issue to an individual.
Date logged	Enter the date that the issue was added to the issue list. If needed, you can sort the entire list by the date on which issues were logged.
Date due	Assign a target date for resolution of the issue.
Notes	Enter any comments or plans for resolution of the issue, such as the general approach and specific action items that have been assigned.

[Project Name] Issues

Done	Issues	Priority (H-M-L)	Owner	Date Logged	Date Due	Notes
	Issue # 2	M	Wilson	May 3	June 5	Enter comments here
	Issue # 5	M	Price	May 15	June 10	Enter comments here
Closed issues:
√	Issue # 1	M	Chin	May 3	May 30	Enter comments here
√	Issue # 3	L	Smith	May 5	May 22	Enter comments here
√	Issue # 4	M	Smith	May 12	June 20	Enter comments here