Skip to content
Product Lifecycle Templates

Change Log

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

The standing register of every change requested against an agreed baseline and what was decided about each one: one row per request, never deleted, with status kept apart from decision. Distinct from the change request it tracks (one document per occasion) and from a software changelog (a release-notes artifact with no requester, decider, or decision field at all).

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

When to use

Section titled “When to use”
  • A baseline already exists, or is about to be agreed, that someone outside the immediate team will hold you to: a spec, a PRD, a scope and a budget a sponsor signed off on. Something is being proposed against it.
  • More than one person needs a standing, shared answer to “what changed here, and who agreed to it,” not just an explanation of the one change under discussion right now.
  • Requests get decided in ways that are not automatically remembered: in a meeting, in a chat thread, in someone’s head. This log is the place a decision becomes durable enough to survive the person who made it moving on.
  • A sponsor or governance body will eventually ask how far the baseline has actually moved in total, not just what the most recent change was. That question is answered by summing rows, never by reading one (see Pick a variant, below, and Cumulative Effect in the full variant).

When NOT to use

Section titled “When NOT to use”
  • Nothing has been baselined yet. This log tracks change against something that already exists and has been agreed; a document still being drafted or negotiated has no baseline yet for a change to be measured against. Route that activity through whatever process produces the first agreed version.
  • It is a software release. A software changelog is a different, adjacent artifact under the same word: it is written for users and contributors, and it carries no requester, decider, or decision field at all. Route release notes there, not here.
  • The team already runs PRINCE2 and keeps requests for change inside its issue register. That is a named, defensible methodology choice, not a gap this log exists to close. Decide explicitly which artifact holds the function; do not run both without saying so.
  • Change routes through one person’s ongoing judgment against an emergent backlog, with no baseline that carries weight outside the team. A standing change log adds process a team like this does not need. Adopt one once a baseline exists that someone outside the team can hold the project to: a contract, a regulator, or a sponsor-signed scope and budget.

Change log, or change request?

Section titled “Change log, or change request?”

The two are easy to conflate because one feeds the other. They are not interchangeable.

Change log Change request
What it is The standing register: one row per request One document, filed to describe and justify a single change
Lifecycle Never finished; every disposition stays on it Filed once, decided, then archived
Deletion No row is ever removed, whatever was decided N/A, it is a single document
Audience Whoever needs the cumulative, governing picture Whoever must decide this one request

The request feeds a row into the log; the log is not a second copy of the request, and the request is not a substitute for the log. If your team runs PRINCE2, the same relationship holds inside the issue register instead, by that methodology’s own design (see When NOT to use, above).

Pick a variant

Section titled “Pick a variant”
  • Lean (default): Purpose and Boundary, Status Vocabulary, Change Log, Authority and Escalation. A complete working register a team can populate and govern from the first submitted request, without a formal delivery hand-off, a standing cumulative figure anyone asks for, or a question about who keeps the log.
  • Full: adds Implementation and Traceability (the target and actual delivery dates, kept apart from the decision date, plus links back to the request document and to related logs), Cumulative Effect (the running total of approved change against the baseline as first agreed), and Review and Ownership (a named keeper and a stated cadence). Move to full once a sponsor or governance body will ask, weeks later, how far the baseline has moved in total; once the decision date and the delivery date genuinely diverge often enough that conflating them would mislead a reader; or once the log needs a named owner because more than one person could plausibly be asked to keep it.

Grow lean into full by adding the three sections; the first four keep their name, order, and table. The scaling signal is whether anyone outside the team will ask about the baseline’s total movement or the gap between deciding and delivering, not how large the project is.

Quality rubric (self-grade)

Section titled “Quality rubric (self-grade)”

Score each row 0, 1, or 2. Below 11 out of 16, the first reader who actually tries to trace one change through this log, from request to decision to delivery, will hit a row they cannot follow: a status standing in for a decision, a baseline named only as “the project,” or an escalation nobody can confirm was ever resolved. A lean log carries no delivery, cumulative, or ownership section to trace, so it is scored, and cleared, against a smaller table; see the scope table below.

