The Issue Log
The issue log is the document that will be used to manage the project issues. It is a document managed by the Project Manager to show the issues on the project and how they progress through to resolution. A classic example of an issue log is shown above:
The elements of the issue log are:
Issue number: A sequential number for referencing the issue
Date identified: The date the issue was identified and entered onto the issue log. This date is important as it gives a sense of how long the issue has been known to the project and can indicate whether the actions are being progressed too slowly
Identified by: The person who first identified the issue. This is then used by the Project Manager to feedback progress on the issue to this individual who identified the item to demonstrate the issue is being managed
Details of the Issue and effect: A description of the issue and what could potentially happen if the issue isn’t managed. A succinct definition can usually be provided in one sentence.
Action (issue history): The activity that will progress the issue through to resolution. This is the most important aspect of managing issues, as these actions will be agreed with the person responsible and monitored until the issue is resolved.
Agreed owner: The name of the person responsible for the resolving action. It is crucial that the owner has agreed that they are responsible for the action and when it is expected to be completed.
Date for completion: The target date for the action to be completed. This date is important for the Project Manager to monitor progress.
How to complete the issues log. When issues are first captured they should be logged on the Issue Log even if they do not have Actions at that stage — record the issue then assign resolving actions. If the issue description is large and represents several issues (or solutions) then these should be split out into individual issues. The resolving actions for the individual issues will probably be different and will be managed by a number of people.
At the start of the project it should be agreed who will update the issues log — solely the Project Manager or the wider team. If others will update the log then they must understand how it will be completed and deletions or major changes must be agreed. If the issue log is open for many people to update then it is wise to have the initials of the person who updated the log and date of the update.
The Project Manager usually has the mandate to assign responsibility but the PM must agree ownership with the individuals. Before it is clear who will own the resolving action it effectively belongs to the PM who will assign it to someone.
As issues are resolved they are regarded as closed. They should be greyed out to make it clear they are no longer to be considered but still readable to show the full history. Deleting closed issues shows a lack of transparency.
Additional techniques with the issue log. The issue log described here is suitable for most projects and has been used thousands of times. However, it can be further enhanced in the following simple ways:
- Conditional formatting can be applied to the action date to show lateness or potential delays
- Categories can be added to help group issues of a similar nature or those that apply to the same department/discipline. This is useful when the issue log grows large
- Priority can be added to highlight which issues should be the primary focus. Materiality can be added in addition, where the project has many high priority issues
- Extracts for the issue log will be used at all team meetings and Steering Committee meetings to either inform others or get decisions.
Conclusion. The Issue Log is one of the most important documents on any project. The control document itself should be implemented very simply, but the Issue Log should be applied rigorously.
