Back to Documentation

Issue Register

In PRINCE2, the Issue Register is the central record of all issues that have been raised and are being formally managed across the project. Issues are raised at the point they are identified — from any source and at any time — and remain on the register until they are resolved or closed. The Issue Register view displays all issues for Change Requests currently in progress. a Change Request End Stage Report summarises the Issues specific to that CR.

Key Principle: Issue management is at the heart of a project’s monitoring function. A project cannot respond effectively to its environment if issues are filtered, delayed, or informally handled when they should be formally managed. Issues should be captured early, when they are still small enough to be resolved within approved tolerances.


The Register

The Issue Register displays all issues across the system, divided into two sections: Open Issues and Resolved Issues. Click any row to open the issue detail and view or update it.

Columns

ColumnDescription
CR NumberThe Change Request this issue is associated with. Click to navigate directly to the Change Request.
CT NumberThe Task (Change Task) this issue was raised against, if applicable. Click to navigate to the task.
Issue TextA summary of the issue content.
Date RaisedThe date the issue was first logged.
Date ResolvedThe date the issue was closed. Blank for open issues.
Days Open / Days to ResolutionFor open issues, the number of days elapsed since the issue was raised. For resolved issues, the total number of days from raising to resolution.

Open Issues

The upper table lists all issues that have not yet been resolved. These represent active items requiring attention. An issue appearing here means it has been formally captured and is being tracked — it should have an owner and a plan for resolution.

Note: The age of an issue (Days Open) is a useful signal. Issues that remain open for extended periods without a resolution plan may indicate that they need escalating to the Change Manager/Board, or that the tolerance thresholds for the associated stage need to be reviewed.

Resolved Issues

The lower table provides a complete historical record of issues that have been formally resolved. Resolved issues remain visible for audit and lessons-learned purposes. The Days to Resolution column provides data that can inform planning on future change requests — a pattern of slow resolution may indicate systemic problems worth capturing as a lesson.


Issue Detail

Clicking any row in the register opens the Issue Detail dialog. The behaviour of this dialog depends on whether the issue is open or resolved.

  • Open issues open in edit mode, allowing the issue content and resolution to be updated, and the issue to be resolved.
  • Resolved issues open in view mode. The record is read-only once an issue has been formally resolved.

Issue Metadata

The top section of the dialog displays the key reference information for the issue:

FieldDescription
CR NumberThe Change Request this issue is linked to.
CT NumberThe Task this issue was raised against, if applicable.
Raised ByThe user who created the issue.
Date RaisedThe date and time the issue was first logged.
Date ResolvedDisplayed only for resolved issues. The date and time resolution was confirmed.
Days Open / Days to ResolutionElapsed time, calculated automatically.

Status Badge

The badge in the dialog header indicates the current status of the issue:

StatusMeaning
OpenThe issue has been raised and is actively being managed. Action is required.
ResolvedThe issue has been formally closed with a recorded resolution.

Issue Content

The full text of the issue as originally raised. For open issues this field is editable, allowing the description to be refined as more information becomes available.

A well-formed issue entry should describe:

  • What has happened or what problem has been observed
  • Where in the change process it occurred (which task or stage)
  • The impact or potential impact on the change request

Note: PRINCE2 distinguishes between issues that can be handled informally — recorded in a daily log and managed by the project manager without escalation — and those that require formal management. Issues appearing in this register are those being handled formally. They typically have a material impact on the change, involve a request to change a baseline, or represent a product not meeting its specification.


Resolution

The resolution field records how the issue was or will be addressed. For open issues this can be updated progressively as the resolution is worked through. When the issue is formally resolved, this field becomes the permanent record of the action taken.

A good resolution entry should explain:

  • What action was taken
  • Who took it
  • Whether any follow-on actions remain (e.g. a lessons entry, a risk review, or a change to the baseline)

Important: Resolution is required before an issue can be formally closed. Recording a clear resolution ensures that the register provides a meaningful audit trail and that the same issue does not recur without being recognised.


Actions

Save

Updates the issue content and resolution text without changing the issue status. Use this to record progress notes or refine the issue description while work is ongoing. The issue remains Open.

Resolve

Formally closes the issue. A resolution must be recorded before this action can be completed. Once resolved:

  • The issue moves from the Open table to the Resolved Issues table in the register
  • The Date Resolved and Days to Resolution are recorded automatically
  • The issue becomes read-only — no further edits can be made

Note: Resolving an issue is a deliberate, formal act. It confirms that the matter has been addressed to the satisfaction of the relevant authority and that no further management action is required within the issue register. If follow-on actions remain — such as updating a risk, raising a change request, or capturing a lesson — these should be completed or initiated before the issue is resolved.

Cancel

Discards any unsaved changes and closes the dialog. The issue record is returned to its last saved state.


Relationship to Other Records

Issues in this register do not exist in isolation. Depending on the nature of the issue, it may be connected to other records in the system:

  • Change Requests — An issue may trigger a formal change request if it reveals that the agreed baseline needs to be modified to resolve it.
  • Risk Register — A pattern of similar issues, or an issue that reveals a new uncertainty, may warrant a new or updated risk entry.
  • Lessons — Issues that reveal a process gap, an estimation error, or a planning assumption that proved incorrect should be captured as lessons so that future change requests can benefit from the experience.

Tip: When reviewing the Issue Register as part of a stage review, look for patterns across issues — repeated issues of the same type on multiple change requests are a leading indicator that a process or template needs improvement, and should be escalated as a lesson rather than managed as individual cases.

← Business Case Risk Register →