# Criterion 0 1 2
1 Boundary is drawn No line says which baseline, by artifact and version, this log tracks A baseline is named, but nothing says what is deliberately left out You can point at the sentence naming the exact baseline artifact and version, and at the sentence ruling out at least one named neighbor (the request document, a software changelog, an issue register)
2 Decision kept separate Only a status list appears; no separate decision value is defined anywhere A decision value exists, but a closed or denied row does not show which one it received You can point at any closed row and name both its status and its decision, because the two are recorded as separate fields, never folded into one word
3 Rows never deleted A rejected, withdrawn, or postponed request cannot be found on the table, and nothing states closed rows stay A closed row exists, but nothing about it or the log’s own framing rules out that it could be quietly removed later You can point at a row with a non-approved outcome, still on the table, carrying its reason, and the log states plainly that no row is ever removed once decided
4 Baseline named per row A row names no baseline artifact, or names only “the project” or “the plan” A baseline artifact is named on most rows, but its version is missing, blank, or inconsistent row to row Every row names the exact artifact and version it would change, and a reader could go find that version without asking the keeper what it meant
5 Authority threshold stated No decider is named, or the only statement is that “the team decides” A decider is named, but nothing states the point at which a change must go above them You can point at a stated threshold, in figures or scope terms, and at any row marked escalated, name who it went to and what decision is being waited on
6 Delivery dated separately (full) One date field stands for both when a change was decided and when it shipped Two date fields exist, but at least one implemented row leaves the actual date blank or repeats the decision date Every implemented row carries a decision date and a separate actual date, and where they diverge, that gap is visible rather than absorbed into a single stamp
7 Cumulative effect computed (full) No running total appears, or one appears without saying which rows produced it A total is stated, but a reader cannot trace it back to specific rows above it The section names the specific approved rows the total was computed from, and does not present an illustrative figure from elsewhere as though it were this log’s own measured number
8 Named keeper, current review (full) No individual is named as keeper, or no cadence is stated A keeper and a cadence are both named, but the log’s last-reviewed date is older than that cadence allows A specific person is named as keeper; the cadence is stated as this team’s own choice; and the last-reviewed date falls inside it

Rubric scope by variant

Section titled “Rubric scope by variant”
Variant Rows scored Maximum Threshold
lean 1-5 10 7
full 1-8 16 11

Lean ships no Implementation and Traceability, Cumulative Effect, or Review and Ownership section, so rows 6 through 8 grade content it does not carry; score a lean log against rows 1 through 5 only. A lean log at 7 out of 10 clears a comparable bar to a full log at 11 out of 16.

Named anti-patterns (the usual wrecks)

Section titled “Named anti-patterns (the usual wrecks)”
  1. A status standing in for a decision. “Closed” tells a reader the row stopped moving, not which way it went; a change can be closed because it was approved, or closed because it was rejected, and the word alone cannot say which. Fix: a decision field, kept apart from status, on every row that is no longer open.
  2. A rejected or withdrawn row quietly removed. Deleting a row that went the wrong way erases the record that the request was ever considered, and invites the same request to come back with nobody able to say it was already declined and why. Fix: every disposition stays on the table, with its reason, for as long as the log exists.
  3. The baseline left unnamed. “Tracks changes to the project” tells a reader nothing they could check. Without an artifact and a version, two readers can disagree about which document a row is even changing. Fix: name the baseline, by artifact and version, in the Purpose and Boundary section and again on every row.
  4. Authority named without a threshold. “The board approves changes” says who decides, not when a change is small enough to skip them. Without a stated threshold, every request becomes its own argument about whether to ask. Fix: state the threshold before it is tested, not the first time a change reaches it.
  5. One date doing the work of two (full). Recording only an “approval date” and letting it stand for both the decision and the delivery hides exactly the gap a later reader, or an auditor, most needs to see. Fix: a decision date and a separate actual date, on every implemented row.
  6. A cumulative figure asserted instead of computed (full). A running total that does not trace back to the specific rows behind it is a guess wearing the shape of a measurement. Fix: name the rows the total was built from, every time it is stated.
  7. A log with no named keeper, or a review date nobody kept current (full). A register nobody owns and nobody actually reopens is a file, not an instrument, however complete its rows look on the day it was written. Fix: one named person as keeper, and a last-reviewed date that stays inside its own stated cadence.
  8. Collapsing this log into the request it tracks, or into a software changelog. The request is one document about one change; this log is the standing register that outlives any single request. A software changelog serves users and contributors and carries no requester, decider, or decision field at all. A log that has quietly become either has stopped doing this artifact’s job. Fix: keep the two documents apart, and route release notes to the artifact built for them.

