Skip to content
Product Lifecycle Templates

Issue Log

beta  ·  Family governance-docs  ·  Phase undefined  ·  Sizes lean, full  ·  ~3,150 tokens

The living, owned record of problems that have already happened on a project or program and need someone above the day-to-day work to act on them: what the problem is, who owns getting it fixed, whether it has been escalated, and when it is genuinely closed. Distinguished from a risk register by tense, something that occurred rather than something that might, and useful only once a team states its own threshold for what counts as an issue here.

Fast reference for using the issue-log bundle. For the full reasoning, history, and sources, read issue-log_companion.md.

When to use

Section titled “When to use”
  • Something has already happened on your project or program, is not resolving itself in the normal course of work, and needs a named person to own getting it fixed.
  • You need one written record of what the problem is, who owns it, whether it has gone up to someone above the day-to-day work, and when it is genuinely closed rather than just quiet.
  • More than one person needs to see the same status: a team lead, a sponsor, a steering group, or whoever picks it up next if the current owner leaves.
  • Issues are starting to resolve into other artifacts often enough that losing the trail matters: one began as a risk that materialized, one raised a change request, one needs a governance decision on record. That is the signal to move from lean to full (see Pick a variant, below).

When NOT to use

Section titled “When NOT to use”
  • The problem has not happened yet. Something that might happen belongs on the risk register, not here; an issue log tracks things that have occurred or are close enough to certain that waiting no longer makes sense. A row describing a future possibility is misfiled.
  • You also need to track assumptions and dependencies alongside issues. Use a RAID log as the one working document; the issue log is the deepened, standalone form of its Issues quadrant, worth splitting out only once that quadrant has outgrown the RAID log’s single row per item.
  • It is a software defect with no project-management dimension. Route it to the bug or ticket tracker instead. No source this bundle read compares a project issue log with a software tracker directly, so that boundary is this library’s own judgment, not a sourced rule; if your team already manages defects as issues on purpose, say so in Purpose and Threshold rather than silently mixing populations.
  • The problem resolves inside the team well under your stated threshold. Logging every small thing a team fixes in passing turns the log into noise nobody reads. The Purpose and Threshold section exists precisely so the team can say where that line sits, rather than every reader guessing at it.

Issue log, risk register, or RAID log? (the question people actually have)

Section titled “Issue log, risk register, or RAID log? (the question people actually have)”
Issue log Risk register RAID log
Tracks Problems that have already happened Risks: things that might happen Risks + Assumptions + Issues + Dependencies
Time frame Has happened, or close enough to certain Might happen Mixed
Cadence Near-daily to weekly, by severity Weekly to quarterly, by scale Weekly working document
Audience Whoever must resolve it now Owners, steering group, board The delivery team
Relationship The deepened, standalone form of RAID’s Issues quadrant The deepened, standalone form of RAID’s Risks quadrant The consolidation layer

They are a system, not a competing choice. When a risk materializes, it becomes an issue: the register entry closes as occurred rather than being deleted, and the new issue-log row links back to it. A RAID log’s Issues column is the same population an issue log holds, formalized; move to a standalone issue log once that quadrant needs its own escalation history, closure audit trail, and links to the logs it started from or fed into.

The change-control fork is worth naming on its own, because the sources genuinely split on it. One convention treats a request for change as a kind of issue: every change starts as an issue, though not every issue becomes a change, and the change stays on this log. The other convention keeps a separate change log for submitted change requests and states no rule for where the two overlap. Either is defensible; record which one your team follows in Links to Other Logs (full) so a reader does not have to guess.

Pick a variant

Section titled “Pick a variant”
  • Lean (default): Purpose and Threshold, Priority Scale, Issues, Escalation, Review and Ownership. A complete working log a team can populate and review from week one. It is enough for a project whose issues resolve inside the team, without a change-control hand-off or a lessons-learned record to keep.
  • Full: adds Closed Issues (resolution, a confirmer distinct from the fixer, closed date, lesson learned) and Links to Other Logs (origin risk, change request, decision, implementing tasks). Move to full once issues start resolving into other artifacts often enough that losing the trail matters: a materialized risk whose register entry needs to close as occurred, a request for change your convention routes through this log, or a governance board that will ask, weeks later, what was actually decided.

