Issue Management

Definition

Issue Management is the disciplined handling of problems that have already occurred and require action to prevent damage to cost, schedule, scope, quality, or safety. An issue is distinct from a risk: a risk is potential, an issue is real. Confusing the two is one of the most common governance failures on troubled projects, because risks get treated as issues (panic) and issues get treated as risks (paralysis).

Issue vs Risk vs Action vs Decision

Mature project governance separates four registers:

• Risk register — future, probabilistic, mitigated.
• Issue log — present, certain, resolved.
• Action log — task assigned to an individual with a due date.
• Decision log — choice made, by whom, with rationale.

An entry mis-classified across these four registers becomes invisible. The classic failure is logging an issue as an action item: it gets a name and a date but loses its impact tracking, escalation path, and closure criteria.

History

Issue management as a discrete process emerged from defence and aerospace quality systems in the 1970s, where non-conformance reports (NCRs) required formal disposition. Software adapted it through defect tracking systems (Bugzilla, Jira) in the late 1990s, and construction followed with site instruction and technical query (TQ) registers. Modern integrated PMIS platforms unify these into a single issue stream with discipline-specific workflows.

The Issue Lifecycle

1. Identify and log — anyone on the project can raise an issue; the project controls team curates the log.
2. Classify — by impact (safety, cost, schedule, quality, reputation) and severity (1–4).
3. Assign owner — one named individual with authority to resolve, not a department.
4. Triage — within 24 hours for severity 1, within a week for severity 4.
5. Resolve or escalate — if the owner cannot resolve within the SLA, escalation is automatic, not discretionary.
6. Verify and close — closure requires evidence the impact has been contained, not just an opinion.
7. Promote to lesson — recurring issues become candidates for the lessons-learned register.

Severity and Escalation

A typical severity matrix used on capital projects:

• S1 — Critical: safety, environmental, or contract-termination risk. Escalation to sponsor within hours.
• S2 — Major: threatens a contractual milestone or causes >5% cost variance on a control account. Escalation to project director within 48 hours.
• S3 — Significant: impacts a non-critical activity or a control-account variance <5%. Resolution within two weeks.
• S4 — Minor: housekeeping or process clarification. Resolution within the month.

Real-World Construction Example

On a 380 kV transmission line project, the contractor discovered that 14 of 62 tower foundations had been cast with concrete from a batching plant whose 28-day cube tests later failed the specified strength by 4–7%. The site team raised it as an action ("re-test cubes"). It should have been an S1 issue. Two weeks were lost before the project director became aware, by which time three towers had been erected on the suspect foundations. Reclassified correctly, the project triggered third-party core sampling, engineering re-analysis, and a localised strengthening solution costing USD 320,000 — but avoided removal of any tower. The post-mortem produced a hard rule: any concrete cube test failure is automatically S1 until a structural engineer downgrades it in writing.

Real-World IT / Agile Example

An e-commerce platform's checkout flow began returning intermittent 500 errors during a Black-Friday rehearsal. The SRE on call logged it in the team's Slack channel — not in the issue tracker. Two more engineers hit the same error independently over the next 36 hours, each filing fresh tickets. By the time the team realised they had three duplicates of the same incident, the underlying cause (a connection-pool exhaustion in a payment gateway client) had cost six days. The retrospective fix was structural: a single incident channel feeding directly into a unified issue log, with deduplication enforced by the on-call lead.

Project Controls Perspective

Controls teams use the issue log as a leading indicator. A sudden rise in S1/S2 issues in a particular discipline or area predicts cost and schedule variance two to four weeks ahead of the earned-value curves. A flat issue log on a busy project is suspicious — it usually means issues are being absorbed informally rather than logged, and the next surprise will be expensive. Mature PMOs publish issue ageing reports alongside the monthly cost and schedule narrative.

Common Mistakes

• Logging issues as actions, hiding the impact dimension.
• Allowing multiple parallel logs (one in email, one in a spreadsheet, one in Jira) — the integrated picture is lost.
• Assigning issues to departments instead of individuals; departments do not resolve, people do.
• Closing issues without evidence of impact containment.
• Letting severity drift: an S2 left open for two months has effectively become S1 by inertia.
• Not promoting recurring issues to the lessons register.

Expert Tips

• Open the weekly progress meeting with the S1/S2 issue list. If the list does not match the project director's mental model, the log is wrong or the director is.
• Publish issue ageing in days, not status. "Open 47 days" tells the truth; "in progress" hides it.
• Make closure require evidence. A photograph, a test report, a Git commit hash — not an opinion.
• Track repeat issues by category. If "drawing clarification" appears 23 times, the upstream design process has a defect; fix the cause, not each instance.
• Tie escalation to the calendar, not to judgement. Automatic escalation removes the political cost of raising the alarm.

Key Takeaways

• An issue has happened; a risk might happen. Confusing the two destroys governance.
• One issue log, one owner per issue, one severity matrix, one escalation calendar.
• Ageing and category trends are leading indicators of cost and schedule variance.
• Closure requires evidence; absence of complaint is not evidence.
• Recurring issues are lessons in disguise — promote them before they repeat again.

Related Concepts

Issue Management interlocks with Risk Management, Change Control, Lessons Learned, Stakeholder Engagement, and Quality Management. Issue ageing dashboards and severity templates are available in the PMMilestone.org governance toolkit.