No paired skill (yet)

Section titled “No paired skill (yet)”

There is no governance skill in the product-on-purpose org today that this bundle’s pairs_with could point to, so it adopts [] until one exists. The one pm-skills name that looks like a match, utility-pm-changelog-curator, drafts software changelog entries from git history: a different artifact under the same word, not this one (see When NOT to use, above). Until a governance-side skill exists, this template is filled by hand.

The artifacts

Section titled “The artifacts”

change-log_template-lean.md · ~3,800 tokens

---
title: "{{project_name}} Change Log"
project: "{{project_name}}"
status: "{{status}}"
doc_type: change-log
size: lean
source_template: change-log
source_template_version: 0.1.0
---


<!--
LEAN CHANGE LOG. The smallest change log that is still a real one: the baseline (or baselines) it tracks
and what does not belong in it, the status and decision vocabulary stated once, the load-bearing table
itself (one row per change request, and no row is ever deleted), and the authority that decides plus the
point at which a change goes above it. Use it when the team decides and closes its own changes without a
formal delivery hand-off, a standing cumulative figure anyone asks for, or more than one person who could
plausibly be asked to keep the log. To grow it into the governance-grade form (see
change-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 A CHANGE LOG IS. Three named bodies describe the same job in close to the same words. PMI's own
errata to the PMBOK Guide states it plainly: "The change log is used to record all submitted change
requests." The European Commission's PM² guide adds the verb the log actually serves: "A Change Log is
used to document, monitor and control all project changes (see Appendix B)." The Association for Project
Management's glossary states the outcome named: "A record of all project changes: proposed, authorised,
rejected or deferred." It is a standing, cumulative register, kept apart from the request document itself
and from the decision recorded about each row. See change-log_companion.md section 1.


IT IS NOT THE CHANGE REQUEST, AND IT IS NOT A SOFTWARE CHANGELOG. A change request is one document, filed
to describe and justify a single proposed change; this log is the standing register that gets one row per
request, whatever its eventual disposition. A software changelog is a different artifact under the
identical word: "A changelog is a file which contains a curated, chronologically ordered list of notable
changes for each version of a project." It is written for users and contributors, with no requester,
decider, decision, or status field at all. See change-log_companion.md section 1 and section 8.


PRINCE2 KEEPS THIS INSIDE ITS ISSUE REGISTER, BY DESIGN. A team already running PRINCE2 records a request
for change as one of its issue types ("Issues must be recorded in the issue register") and names a change
log only as an alternative place to write the eventual decision. This is a named methodology choice, not a
gap this template is filling. See change-log_companion.md section 1 and section 5.


HOW TO FILL THIS IN
1. Read the comment under each heading: WHAT, WHY (with a companion pointer), ASK, GOOD, WEAK, TRAP; the
   status list and the table also carry PRIORITY and ROW HINT.
2. Replace each {{placeholder}}. The Change Log table is the heart; no row is ever deleted, including a
   rejected, withdrawn, or postponed one, and each row names the baseline it would change, by artifact and
   version.
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 change-log_guide.md, then
   DELETE every HTML comment. They are guidance, not content.
-->


# {{project_name}} Change Log


## Purpose and Boundary


<!-- WHAT  A short statement of which baseline, or baselines, this log tracks, by artifact and version,
           and what does not belong in it.
     WHY   The name collides with two other documents a reader will meet under similar words, and the
           first job of this section is to rule them out before the table starts. A software changelog
           exists for a different purpose, stated in its own governing convention: "To make it easier for
           users and contributors to see precisely what notable changes have been made between each
           release (or version) of the project." It carries no requester, decider, or decision field at
           all. PRINCE2 is the named exception on the methodology side: it keeps a request for change
           inside its issue register and names a change log only as an alternative place the decision
           "should be documented in the issue register or change log." Deep dive:
           change-log_companion.md section 3 (Purpose and Boundary).
     ASK   Which baseline, or baselines, does this log track, by artifact and version? What does not
           belong here: the change request document itself (a separate document that feeds one row into
           this log), a software changelog, or, if this team runs PRINCE2, its issue register? Who is
           expected to read this log?
     GOOD  "This log tracks change requests against the Business License Renewal Requirements
           specification, currently version 2.0. It is not the change request form itself (each request
           is filed as its own document; this log gets one row per request) and not a software changelog
           (no code releases are tracked here)."
     WEAK  "Tracks changes to the project." (no baseline named by artifact or version, and does not say
           what is deliberately left out)
     TRAP  Treating a single request document as though it were this log, or letting this log absorb a
           software release's changelog. Name the baseline and rule the neighbors out before the table
           starts. -->


{{purpose_and_boundary}}


## Status Vocabulary


<!-- WHAT  The status values a change request can hold on this log, and, kept apart from status, the
           decision values that record what was actually decided.
     WHY   No two published sources use the same status list, and naming both up front is what keeps the
           table itself short. PM²'s guide offers "Submitted, Investigating, Waiting for approval,
           Approved, Rejected, Postponed, Merged or Implemented" as one sourced default (its own appendix
           names the second value "Assessing: Use this status to initiate an assessment" instead, an
           inconsistency in the source itself, not a choice this template is making for you); Connecticut
           DSS offers "Submitted, In Review, Approved, Denied, Deferred, Withdrawn, or Closed" as an
           alternative. Decision is kept distinct from status, following PM²'s own field: "There are four
           possible decisions: approve, reject, postpone or merge the change request." HHS's own "Closed"
           value shows why the split matters: "The change request is no longer considered an active
           project threat and can be closed with or without resolution." That sentence never says which
           way it went. Deep dive: change-log_companion.md section 3 (Status Vocabulary) and section 6 (which
           statuses, and is the decision a status).
     ASK   What status values does this log use, stated once so every row is comparable? What decision
           values are possible, kept apart from status? What priority scale does the Change Log table
           below assume?
     PRIORITY  State the list here, once, rather than letting each row invent its own values. If a
           published source you are borrowing from is internally inconsistent about a value's name (as
           PM²'s own guide is), say so rather than silently picking one and hiding the source's own
           disagreement.
     ROW HINT  A good status value says what triggers moving into it. A weak one is a bare word with
           nothing to distinguish it from its neighbors, or a status like "Closed" that never says which
           way the decision went.
     GOOD  "Status: Submitted, Investigating, Waiting for approval, Approved, Rejected, Postponed,
           Merged, Implemented. Decision, kept apart from status: Approve, Reject, Postpone, or Merge.
           Priority: Critical, High, Medium, Low."
     WEAK  "Open or Closed." (two values, no decision field, and Closed hides whether the request was
           approved or rejected)
     TRAP  Treating "Closed" as though it says what was decided. A closed row still needs its own Decision
           field stated, or a reader cannot tell an approved change from a rejected one. -->


