Issue Log
An issue log records problems that have already occurred and are affecting delivery now. Each entry carries a description, the date it was raised, an assessment of impact, a severity, a named owner, a resolution action with a target date and a status. It sits alongside a risk register, which covers events that have not yet happened.
An issue is a fact. That distinguishes it from a risk, which is a possibility, and it changes what the log is for: a risk register supports assessment and mitigation, an issue log supports resolution and escalation. Entries are expected to close, and an issue log where nothing closes is a signal in itself.
What it contains
| Field | What it records |
|---|---|
| Issue ID | Reference used in status reports and escalations |
| Description | What has happened, stated as fact rather than as a complaint |
| Date raised | When it was logged, and by whom |
| Impact | The effect on scope, cost, schedule or quality, quantified where it can be |
| Severity or priority | The organisation's scale, used to decide what gets attention first |
| Owner | The named person driving the resolution |
| Resolution action | What is being done, in a form that can be finished |
| Target resolution date | When it is expected to be closed |
| Escalation level | Whether it sits with the project, the programme or the steering committee |
| Source | Whether it arrived from a realised risk, a failed assumption, testing or operations |
| Status and date closed | Open, in progress, closed, with the date it was resolved |
Logs used during a go-live add two more: the environment or system affected, and whether the issue blocks the cutover. During hypercare the same structure is normally used for post-go-live defects, with a link to the ticket in the service desk tool.
How it is used
The log drives two conversations. In the weekly delivery meeting, open issues are worked through by owner and severity, and anything the team cannot resolve itself is flagged for escalation. In the governance meeting, only the issues above a threshold appear, each with what is being asked for — a decision, money, a resource, or a change to scope.
The escalation column is what makes the log useful outside the team. An issue that has been open for six weeks at project level, with three missed target dates and no escalation, is a reporting failure rather than a delivery one. The RAID Log & Program Governance Pack holds the issue log and the action log in the same workbook as the status report, so the escalated entries carry through automatically.
Where it goes wrong
Issues logged as blame is the first problem. An entry naming a team as the cause invites a defence rather than a resolution, and the log becomes political. Stating the effect rather than the fault keeps it workable.
Severity drift is the second. If everything is high, the log gives no ordering, and the meeting reverts to discussing whatever was raised most recently. The third is the log that duplicates the defect tracker: during testing and hypercare, defects belong in the tool the testers use, and only the ones with delivery-level consequences belong in the issue log. Keeping both in full sync is work nobody sustains.
The fourth is closure without record. An issue marked closed with no note of how it was resolved leaves nothing for the lessons learned review, and the same issue reappears on the next project.
Related terms
See also RAID log, risk register and assumption log.
Questions
What is the difference between an issue log and a defect log?
A defect log records faults found in a system during testing or support. An issue log records anything affecting delivery, including staffing, contracts, environments and decisions.
When does a risk become an issue?
When it occurs. The risk is closed as realised, an issue is opened, and the two entries reference each other so the register shows which risks materialised.
What severity levels should an issue log use?
Whatever the organisation already uses elsewhere. The value is in consistency across projects, not in the number of levels.
Should an issue log be shared with the steering committee?
Usually as an extract rather than in full — the entries above an agreed severity or escalation level, each with the decision being requested.