Issue report
An issue report provides a detailed description and impact assessment of one or more issues that require formal handling. It supports decision-making by capturing essential information, proposed solutions, and the final decision.
Timeline
The issue report is typically initiated when the issue is first entered into the issue register, capturing basic information such as: Issue ID, issue type, date raised, and raised by.
The report is then updated after the issue has been assessed, options for resolution have been proposed, and a decision has been made. It may be updated once more upon issue closure. Note: Not all entries in the issue register require a standalone issue report — only those that need formal handling, such as major risks, change requests, or off-specifications.
Procedure
The procedure for handling issues is defined in the issue management approach, which is created during the initiation stage.
This procedure includes five general steps, during which both the issue register and issue report can be updated:
- Capture: Identify the type of issue (formal or informal) and classify it into one of the three categories (e.g., change request, off-specification, or other).
- Assess: Evaluate the impact of the issue on the project’s objectives. This step involves understanding how the issue will affect the project’s scope, time, cost, or quality.
- Recommend: Propose possible actions to address the issue. Identify available options, evaluate their impact, and make a recommendation for the best course of action.
- Decide: A designated decision-maker (e.g., the project manager, change authority, or project board) will approve, reject, or modify the proposed solution based on its merits and alignment with the project objectives.
- Implement: Once approved, implement the recommended solution. This includes taking corrective actions and ensuring that the issue is resolved in accordance with the project’s goals.
Timeline
Issue reports are created and maintained by the project manager during the controlling a stage process. They are typically produced or updated during the following activities:
- Capturing and examining issues and risks: Initial creation with basic information.
- Escalating issues and risks: Updating the report with impact assessments and proposed options.
- Taking corrective action: Final updates to reflect the decision taken and closure details.
This ensures that the issue report reflects the full lifecycle of the issue — from identification to resolution.
Source data
Information used to create or update an issue report may come from a variety of sources, including:
- Checkpoint reports and highlight reports: primary sources for identifying emerging issues.
- End stage reports: can provide supporting context, though used less frequently.
- Stakeholder feedback: including informal or oral comments.
- Project registers: such as the quality register and risk register.
- Lessons log: may contain relevant insights or recurring issues from previous projects.
- Completed work package outputs: especially if the product delivered is off-specification or triggers a concern.
Format
The issue report can be created and maintained in various formats, depending on the tools and preferences of the organization:
- Document format: typically a Word or PDF document for formal reporting and sharing.
- Spreadsheet format: A structured sheet that may be linked to the issue register for easier tracking and updates.
- Project management tools: Many tools provide integrated spaces for logging and managing issues alongside other project data (e.g., tasks, risks, and decisions).
The chosen format should align with the project’s complexity and the organization’s standard practices.
Contents
The issue report provides a detailed, formal description of an issue requiring action, supporting informed decision-making through clear analysis and documentation:
- Unique identifier – consistent with or linked to the entry in the issue register.
- Type of issue – identify whether it is a request for change, off-specification, or problem/concern.
- Date raised and raised by – record when the issue was reported and by whom.
- Issue description – A clear and concise summary of the issue.
- Impact analysis – A detailed assessment of the issue’s potential impact on the six project performance aspects:
- Time, cost, quality, scope, benefits, risk and Sustainability
- Priority and severity – rated using the organization’s defined scales.
- Decision description – document the resolution or course of action agreed upon.
- Decision date and closure date – record when the decision was made and when the issue was officially closed.
Quality criteria
To ensure the issue report is useful for decision-making and traceability, it should meet the following quality criteria:
- The issue is clearly described, so it remains understandable even if reviewed weeks later.
- The impact analysis is detailed and relevant — without it, the report holds little value.
- All reasonable implications have been considered, especially the effect on the six project performance aspects (time, cost, quality, scope, benefits, and risk).
- The issue has been assessed for its impact on stage or project tolerances.
- Decisions are clearly documented, including the rationale, and are easy to understand.
Tips
Here are a few practical reminders to help you use the issue report effectively and apply sound judgment when managing issues in a PRINCE2 project:
- Understand the issue and change control procedure you’re expected to follow — this ensures consistency and proper governance.
- Don’t rush to solve an issue. Take time to consult others, especially team managers or those with domain expertise.
- The project manager is a facilitator, not always the technical expert — rely on the knowledge and input of your team.
- Make time to review issues regularly. This activity is often overlooked when project managers are busy, but keeping the project under control is critical.
- Be transparent about major issues. Never hide them from the project board — and remember, the executive is ultimately responsible for the project.
- Understand the connection between issues and risks. An issue may stem from a realised risk or trigger new risks that need to be logged and monitored.
—o—
Written by Frank Turley.
If you have questions or doubts after using this wiki, you can ask for help on the Facebook or LinkedIn study groups.