Grow lean into full by adding the two sections; the first five sections keep their name and order. The scaling signal is how often issues hand off to another artifact, not how large the project is.

Quality rubric (self-grade)

Section titled “Quality rubric (self-grade)”

Score each row 0, 1, or 2. Below 13 out of 18, the log will not survive its first real review: the first person who reads it closely will find a row with no owner, no threshold, or no decision behind an escalation.

# Criterion 0 1 2
1 States its own threshold No line saying what counts as an issue here A line exists, but it is too vague for two people to apply the same way A stated threshold (an event, a tolerance breach, or a condition) with a size or duration test, plus what is explicitly out and where it goes instead
2 Priority scale is anchored Bare High / Medium / Low, or a number with no meaning attached Named levels exist, but two people would still rate the same issue differently Every level is anchored to something observable for this project, and the scale states what triggers escalation
3 One named owner No owner column, or owner is a role or “the team” A person is named on some rows, a role or team on others A specific individual is named on every open row, and is the person actually accountable for resolving it
4 States cause and impact A one-word label (“Vendor”, “Export broken”) Cause or impact is present, not both A reader who was not there can tell what broke, why, and what it threatens, from the row alone
5 Rows stay current No Last updated column, or every row carries its creation date regardless of activity Some rows are current, others are stale with no way to tell which A reviewer can open the table and find no row whose real status changed more recently than its recorded update
6 Escalation has a rule No rule stated; escalations, if any, have no decision named A rule is named in general terms, but current escalations do not say what is being decided The shape (a role ladder, an aging clock, or a per-issue flag) is named, and every escalated row shows who it went to and the decision awaited
7 Review is current No cadence and no named log owner A cadence is named, but the last-reviewed date is older than the stated cadence allows Cadence, triage order, and log owner are all named, and the last-reviewed date is inside that cadence window
8 Closure is confirmed independently (full) Closed rows show a status flip with no confirmer and no date A confirmer or a date is recorded, but the confirmer is the person who did the fix Every closed row names a confirmer distinct from the fixer, a closed date, and either a lesson or a stated reason none applies
9 Links are traced (full) The section is blank or missing Links are named but lack a direction or an ID, or another log’s own detail is copied in here Every issue’s origin risk (or “None”), change request, closing decision, and implementing tasks are named by ID, and a reader can follow each one back to its own log

Rubric scope by variant

Section titled “Rubric scope by variant”
Variant Rows scored Maximum Threshold
lean 1-7 14 10
full all 9 18 13

Lean ships no Closed Issues or Links to Other Logs section, so rows 8 and 9 grade content it does not carry; score lean against rows 1 through 7 only. A lean log at 10 out of 14 clears a comparable bar to a full log at 13 out of 18.

Named anti-patterns (the usual wrecks)

Section titled “Named anti-patterns (the usual wrecks)”
  1. No owner. A row assigned to “Engineering” or “the team” is assigned to no one, and an issue with no owner is unlikely ever to get resolved. Fix: one named individual, on every row, before it goes further.
  2. Nobody reviews it. The review is the task that quietly gets skipped when the people running the project get busy, so the log keeps existing while it stops being read. Fix: a stated cadence, and a named person who runs the review and records its date.
  3. Raised late. Reluctance, or simply a lack of time, keeps an issue off the log until it is already serious. Fix: log it the moment it meets your stated threshold.
  4. Decided badly once it arrives. Getting an issue to governance is not the same as getting a good decision from it; a board can still fail to address the root cause and treat only the symptom in front of it. Fix: escalate with a proposed solution, not a bare problem, so the decision has something to act on.
  5. Aging without movement. A row nobody has touched in months is a row nobody is actually working, no matter what its status says. Fix: the Last updated column this template carries beyond some published field lists, and a review that actually looks at stale rows rather than only new ones.
  6. Escalation used to assign blame. An escalation record that names who caused a problem, instead of what decision is needed, has stopped being a request for a decision. Fix: escalate to get a decision, never to assign fault.
  7. Resolved treated as Closed. These are not the same state: Resolved means the work is done, Closed means someone other than the person who did the fix has verified it. Collapsing them into one step removes the check the second state exists for. Fix: keep the states distinct, and name who confirms closure separately from who performed it.

