The issues practice: types of issue and the register

Risks are things that might happen. Issues are things that have happened, or requests that have been made, and that need someone to decide what to do. A project that handles its issues well keeps a clear record of every significant event, assesses each one against the baselines, and makes sure decisions are taken at the right level. A project that handles them badly ends up with changes nobody approved, defects nobody owns, and a board that learns about problems from rumours. This lesson covers what counts as an issue, the types PRINCE2 recognizes, the records used to capture them and the procedure for managing them. Lesson 6 looks closely at change control.

What an issue is

In plain terms, an issue is a relevant event that has happened, was not planned, and requires management action. It can be raised by anyone with an interest in the project at any time: a team member, a supplier, a user, a board member or a member of the public. Issues can be about anything that affects the project: a request to change a product, a product that does not meet its specification, a problem with a supplier, a question from a stakeholder, a change in the law or an opportunity that has suddenly appeared. What makes it an issue is that it needs a decision.

Types of issue

PRINCE2 groups issues into three types, because each type tends to be handled differently. A request for change is a proposal to change a baseline, such as a product description, a plan or the business case. An off-specification is something that should be provided by the project but currently is not, or is forecast not to be, provided: a missing product or a product that does not meet its specification. A problem or concern is any other issue that the project manager needs to resolve or escalate, such as a supplier dispute, a stakeholder complaint or an external event. Some study guides list external events and business opportunities as separate categories; in practice these are usually handled as problems or concerns, or, if they are still uncertain, as risks.

Only requests for change and off-specifications go through change control, because only they affect an agreed baseline. A problem or concern may lead to a request for change, for example if the factory shutdown means the plan must be altered, but in itself it is handled by the project manager's judgment within the stage tolerances, or escalated if it threatens them.

Formal and informal handling

Not every issue needs the full procedure. PRINCE2 distinguishes between issues that can be handled informally, which the project manager notes in the daily log and resolves, and issues that need formal handling, which are recorded in the issue register and may be described in an issue report. The issue management approach for the project defines where the line falls. A useful test is whether the issue affects a baseline, needs a decision above the project manager, or needs a formal audit trail. If none of these apply, the daily log is enough.

In PRINCE2 7, the daily log and the issue register, together with the risk register, quality register, lessons log and product register, are all described as parts of the project log. This reflects how most projects now work: one tool, often a project management application or a shared workspace, holds all the records, with different views for different purposes.

The issue management approach

During initiation, the project manager prepares an issue management approach, approved by the board as part of the project initiation documentation. It describes how issues and changes will be handled on this project. In plain terms it covers the procedure, the tools and records, the scales used for priority and severity, the change authority and change budget, how off-specifications and concessions are handled, how issues are reported, the timing of reviews and the roles involved. It also sets the line between informal and formal handling.

The issue management procedure

PRINCE2 describes a procedure for managing issues formally. In plain terms its steps are: capture the issue and decide whether it needs formal handling; assess its impact on the project's objectives, business case, plans and risks; recommend options and a preferred course of action; decide, by the person or body with the authority to do so; and implement the decision, updating plans and records. Throughout, the project manager keeps the person who raised the issue informed.

Decisions depend on the issue type and size. For a request for change, the decision-maker may approve, reject, defer or ask for more information. For an off-specification, the options include requiring the product to be fixed, granting a concession so the product is accepted as it is, or deferring. For a problem or concern, the project manager may resolve it within tolerance, or escalate it if it threatens stage tolerances. An issue that would cause a stage tolerance to be exceeded is escalated to the board, usually in an exception report, which lesson 9 covers.

Keeping the register healthy

An issue register can easily become a graveyard of old items that nobody closes. A healthy register has few very old open issues, clear owners and dates for each, and a mix of types that makes sense for the stage. The code below reads a small extract of Ridgeline Water's register in week 22 of the pilot, calculates how long each open issue has been open, flags any that have been open longer than the limit set for their severity, and summarizes the open issues by type.

today = 22
limits = {1: 1, 2: 3, 3: 6, 4: 10}  # weeks allowed open by severity
issues = [
    # id, type, severity, raised week, closed week or None, summary
    ("I-01", "request for change", 3, 8, 12, "Monthly bills in pilot district"),
    ("I-02", "off-specification", 2, 13, None, "Radio coverage 96 % against 98 %"),
    ("I-03", "problem or concern", 2, 15, None, "Factory shutdown announced"),
    ("I-04", "off-specification", 2, 15, 19, "Meter batch 2 failed sample"),
    ("I-05", "problem or concern", 4, 9, None, "Councillor query on district choice"),
    ("I-06", "request for change", 3, 18, None, "Add Spanish and French alert text"),
    ("I-07", "request for change", 4, 20, None, "Change portal logo"),
]
open_items = [i for i in issues if i[4] is None]
print(f"open {len(open_items)} of {len(issues)}")
for iid, typ, sev, raised, closed, text in sorted(open_items, key=lambda x: x[2]):
    age = today - raised
    flag = "  OVER LIMIT" if age > limits[sev] else ""
    print(f"{iid} sev {sev} open {age:2} weeks  {text}{flag}")
by_type = {}
for i in open_items:
    by_type[i[1]] = by_type.get(i[1], 0) + 1
print(by_type)

open 5 of 7
I-02 sev 2 open  9 weeks  Radio coverage 96 % against 98 %  OVER LIMIT
I-03 sev 2 open  7 weeks  Factory shutdown announced  OVER LIMIT
I-06 sev 3 open  4 weeks  Add Spanish and French alert text
I-05 sev 4 open 13 weeks  Councillor query on district choice  OVER LIMIT
I-07 sev 4 open  2 weeks  Change portal logo
{'off-specification': 1, 'problem or concern': 2, 'request for change': 2}

Five of the seven issues are open. Three are over their limits: the radio coverage off-specification (9 weeks against 3 for severity 2), the factory shutdown (7 weeks against 3) and the councillor's query (13 weeks against 10). The two severity 2 items should already have been decided; their age suggests they are waiting for a decision above the project manager, and both should appear prominently in the next highlight report. The councillor's query is minor in project terms but politically sensitive, and leaving it unanswered for three months is a communication failure that the issue management approach was meant to prevent.