Issue Report

An Issue Report is a description of one or more issues. It also contains an impact assessment of the issue(s). The report is usually created (first information is added) when the issue is first registered in the Issue Register. Basic information can be added like Identifier, Issue Type, Date on Which it was Raised, and Raised By. It can then be updated again after the issue has been examined, solutions proposed, and a solution chosen. An Issue Report is only created for those issues that need to be handled formally.

An Issue Report is first created when capturing an issue and can then be updated after the issue has been examined and when proposals are identified for issue resolution. The report can be later be updated to record what option was decided upon, and finally updated when the issues are closed. Note: Not all entries in the Issue Register will need a separately documented Issue Report.

The Issue Report describes an issue in detail. According to PRINCE2, an issue can be 1) request for change, 2) an off-specification, or 3) problem/concern. The procedure to follow for dealing with issues is defined in the Change Management Approach during the Initiation Stage and the name of this procedure is the Issue and Change Control procedure.

The five steps in the Issue and Change Control procedure are mentioned below and both Issue Register and Issue Report can be updated at each step.

• Capture: Determine type of issue, formal, informal, type (3 types)
• Assess: Assess the impact of the issue on the project objectives
• Propose: Propose actions to take – so identify the options, evaluate, and recommend
• Decide: Someone decides whether to approve or reject the recommended solution
• Implement: Put the recommended solution in action (taking corrective action)

Timeline Issue Report

Issue Reports are created and updated during the Controlling a Stage process by the Project Manager during the following activities

• Capture and examine risks and issues
• Escalate issues and risks
• Take corrective action

Sample Issue Report

This is a good example of an Issue Report (from the PEN sample project) and also shows the row from the Issue Register. As you can see, most of the effort goes into describing the Impact Analysis and the Recommendation. I have not included the different options in this example.

Source data for Issue Report

• Checkpoint Reports or Highlight Reports
• End Stage Reports can also be used as inputs but not as much as the above-mentioned products
• Oral comments from stakeholders
• Other register files: Quality Register and Risk
• Lessons Log as this may have suggestions from previous projects
• Related products from completed work packages

Format of the Issue Report

• Document (Word or PDF)
• Spreadsheet form which is linked to the Issue Register
• Project management tool which provides space for all project data

Content of the Issue Report

• A unique identifier (same or similar to Issue Register)
• Type of issue (Request for change, off-specification, problem/concern)
• Date raised and who the issue was raised by
• Issue description: clear and easy to understand
• Impact analysis: which should be detailed and look at the six project variables of Time, Cost, Quality, Scope, Benefits and Risk
• Priority and Severity following the organization scales
• Decision description for the request for change, off-specification or problem/concern
• Decision date and close date.

Quality croteria of the Issue Report

• The issue stated is clear and easy to understand if read weeks later
• A detailed impact analysis otherwise it will have little value
• All (withing reason) implications have been considered and its good to look at the effect on the six project variables
• The issue has been examined for its effect on the tolerances
• Decisions are accurately described and easy to understand

Some tips from Frank

• Understand the Issue and Change control procedure that you are supposed to be following
• Don’t rush into finding a solution for an issue and take time to talk to others (Team Managers).
• Remember the Project Manager is the facilitator and the recommendations can come from people with domain knowledge
• The Project Manager must give themselves time to review issues as this is an activity that is often overlooked if the Project Managers gets busy.
• Do not hide major issues from the Project Board and remember that the Executive is responsible for the project.
• Understand the relationship between Issues and Risks