No paired skill (yet)

Section titled “No paired skill (yet)”

There is no deliver-issue-log or govern-issue-log skill in the product-on-purpose org today, so this bundle’s pairs_with is empty. Until one exists, this template is filled by hand.

The artifacts

Section titled “The artifacts”

issue-log_template-lean.md · ~3,150 tokens

---
title: "{{project_name}} Issue Log"
project: "{{project_name}}"
log_owner: "{{log_owner}}"
last_reviewed: "{{date}}"
review_cadence: "{{cadence}}"
status: "{{status}}"
doc_type: issue-log
size: lean
source_template: issue-log
source_template_version: 0.1.0
---


<!--
LEAN ISSUE LOG. The smallest issue log that is still a real one: a stated threshold for what counts as an
issue here, a priority scale, the issues themselves (one owned, actionable row each), the escalation rule
and record, and the cadence that keeps the log alive. Use it when one team logs and resolves its own issues
without a change-control hand-off or a lessons-learned record worth keeping. To grow it into the
governance-grade form (see issue-log_template-full.md), ADD sections; never rename or reorder the ones
below, because the full variant is a strict superset of this one.


WHAT AN ISSUE LOG IS, AND WHY THE FIRST SECTION MATTERS MOST. Published sources define "issue" four
different ways: PM2 and PRINCE2's 2009 glossary require something that has already happened; APM requires a
breach of delegated tolerance; PRINCE2 7 widens the definition to anything that could affect the project;
PMI's Lexicon requires neither an event nor a tolerance breach, only a current condition with impact. This
template does not pick a winner. It requires you to state your own threshold in the first section, because
two people keeping the same log will disagree about what belongs in it unless the team writes the line down.
See issue-log_companion.md section 6.


IT IS NOT A RISK REGISTER. A risk might happen; an issue already has, or is judged close enough to certain
to require action now. When a risk materializes, it becomes an issue, and the risk register entry closes as
occurred, linked back to this log, never deleted. See issue-log_companion.md section 8.


HOW TO FILL THIS IN
1. Read the comment under each heading: WHAT, WHY (with a companion pointer), ASK, GOOD, WEAK, TRAP; a
   scale or a record section adds PRIORITY and ROW HINT.
2. Replace each {{placeholder}}. The Issues table is the heart; give every row one named owner, never a
   role and never "the team".
3. If a section does not apply, write "N/A" and one line of why, rather than deleting it.
4. This document is never finished, but before you share it: self-grade against issue-log_guide.md, then
   DELETE every HTML comment. They are guidance, not content.
-->


# {{project_name}} Issue Log


## Purpose and Threshold


