Issue Log

What this tool does

CM8-237 is a working issue log for a project or a running operation. You record each issue as it surfaces — what is happening, what it is blocking, who owns it and when it will be fixed — and the tool tracks age, flags anything past its target date, shows where issues are piling up, measures how long resolution actually takes, and prints a report for the weekly meeting or the steering group.

It covers the whole life of an issue: raised, worked, escalated when it stalls, resolved when the fix is applied, and closed only when whoever raised it agrees it is fixed. Everything runs inside this single file. There is no account, no upload and no network request of any kind, so what is going wrong on your project never leaves the computer you are using.

An issue is not a risk

A risk might happen; an issue is happening. "The supplier could go under" is a risk — you score its likelihood and decide what to do in advance. "The supplier has stopped answering the phone and the delivery is a week late" is an issue — likelihood is no longer a question, and the only decisions left are who fixes it, how fast, and at what cost. Keeping the two in one list muddles both: risks get worked as if they were urgent, and issues get scored as if they were hypothetical. When a risk on your register is realised, close it there and open it here. If you want risks, assumptions, issues and dependencies together in one register for programme governance, that is the separate RAID log tool — this one is the dedicated operational issue log, built for escalation, aging and resolution discipline.

Severity and priority are different questions

Severity is how bad the impact is. Priority is how urgently you are working it. They usually correlate, and they are not the same thing:

• Low — inconvenient, and a workaround exists.
• Medium — degrades progress or quality; work continues but worse or slower.
• High — blocks a workstream; a team is stopped or working around at real cost.
• Critical — blocks the project or affects customers.

Priority is the queue: P1 now, P2 this week, P3 in the normal course. A high-severity issue can honestly sit at P2 for a day or two while a P1 is cleared. What cannot happen is a critical issue at P3: if it truly blocks the project, it cannot also be something you will get to eventually. The tool refuses that combination — one of the two ratings is wrong, and it is worth ten seconds to decide which. The opposite pattern is also worth watching: everything marked critical means severity has stopped carrying information, and the one issue that really is critical gets the same attention as the rest.

The ownership rule

Every issue has exactly one owner, and the owner is a person, not a team. "IT" cannot be asked on Friday what changed since Monday; a named person can. The owner is not necessarily the one doing the work — they are the one accountable for the issue moving, the one the review turns to, and the one who decides to escalate when it stops moving. An issue whose owner cannot say what happens next has already stalled; the log just has not noticed yet.

Escalation discipline

Escalate when the issue cannot be resolved with your own authority — the fix needs money you cannot spend, a decision you cannot make, or pressure on someone who does not answer to you. Three rules keep it honest:

• Name a person. "Escalated to management" is not an escalation; it is a shrug in a tie. The tool will not save an escalated issue without a name in the "escalated to" field.
• Date it. The escalation date starts a new clock — how long the decision itself has been waiting, which is a different and often more embarrassing number than the issue's age.
• Ask for a decision, not sympathy. An escalation is a request: "we need X by Y or Z happens." It is not blame, and it is not failure — escalating on time is what the sponsor is for, and an issue quietly held at the wrong level for three weeks does far more damage than one escalated on day two.

Targets and the overdue flag

Give every open issue a target resolution date — the date by which it will be fixed, not the date by which someone will look at it. Once the target passes and the issue is neither resolved nor closed, the register marks it Overdue in red and the tiles count it. An overdue issue is not necessarily mismanaged, but it always deserves a sentence at the review: new target and why, or escalate. Moving a target silently is how a two-day issue becomes a two-month one without anyone ever deciding that was acceptable.

Open issues at high or critical severity older than the threshold in the settings (14 days by default) are flagged in red in the register — two weeks is a long time for something that blocks a workstream.

Resolution and closure are two different events

Resolved means the fix has been applied. Closed means whoever raised the issue has confirmed it is actually fixed. The gap matters: a good fraction of "fixed" issues come back, usually because the fix addressed the symptom the fixer saw rather than the problem the raiser had. Closing with the raiser costs one conversation and catches those before they resurface as new issues with new numbers.

