Skip to content

Issue Log

At a glance

  • Purpose: Track problems that have already happened — as distinct from risks, which have not — with an owner and a date, so nothing is forgotten between meetings.
  • Use it when: Continuously, from the first problem that affects delivery. It is often the most-used document on a project and the most neglected in reporting.
  • Owner: The project manager or a named coordinator; each issue has its own owner.
  • Related: Module 08 · Module 11 · Lab 22
  • Spreadsheet version: csv/issue-log.csv

How to use this template

  1. Keep the boundary sharp: a risk that has occurred becomes an issue, and it should appear here as well as being closed in the risk register. This link is what makes the two documents useful together.
  2. Record the effect, not just the description. "Test environment unavailable" is a description; "testing is blocked, so verification slips by four days" is what makes it prioritised.
  3. Give every issue an owner and a target date, and review the list at a fixed cadence. Issues without owners are notes.
  4. Note what it blocks. An issue blocking three people is a different priority from one blocking nobody.
  5. Close issues with a resolution statement, not a status change. "Resolved — the environment was provisioned; no further impact expected" is a closure.

Field descriptions

Column What goes in it Watch out for
ID Stable reference (I-001) Reusing IDs across logs
Raised by and date Who found it, and when Issues with no origin
Issue The problem, stated as an effect Descriptions with no consequence
Effect What it stops or slows, and for whom Effect left to the reader
Related risk The register row it came from, if any Occurred risks never linked
Severity Impact on delivery if unresolved Everything high
Owner The person who will resolve it Owners assigned to people who cannot act
Target date When resolution is expected Dates that pass without review
Resolution What was actually done "Sorted out"
Status Open / in progress / blocked / resolved / closed Issues open for the whole project

Blank template

# Issue Log — [Project name]

| | |
| --- | --- |
| **Log owner** | [Who maintains this] |
| **Reviewed at** | [The meeting where the log is walked] |
| **Last updated** | [YYYY-MM-DD] |

| ID | Raised by | Date | Issue | Effect | Related risk | Severity | Owner | Target date | Status | Resolution |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| I-001 | [Who] | [Date] | [Problem as an effect] | [What it blocks] | [R-nn] | High | [Who] | [Date] | Open | — |

## Blocked conflicts

| Issue | What must happen first | Who can unblock it | Escalated to | On what date |
| --- | --- | --- | --- | --- |

## Closed this period

| ID | Issue | Resolution | Closed | Recurrence? |
| --- | --- | --- | --- | --- |

Worked example

From Lab 22, invented for teaching. Three issues from one reporting period:

ID Issue Effect Related risk Severity Owner Target Status
I-004 The test environment has no copy of realistic record volumes Performance testing cannot start; the list-screen timeout at 1,200 records is undiscovered R-07 (occurred) High IT operations 5 days Resolved — 1,200 seeded records available
I-005 The records office has not confirmed the retention period Retention is configured from an assumption; a wrong value is a compliance exposure R-03 High Business owner 10 days In progress
I-006 Two developers are both editing the same integration module Rework risk; last week's merge overwrote a fix — Medium Technical lead 2 days Resolved — module ownership agreed

Two things this log makes visible that a status report would not. I-004 and I-005 are risks that occurred, so the risk register must be updated to close them and the issue log carries the consequence — linking the two documents is what stops the same problem being described twice with no action. And I-006 has no related risk, which is a finding in itself: the project had no risk registered for concurrent editing, and the same pattern will recur. A useful response is to add that risk rather than only close the issue.

Common mistakes

  • Confusing issues with risks. Issues have happened; risks have not. Mixing them into one list means either the risk register loses its forward view or the issue log becomes historical.
  • A description with no stated effect. Without a consequence, nobody can prioritise it.
  • Ownership assigned to the requester. The owner must be able to act.
  • Target dates that pass silently. A log reviewed but not acted on trains people to ignore it.
  • Issues left open indefinitely. Either resolve, formally accept, or convert to a risk or change request — but stop leaving it "in progress" for months.
  • No recurrence check. Repeated issues point to a systemic cause, which is worth fixing rather than logging again.
  • Only negative items. Blockers cleared, and problems avoided, are worth recording too — otherwise the log tells a story more pessimistic than the project deserves.