<!-- WHAT  A short statement of what counts as an issue on this project, the threshold that separates a
           logged issue from something the team just fixes in passing, and what is explicitly out of
           scope: risks (the risk register), software defects (the bug tracker, a boundary this library
           draws itself, since no source read compares the two), and approved changes (change control).
     WHY   The sources genuinely disagree about what an issue even is, and none of the four positions is
           wrong: an event that has already happened, a tolerance breach, anything that could affect the
           project, or a current condition with impact. The single most useful sentence in an issue log is
           the one that says what its rows mean here. Deep dive: issue-log_companion.md section 3 (Purpose
           and Threshold) and section 6 (what an issue even is, stated four ways).
     ASK   Which threshold does this team use: already happened, a tolerance breach, or something else
           stated plainly? What size or duration moves a problem from "just fix it" to a logged issue?
           What is explicitly out (risks, defects, approved changes), and where does each of those live
           instead? Who owns the log itself?
     GOOD  "An issue is any unplanned event that has already happened and cannot be resolved at the team
           level within three days. Something that might happen goes on the risk register; a software
           defect goes to the bug tracker; an approved change goes to change control. Owned by the program
           manager."
     WEAK  "Problems and blockers." (no threshold, no owner, no boundary against the other logs, so every
           row is a judgment call)
     TRAP  Borrowing PRINCE2 7's forward-looking definition, anything that could affect the project,
           without saying so. It pulls the concept toward the risk register's territory, and a reader
           comparing the two logs cannot tell which convention you used unless you state it. -->


{{purpose_and_threshold}}


## Priority Scale


<!-- WHAT  However this project ranks issues for attention, stated in words a second person would apply
           the same way to the same issue.
     WHY   The published sources split the scale three different ways: one methodology guide scores
           urgency and impact separately on parallel one-to-five scales; a government template instead
           names five impact levels outright plus a separate Material or Non-Material split; a third
           published log assesses impact against named cost, schedule, and quality dimensions directly.
           Deep dive: issue-log_companion.md section 3 (Priority Scale).
     ASK   Do you score urgency and impact separately, use named impact levels, or assess against named
           dimensions (cost, schedule, quality)? What does each level mean, concretely enough that two
           people would apply it the same way? Where do you draw the line for "escalate now"?
     PRIORITY  This is this template's own field, not a literal field name every source carries. One
           methodology guide's own plan text refers to a "priority" scale, but its log fields carry no
           field literally named priority, only urgency, impact, and size; do not claim a source names a
           field this template does not find in it.
     ROW HINT  A good scale level is anchored to something observable, for example "5 = Very high" paired
           with what that means for this project, or "5 = Catastrophic, affects cost, schedule, or scope
           enough to threaten the project." A weak scale level is a bare number with no anchor.
     GOOD  "Urgency 1 to 5 and Impact 1 to 5 (5=Very high, 4=High, 3=Medium, 2=Low, 1=Very low), scored
           separately; either scoring 4 or 5 triggers the escalation rule below."
     WEAK  "High / Medium / Low." (no anchors; two people will rate the same issue differently)
     TRAP  Naming a column "Priority" and citing a methodology guide for it, when that guide's own field
           list carries no field by that name. State your scale as your own choice. -->


{{priority_scale}}


## Issues


<!-- WHAT  The load-bearing table, one row per issue: an ID, an optional category, the issue itself
           (cause and impact, not a theme label), when and by whom it was raised, its priority, one named
           owner, the next action and its target date, its status, and when the row was last touched.
     WHY   Every published field list agrees on a small spine, ID, description, owner, and status, and
           diverges on everything else. This template gains a Last updated column beyond the fullest
           published field list, a field three independently published sources carry that it does not.
           Deep dive: issue-log_companion.md section 3 (Issues).
     ASK   For each issue: what happened, its cause, and its impact? Who raised it and when? What is its
           priority on the scale above? Who is the one named owner? What is the next action and its target
           date? What is its status (Open, Postponed, Resolved, Closed)? When was the row last updated?
     PRIORITY  Order by priority, highest first, then by age within a priority. Owner is one named person,
           never a role and never "the team". Status is a small, stated set; keep it the same set you use
           in Escalation below.
     ROW HINT  A good row states cause and impact, not a theme; carries a named owner and a next action
           with a date; and its Last updated column moves every time someone touches it. A weak row is a
           one-word label with no owner, no action, and a Last updated column nobody has touched in months.
     GOOD  | ISS-07 | Supplier | Because the payroll vendor withdrew support for the file format our
           interface sends, February's payroll run needed a manual workaround and March's will fail without
           one | Priya Shah, 2026-02-17 | High | Tom Reid | Agree a format change or a support extension with
           the vendor; target 2026-03-06 | Open | 2026-02-24 |
     WEAK  | ISS-07 | Supplier | Payroll file broken | | High | IT | fixing it | Open | |
     TRAP  Logging a theme instead of a cause-and-impact statement, or leaving the owner as a team. An
           issue owned by "Engineering" is owned by no one. -->