**Status values:** {{status_values}}


**Decision values (kept apart from status):** {{decision_values}}


**Priority scale:** {{priority_scale}}


## Change Log


<!-- WHAT  The load-bearing table, one row per change request: an identifier, its category, a one-line
           description of the change, the baseline it would change (by artifact and version), who
           requested it and when, its priority, its status, the decision made and the reason for it, and
           who decided it and when.
     WHY   HHS states the rule the whole table exists to keep: "Each change request should be recorded as
           a single line item. Do not combine multiple requests under one change request ID." No row is
           ever deleted for having gone the wrong way: APM's own definition already names rejected and
           deferred outcomes as part of what the log records, not exceptions to it ("proposed, authorised,
           rejected or deferred"), and Connecticut carries "Withdrawn" and "Deferred" as ordinary statuses,
           not removals. Keeping a rejected row on record "prevents the same request from being
           resubmitted without understanding why it was declined." Three or more of the published field
           lists checked for this bundle share an identifier, a description, the date raised, and a status;
           most also carry a requester and a priority. This template adds two fields beyond that shared spine: the
           baseline each request would change, following HHS's own shared data element: "The product
           version that the suggested change is for." The second is the decision with its reason, kept
           beside the row (HHS's own spreadsheet carries this as a field named "Final Resolution &
           Rationale", and Connecticut's own log carries a Resolution/Comments column). Who decided a
           change and when belong here, in lean; the full variant adds the surrounding delivery detail
           without adding a new field's worth of judgment to this table. Deep dive:
           change-log_companion.md section 3 (Change Log).
     ASK   For each change request: what is its identifier and category? What is the change, in one line?
           Which baseline does it change, by artifact and version? Who requested it, and when? What is its
           priority and current status? What was decided, and why? Who decided it, and when?
     PRIORITY  No row is ever deleted, including a rejected, withdrawn, or postponed one. Decision is a
           distinct field from status, never folded into it. Baseline is named by artifact and version,
           never left as "the plan."
     ROW HINT  A good row names the baseline by artifact and version, states the decision and its reason
           in the same cell, and names one person as decider. A weak row leaves the decision blank because
           the status column looks like it already says enough.
     GOOD  | CHG-014 | Scope | Add a 10-day grace-period reminder email before a business license lapses |
           Business License Renewal Requirements | 2.0 | Dana Okafor, 2026-04-03 | Medium | Approved, with
           a condition | Reduces late-renewal calls to the service desk; condition is a confirmed sender
           identity for the reminder email | Luis Ferreira, 2026-04-15 |
     WEAK  | CHG-014 | | Reminder email | | | | | Approved | | |
     TRAP  Recording only a status and leaving the decision cell blank, or deleting a row once a request
           is rejected. Both leave the next reader unable to tell what actually happened to that
           request. -->


| ID | Category | Change | Baseline artifact | Baseline version | Requested by (date) | Priority | Status | Decision (and reason) | Decided by (date) |
|---|---|---|---|---|---|---|---|---|---|
| {{change_id}} | {{category}} | {{change_description}} | {{baseline_artifact}} | {{baseline_version}} | {{requested_by_date}} | {{priority}} | {{status}} | {{decision_and_reason}} | {{decided_by_date}} |


## Authority and Escalation


<!-- WHAT  Who may decide which changes on this log, and the point at which a change goes above that
           person or group.
     WHY   Every source found on this subject is actually about who holds the authority to decide;
           escalation is simply what happens when a change exceeds it, which is why this section carries
           this name rather than the more common "Escalation" alone. PRINCE2's practitioner literature
           states the role plainly: "The change authority is a person or group to whom the project board
           may delegate responsibility for reviewing and approving change requests or off-specifications."
           HHS supplies a worked threshold from its own program: "a project manager (PM) may be authorized
           to personally approve changes with a project impact of less than $5,000" (HHS's own figure,
           reported here as its example, not as a rule this template sets for every project). PM² carries
           the same idea as a per-row flag rather than a policy statement: "Escalation to the Directing or
           Steering layer is needed? (Yes or No)." Deep dive: change-log_companion.md section 3 (Authority
           and Escalation).
     ASK   Who decides a change on this log, by default? At what point does a change go above that person
           or group, stated as a threshold rather than left to a judgment call each time? What is
           currently escalated, to whom, and what decision is being waited on?
     PRIORITY  State the threshold before it is needed, not the first time a change tests it. Escalate to
           get a decision, never to assign fault for the change itself.
     ROW HINT  A good escalation entry names the change, who it went to, the date, and the decision being
           waited on. A weak entry says only "escalated," with nothing else a reader could follow up on.
     GOOD  "Authority: Luis Ferreira, licensing program manager, decides any change to the renewal
           service's own screens, wording, or reminder schedule. A change to a fee, an eligibility rule, or
           a statutory deadline goes to the licensing board, because those are set outside the service.
           Currently escalated: CHG-017, to the licensing board on 2026-04-22, waiting on whether a late
           fee may be waived after a service outage."
     WEAK  "Whoever is around approves it." (no named authority, no threshold, and nothing to check an
           escalation against)
     TRAP  Naming a board as the decider without stating which changes it actually decides. Without a
           threshold, every row becomes its own judgment call about whether to ask. -->


**Authority:** {{authority}}


**Escalation threshold:** {{escalation_threshold}}


**Currently escalated:** {{escalation_record}}

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).