The tool insists on two things before an issue can be marked resolved or closed: the actual resolution date, and a sentence saying what was done. "Fixed" helps nobody in three months, when the same symptom reappears and the only record of last time is a closed row with an empty resolution field. Write what was done and, where you know it, why it happened — the resolution field of a well-kept log is a searchable history of how this organisation's problems actually get solved.

Reading the burn-down

The monthly chart shows the issues raised in each month, split into those since resolved and those still open. Read it two ways. First, the trend in bar height: a rising count of raised issues is not automatically bad — early in a project it usually means people have started reporting honestly. Second, and more telling, the dark "still open" portion of the older bars: last month's bar being half-open is normal; a bar from four months ago still showing open issues means things are being raised and then abandoned. The "this month" tile gives the same signal as a single figure — closed versus raised — and says plainly whether you are draining the pool or filling it.

The weekly review

An issue log earns its keep in a short recurring review — weekly on most projects, daily in a crunch. The Needs attention now table is the agenda, pre-sorted: worst severity first, oldest first within it.

1. Start at the top. For each open issue: what changed since last week, and what happens next? An owner who answers "nothing, and I don't know" has an issue to escalate, today, with a name on it.
2. Deal with everything marked Overdue: new target with a reason, or escalation. Never silence.
3. Check the escalated issues: has the person they were escalated to actually decided? The escalation date tells you how long the decision has been sitting.
4. Skim the Recently resolved table: anything "resolved — not yet verified" for more than a week needs the closing conversation with its raiser, or it will be back.

Fifteen minutes, every week, same order. The projects that do this rarely have dramatic issue meetings, because nothing gets old enough to become dramatic.

FAQ

How is this different from the RAID log? The RAID log is one combined register for risks, assumptions, issues and dependencies — the governance view for a programme board. This tool does one of those four letters properly: operational issue management, with escalation to a named person, aging flags, target dates and resolution-time measurement. Many teams run both — RAID for the board pack, this log for the weekly working meeting.

Should small issues go in at all? If they need someone other than the person who found them to act, yes. If the finder can fix it in less time than logging it would take, fix it. The log is for issues that need tracking, not a diary of everything that went slightly wrong.

Who sets the severity — the raiser or the owner? The raiser proposes, the owner confirms at triage. The raiser knows the impact on them; the owner can see the impact on everything else. Disagreements are worth thirty seconds, because severity drives the order of the attention table.

Can an issue be reopened? Set it back to open and note in the description why it came back — a resurrected issue is evidence that the previous resolution treated a symptom, which is exactly the kind of thing the log exists to remember.

What is a good average resolution time? There is no universal number — a software defect and a late steel delivery live on different clocks. Watch your own trend, and watch the 15+ days bucket in the distribution chart: issues that old usually stalled waiting for a decision, which means they should have been escalated in week one.

Saving your work

Issues, settings and the report header are written to this browser's local storage as you type, and the toolbar shows the time of the last save. That storage belongs to one browser on one computer: another browser, a private window, a second machine or a clean-up tool that clears site data will not have it.

Treat Export .json as the real save — one file containing everything, which Import .json restores anywhere. Export CSV gives you the register for spreadsheet work and includes every filtered record, not only those drawn on screen. Reset asks twice, then erases everything this tool has stored. There is no undo.

Accuracy & disclaimer

The arithmetic here is dates and counts, and the tool does it faithfully. Everything that matters sits underneath it: whether issues are logged at all, whether severities are honest, whether "closed" really was verified with the raiser. An issue nobody logs is still an issue — a clean register is evidence of a calm project only if people trust it enough to write the bad news down.

This is a record-keeping and prioritisation aid, not project-management advice. Where an issue touches a legal, safety or contractual obligation, the obligation is met by the thing itself being handled properly — not by its row in this log.