Issues are major problems that will impede the progress of your project and are not totally within the control of the project team. Since they are not totally within your control, they require a more rigorous and structured process to resolve. You don't have the option to say that your project is not large enough to have issues. When issues occur, they occur and need to be dealt with. All projects should be prepared to manage issues as they arise.
All projects should track issues with an Issues Log. The Issues Log contains one line per issue, with a brief explanation and a current status indicating whether the issue is open, closed, in-progress, etc.
You need to manage issues in larger projects more rigorously. This includes a more formal process for surfacing potential issues. The Issues Submission form is used to capture, screen, and evaluate issues. Each form is used to describe one specific issue. Be sure to include enough information so that the issue can be identified and tracked, but not so much information that the form becomes a report. An Issues Submission form could include the following information.
- Issue ID. This is used to track the issue. It could simply be a 1,2,3 sequential number. You could also be more sophisticated and include a smart coding scheme to help categorize the issue. The same Issue ID is also used on the Issue Log to tie the documentation of an issue to the tracking log.
- Date reported. This date documents when the issue was identified.
- Reported by. This documents the person who reported the issue to begin with. This person might be needed to help describe the problem.
- Description of issue. Describe the issue with enough detail that others will be able to understand the problem. The general rule for issues is that if you can't define the issue, you can't resolve it.
- Status. This field describes the overall progress of the Issues Management Process. This field value is usually Pending (but shouldn't be for long), In Progress, or Complete. (If you have a status of OnHold, it's probably not an important issue.)
- Assigned to. This field identifies the person or persons assigned to look for alternatives and impact to the project.
- Impact of doing nothing or delaying the resolution. Describe the impact to the project if the error is not resolved. Also, describe the consequences of any delay in resolving the issue. This will help identify the sense of urgency required to resolve the problem.
- Alternatives and recommendation. Document the different alternatives for resolving the issue (if there are multiple alternatives). This will usually be completed after the person assigned to resolve the issue performs initial analysis. For each alternative there should be an estimate of any cost, effort or duration impact on the project. The project team member and project manager should then make a recommendation as to how to proceed.
- Final Resolution. Briefly describe how the issue was resolved. This should include the rationale for choosing the alternative for the benefit of readers that were not a part of the decision.
- Date Resolved. Note when the issue was resolved.
When each issue is resolved, the status would change to "closed" and the Issues Submission Form would be saved as a part of the overall record of the project.