Issue Log

A product launch is delayed because a supplier has not delivered test units. Several people discuss it, but nobody owns the next call, so an issue log gives the problem a named owner and a visible next step.

Atlassian's issue-log template describes recording and tracking problems through resolution, though its format is one example and a spreadsheet or project tool can serve the same purpose. Atlassian's RAID-log guidance groups risks, assumptions, issues and dependencies, which helps avoid labelling a current blocker as only a possible future risk.

Write a specific issue, since "Supplier delayed samples for launch testing" is more useful than "Supplier problem", and state what is affected and the evidence known. Assign an owner who coordinates resolution even if others perform tasks, because a group named engineering is not always enough when a deadline is near.

Set priority from impact and urgency, so that a critical safety issue gets immediate escalation while a minor formatting defect may wait, and define the scale so teams use it consistently. Record a next action and date, because an issue marked open with no plan can sit for weeks, and record the impact on cost, schedule, customer effect and compliance, updating it when new facts appear.

Capture status honestly, so that open, in progress, blocked and closed mean different things and an issue is not closed simply because someone acknowledged it. Separate issue from decision: the issue log records a problem and actions, while a decision log can record a consequential choice made to resolve it, and the two can be linked.

Avoid duplicate records by linking reports of the same outage from ten people to one master issue, keeping their distinct evidence without creating ten competing owners. Escalate when authority is missing, since a project lead may need budget approval or a supplier contract decision, and the log should show the blocker and escalation route.

Use timestamps for when an issue arose, was assigned and closed, without inventing dates retrospectively, and keep evidence such as tickets, test reports and emails linked while respecting access rights and avoiding pasting sensitive material into a widely shared table. Document closure criteria, because a supplier delay is closed when units arrive and are usable, not merely when a revised date is promised, and note workarounds separately so containment is not confused with a fix.

Review aging and patterns, since an issue open for months may need a new owner or decision, and repeated issues of the same type can reveal a process defect for which a root-cause review may be more valuable than closing each one in isolation. Discuss the log at useful intervals that follow risk and deadlines, as a weekly review may suit a slow project while an active incident needs faster updates, and keep it visible to relevant people with sensitive items restricted.

Use neutral language that describes facts and effects rather than character judgments, and archive closed issues under policy for learning and audit while keeping the active view focused on work still needing action. For owners, an issue log is a work-control tool for problems already present, and a perfect log cannot repair a broken service, so it succeeds when each important item has an owner, next step and truthful closure.