| ID | Category | Issue (cause and impact) | Raised (by, date) | Priority | Owner | Next action (target date) | Status | Last updated |
|---|---|---|---|---|---|---|---|---|
| {{issue_id}} | {{category}} | {{issue}} | {{raised_by_date}} | {{priority}} | {{owner}} | {{next_action_target}} | {{status}} | {{last_updated}} |


## Escalation


<!-- WHAT  The rule that decides when an issue goes up, decided before it is needed, and the record of
           what has actually been escalated: to whom, when, and what decision is awaited.
     WHY   Every source that discusses escalation agrees it should happen and disagrees completely about
           the trigger: a role ladder with no timer, an aging clock that starts the day the issue is first
           logged, or a per-issue Yes/No flag against thresholds fixed in advance. No source reconciles
           these three shapes, so this template asks you to name the one you use rather than picking for
           you. Deep dive: issue-log_companion.md section 3 (Escalation) and section 6 (the escalation
           trigger debate).
     ASK   Which shape governs here: a role ladder, an aging clock, or a per-issue flag against a stated
           threshold? Who does an escalated issue go to next? What has actually been escalated, on what
           date, and what decision is the team waiting on?
     PRIORITY  State the rule once, in prose, before listing current escalations. Every escalated item
           needs a decision awaited, not just a status of "escalated"; escalate to get a decision, never to
           assign fault.
     ROW HINT  A good entry names the issue, who it went to, the date, and the decision awaited. A weak
           entry says "escalated" with nothing else.
     GOOD  "An issue goes to the program board when its resolution needs a decision above the project
           manager's authority. Currently escalated: ISS-07, to the program board on 2026-03-02, awaiting a
           decision to extend the vendor's support contract by one quarter."
     WEAK  "Escalated when needed." (no rule, no record, no decision named)
     TRAP  Using the escalation record to name who caused the issue rather than what decision is needed.
           That turns a request for a decision into an accusation, and the decision is what the board can
           give. -->


{{escalation}}


## Review and Ownership


<!-- WHAT  The stated review cadence, who owns the log itself, and which issues get looked at first.
     WHY   Practitioners genuinely disagree on cadence: two authors of the same article disagree with each
           other, one reviewing weekly and the other saying issues should be discussed almost every day. A
           government issue-management plan instead settles on weekly with severity-first triage. This
           template reports the disagreement rather than resolving it; state your own cadence instead of
           assuming one. Deep dive: issue-log_companion.md section 3 (Review and Ownership) and section 6
           (review cadence).
     ASK   How often is the log reviewed, and by whom? Which issues get looked at first (severity,
           escalated status, age)? Who owns the log day to day, separate from who owns any one issue?
     GOOD  "Reviewed weekly by the PMO; review priority goes to high-severity and escalated issues first.
           Log owned by the program manager. Last reviewed 2026-07-20."
     WEAK  "Reviewed regularly." (no cadence, no owner, no triage order; this is how a log quietly stops
           being read)
     TRAP  Treating the review as a calendar formality nobody actually does. One source names exactly this
           failure: the review "gets neglected when project managers get busy." -->


{{review_and_ownership}}

Provenance

Section titled “Provenance”

The reasoning, the history and every source, in the repository:

  • Companion - the long-form argument: why these sections, where the sources disagree, and what the bundle refuses to claim
  • History - what changed in this bundle, and when
  • Research log - every source consulted, with what each one actually supports
  • Catalog metadata - the machine-readable record this page is generated from

Catalog record: 7 sections across 1 format(s), methodology PMBOK, typically owned by PM.