Issue log: the list that stops problems being rediscovered

An issue log is a single list of problems that have actually occurred on a piece of work: what happened, who owns resolving it, what has been decided so far, and whether it is still open. It is deliberately narrow. A risk is something that might happen; an issue is something that already has, and mixing the two is the fastest way to make both lists useless.

The reason to keep one is not process compliance. It is that without a list, the same problem gets raised three times by three people, each time from scratch, and the decision taken in week two is unavailable to the person who hits it again in week six.

What belongs in an issue log

• A short description of the problem, in the terms the person who hit it would use.
• When it was raised and by whom.
• The impact — what it is blocking or costing, concretely.
• An owner. Not a team, a person.
• Severity, using no more than three levels.
• Status: open, in progress, resolved, closed with the decision recorded.
• The decision and its reasoning, which is the field people skip and the one that has value six months later.
• A target date, and the date it actually closed.

The decision field is the whole point. An issue log listing thirty resolved problems with no record of why each was resolved that way is a count of past inconvenience. One that records the reasoning is a document that answers next year's question about why the system works the way it does.

Issue log, risk register, RAID log

These three overlap enough to cause confusion. A risk register holds things that might happen, with likelihood and mitigation. An issue log holds things that have happened, with an owner and a resolution. A RAID log combines four lists — risks, assumptions, issues and dependencies — into one artefact, which suits small projects where maintaining four separate documents guarantees that three are stale.

The pair worth keeping separate on any larger piece of work is risks and issues, because they are reviewed by different people at different intervals. Risks want periodic reassessment; issues want daily chasing. Merged, one of the two rhythms always wins and the other list quietly dies.

Running one that stays alive

1. Give one person responsibility for the log itself, separate from ownership of individual issues.
2. Let anyone raise an issue, with a low barrier — a sentence is enough to start.
3. Assign an owner within a day, or the log becomes a complaints box.
4. Review open issues at a fixed point in the week, oldest first rather than newest.
5. Close items explicitly with the decision written down, rather than letting them go quiet.
6. Escalate on a rule — anything open past its target date and blocking someone — not on how loudly it was raised.
7. At the end of the work, read the closed issues and ask which were symptoms of the same cause.

How issue logs die

Two ways, mostly. The first is severity inflation: everything is raised as critical because critical gets attention, until the field carries no information and the log is triaged by whoever is most persistent. Three levels, with a written definition of each, and the discipline to say that something is genuinely medium.

The second is the log becoming a place issues go instead of a place they get resolved. Once people learn that logging something means nothing will happen, they stop logging and start escalating directly, and the log turns into an incomplete record that is worse than none because it looks complete.

Keeping it in one place

This is what Ettex Records is for: one structured list where each row is an issue, with fields for owner, severity, status, decision and dates, filterable to what is open and past its date. One list everyone can see beats a spreadsheet emailed round, which is where most issue logs start and where most of them fork into three versions.

It is a record system rather than a ticketing tool. There is no automatic escalation, no notification rules, no SLA timers and no customer-facing intake. The weekly review is a meeting, not a workflow engine — for small teams that is the right trade, and for anything running a support desk it is the wrong tool and worth saying so.

Keep issues separate from risks, assign an owner within a day, cap severity at three levels, and always write down why something was closed.