PM² Logs: risks, issues, decisions and changes as a governance system
Twenty-eighth article in the “Learning PM² Through a Project” series
A log is not for “keeping track” in a bureaucratic sense. It makes visible information otherwise lost in chats, meetings, tickets and people’s memory: what may happen, what has already happened, what is requested to change and why a decision was made.
In PM², the Risk Log, Issue Log, Change Log and Decision Log are complementary tools. Used well, they connect daily monitoring to governance; used badly, they become four disconnected, outdated lists.
Four logs, four questions
| Log | Question it answers | Item recorded |
|---|---|---|
| Risk Log | What could happen and harm or benefit the project? | Uncertain event, probability, impact, response, owner and trigger. |
| Issue Log | Which real problem needs action? | Current event or condition, impact, actions, owner, due dates and escalation. |
| Change Log | What is requested to change compared with an approved baseline? | Change request, impact, decision and resulting updates. |
| Decision Log | Which important choice was made, by whom and why? | Decision, options, rationale, actions and responsibilities. |
The key distinction is temporal: a risk is uncertain; an issue is real. A change is a request to alter something approved; a decision records a choice that may concern a risk, issue, change or another governance matter.
How the logs connect
flowchart TD
A[Risk Log: uncertain event] -->|materialises| B[Issue Log: real problem]
B -->|may require| C[Change Log: baseline modification]
A -->|response or acceptance| D[Decision Log]
B -->|trade-off or escalation| D
C -->|approved, rejected or deferred| D
D --> E[Plans, baselines and communications updated]
Not every arrow is mandatory. A risk may be mitigated without a formal decision; an issue may be resolved by the team without a change; a change may be rejected without producing work. The model’s value is knowing when to connect information and prevent it from disappearing.
Risk Log: make uncertainty actionable
An effective risk record includes:
| Field | Example |
|---|---|
| Cause-event-effect | Because of an external provider, push policies may change, delaying go-live. |
| Probability and impact | Medium / high. |
| Owner | Technical lead for integration. |
| Response | Mitigate: early testing, policy monitoring, defined fallback. |
| Trigger | Provider notice or end-to-end test failure. |
| Residual risk | Still medium after mitigation. |
The word “monitor” alone is not a complete response. Specify who watches what, at what frequency, and which event activates action.
Issue Log: turn a problem into verifiable action
| Field | Example |
|---|---|
| Issue | Push notifications do not arrive on some Android devices. |
| Impact / priority | High: waiting list and go-live are at risk. |
| Owner | Technical lead for notification module. |
| Actions | Analyse logs, correct configuration, test devices, email fallback. |
| Due date / escalation | Diagnosis within 48 hours; escalate to PO/BM if fallback becomes necessary. |
| Closure | Test evidence and decision on adopted solution. |
An issue is not closed merely because a workaround was selected. It may close with an accepted workaround, but the log must state who accepted the impact and which follow-up remains.
Change Log: protect baseline without blocking value
A change request is not a “wish” scattered in a meeting. It is an identifiable request that modifies a requirement, scope, plan, cost, schedule, deliverable, acceptance criterion or other baseline.
| Field | Example |
|---|---|
| Request | Add CSV export of attendance. |
| Rationale | Manager needs to reconcile attendance with an external system. |
| Impact | Five days of effort, new tests, possible go-live delay. |
| Options | Include and defer date; substitute another feature; defer to next release. |
| Decision | Deferred to next release to protect go-live. |
| Actions | Update backlog/plan and communicate outcome to requester. |
The Change Log also retains rejected or withdrawn changes: it prevents the same request returning later as if it were new and without the context of the earlier decision.
Decision Log: do not lose the rationale
The Decision Log does not duplicate the other logs. It captures the point they do not always make explicit: the choice, authority, why and consequences.
| Field | Example |
|---|---|
| Decision | Activate email fallback for waiting list at go-live. |
| Context | Android issue not closed by planned date. |
| Options | Delay go-live; release without notifications; use email fallback. |
| Decision maker | PO/BM, with feasibility confirmed by SP. |
| Rationale | Protect date and core functionality while reducing user impact. |
| Actions | Configure email, update guide, plan push fix and monitor adoption. |
Minor, reversible decisions do not always need a formal log. The test is the value of memory: if in a month it will matter who decided, based on which options and with what consequences, record it.
A genuinely useful log review
Review should not consist of reading every row. At a useful cadence, the PM and owners check:
- new, increased, materialised or no-longer-relevant risks;
- issues without owner, action, date or closure evidence;
- changes awaiting assessment or decision;
- decisions with incomplete actions;
- links that must update the Work Plan, baselines, communications and plans.
| Signal | Action |
|---|---|
| Risk without trigger or response | Complete assessment or explicitly reduce priority. |
| Issue “in progress” for many weeks | Reassess owner, actions, tolerances and escalation. |
| Change without estimated impact | Do not bring it to decision until proportionate analysis exists. |
| Decision without follow-up | Assign actions, owners and dates; otherwise it has not truly been implemented. |
The Annotatio case: from external dependency to decision
For Smart Bookings, the notification provider announces an upcoming API change.
| Moment | Log | Example |
|---|---|---|
| Announcement not yet effective | Risk Log | Compatibility risk; early test and fallback as mitigation. |
| Test fails | Issue Log | Android notifications do not work; technical owner and diagnosis within 48 hours. |
| Go-live or behaviour must change | Change Log | Proposal: release with email fallback, modifying the operational notification criterion. |
| Option is chosen | Decision Log | PO/BM approve email fallback; actions for guide, configuration and later fix. |
This chain prevents two opposite errors: treating a risk as an already real problem, or leaving a real problem stuck in the Risk Log without urgent actions.
Where to keep the logs
PM² does not impose a tool. A small project may use simple tables; a complex project may use an integrated portfolio, ticketing or repository system. Minimum requirements remain the same:
- a single source or clear official references;
- unique identifiers and links between logs;
- appropriate access for roles and confidential information;
- enough history and versions for audit and learning;
- regular review and visible accountability.
The tool should reduce the cost of updating and consulting the project’s truth, not increase it.
Do not confuse these
| Statement | Correction |
|---|---|
| “A severe risk is an issue.” | No: it remains a risk while uncertain; it becomes an issue when real. |
| “The Decision Log replaces the Change Log.” | A decision may approve a change, but the Change Log retains the specific request and impact. |
| “A workaround automatically closes an issue.” | It may close it only when impact is accepted and closure is documented. |
| “Logs are only for the PM.” | They serve owners, team and governance to act and decide on reliable data. |
Three questions to anchor it
- Is this item uncertain, real, a modification request or a choice already made?
- Which log should contain primary information, and which others should be linked?
- Which action, owner and date make this record useful to the project?
Flashcards
Q: What is the difference between Risk Log and Issue Log?
A: The Risk Log manages uncertain events; the Issue Log manages already real problems.
Q: Why does a rejected change remain in the Change Log?
A: To retain rationale, impact and decision, preventing it from returning without context.
Q: What is the Decision Log for?
A: To record the choice, options, decision-maker, rationale and resulting actions.
Exam-style question
During a review, the team sees that the risk “supplier may delay” has occurred. The PM only increases the impact score in the Risk Log and continues normal monitoring.
What is the best correction?
Answer: the risk has materialised and should become an issue with owner, actions, dates and potential escalation. Update the Risk Log to retain history and learning, but it does not replace urgent management of the real problem.
Source
The Change Log, Risk Log, Issue Log, Decision Log and associated management plans are described in the European Commission’s PM² Methodology Guide 3.1.
Next: Project reporting and progress control, turning data and logs into timely forecasts, decisions and actions.