Issue and Decision Management in PM²: resolving what is real and remembering why choices were made
Nineteenth article in the “Learning PM² Through a Project” series
A project is not in trouble because it has issues. It is in trouble when issues remain implicit, have no owner, due date or escalation path, and reappear week after week in reports.
In PM², Issue Management handles current or already occurred problems; Decision Management retains important choices, their rationale and consequences. They are different but closely connected activities.
Issue: a real problem requiring management
An issue is a current event, condition or problem requiring attention and action. It may concern requirements, resources, schedule, quality, suppliers, security, stakeholders or blocked decisions.
| Not an issue | An issue |
|---|---|
| “The supplier may be late.” — risk. | “The supplier has communicated a delay.” — issue. |
| “We might have too few testers.” — risk. | “Two assigned testers are unavailable.” — issue. |
| “We would like to add a feature.” — change request. | “The approved feature does not meet an acceptance criterion.” — issue. |
This distinction prevents incorrect treatment: a risk needs prevention and monitoring; an issue needs containment, resolution or escalation.
The Issue Management cycle
flowchart LR
A[Identify and log] --> B[Analyse impact and urgency]
B --> C[Assign owner and actions]
C --> D[Monitor and communicate]
D --> E{Resolved?}
E -- No --> F[Escalate or revise response]
F --> D
E -- Yes --> G[Close with evidence]
Closure does not mean “we no longer talk about it”. It requires evidence that action is complete and the effect is acceptable; otherwise the issue remains open or creates a new issue, risk or change.
What makes an Issue Log useful
An effective Issue Log answers in seconds: what happened, how much does it matter, who is handling it, by when, and what is blocked?
| Field | Purpose |
|---|---|
| Description and date | Make the problem concrete. |
| Impact and priority | Decide how quickly to act. |
| Owner | Make someone accountable for coordinating resolution. |
| Actions and due dates | Turn the problem into verifiable work. |
| Status and linked decisions | Avoid vague, repetitive updates. |
| Escalation | Clarify when and to whom to raise a blockage. |
| Closure evidence | Demonstrate that it was actually resolved or accepted. |
The owner need not personally resolve everything; they must ensure that resolution is driven, verified and communicated.
Priority: impact, urgency and tolerances
Not every issue is an emergency. A useful classification distinguishes:
| Priority | Example | Response |
|---|---|---|
| Critical | Release blocked or security risk. | Immediate action, high visibility, escalation if needed. |
| High | A milestone or material requirement is threatened. | Owner and near-term response plan; frequent monitoring. |
| Medium | Problem with an acceptable workaround. | Plan and verify the correction. |
| Low | Limited impact and no effect on objectives or users. | Handle in normal flow or consciously accept. |
Priority is not based only on technical severity. A small anomaly in legally relevant data may be more urgent than a highly visible cosmetic defect.
Decision Management: the memory of choices
Every project makes decisions: accepting a trade-off, choosing a technical option, deferring a requirement, authorising a change, accepting residual risk, escalating or changing a dependency.
An important decision should be recorded because, after weeks, people tend to remember the choice but not its reason. The Decision Log makes context and responsibility verifiable.
| Field | Example |
|---|---|
| Decision | Release Smart Bookings without CSV export in the first version. |
| Context / problem | CSV export delays go-live by five days. |
| Options considered | Include and defer; substitute another feature; defer CSV. |
| Decision maker | PO/BM, according to agreed governance. |
| Date and rationale | Protect launch date and validate core functionality first. |
| Consequences / actions | Log change as deferred; plan it for the next release; update communications. |
A Decision Log does not replace minutes when those are needed, nor does it replace the Change Log or Risk Log. It connects to them: a decision may close an issue, approve a change or accept a risk.
When to escalate
The PM should not wait until a situation becomes irreversible. Escalation is appropriate when:
- an issue exceeds schedule, cost, quality or scope tolerances;
- the team lacks the authority or capacity needed to resolve it;
- a choice between options with business impact is needed;
- two stakeholders have a conflict the PM cannot resolve;
- delaying a decision materially increases harm or cost.
A good escalation brings facts, impact, options, recommendation and required decision. Simply saying “we have a problem” transfers pressure; it does not enable a decision.
The Annotatio case: Android notifications do not work
During the Smart Bookings pilot, Android notifications do not arrive on some devices. The issue could be recorded as follows:
| Field | Content |
|---|---|
| Issue | Waiting-list promotion notifications do not reach some Android users. |
| Impact | High: risk of empty places and failure of the waiting-list flow. |
| Owner | Technical lead for the notification module. |
| Actions | Analyse logs and configuration; test device models; prepare email or in-app fallback. |
| Due date | Diagnosis within 48 hours; go-live decision after correction testing. |
| Escalation | If unresolved within 48 hours, PO/BM choose between delay, fallback or reduced scope. |
A linked decision could be: “keep go-live, activate email as Android fallback and plan the push correction within the first week”. That is a trade-off decision, not merely closing the issue.
Do not confuse these
| Statement | Correction |
|---|---|
| “An issue is a severe risk.” | No: it is an already real problem. |
| “If an issue has an owner, the PM can forget it.” | The PM monitors, facilitates, communicates and escalates when needed. |
| “The decision is implicit in the chat or meeting.” | If material, make it explicit and log it with rationale and action owners. |
| “Closing an issue means deleting it from the log.” | Retain the solution and closure evidence. |
Three questions to anchor it
- Is this item a risk, issue or change request?
- Which owner, action and date make the issue manageable?
- Which decision is needed, who must make it, and which options should they assess?
Flashcards
Q: What is an issue?
A: A real problem, event or condition requiring attention and action.
Q: What is the Decision Log for?
A: To retain the decision, context, options, decision-maker, rationale and resulting actions.
Q: When should the PM escalate?
A: When tolerances or available authority are exceeded, a business trade-off is needed, or delaying a decision increases impact.
Exam-style question
An external dependency has already blocked acceptance testing. The PM keeps it in the Risk Log with high probability and waits for the next status meeting before involving other roles.
What is the correct approach?
Answer: the blockage is an issue, no longer a risk. The PM should log it in the Issue Log, assess urgency and impact, assign owner and actions, and escalate promptly if the team cannot resolve it within tolerances. The Risk Log may be updated as a materialised risk.
Source
Issue Management, the Issue Management Plan, Issue Log and decision-management activities are covered in the European Commission’s PM² Methodology Guide 3.1.
Next: Quality Management, for building quality into the work rather than merely inspecting it at the end.