The Use and Content of the Issue Register and Issue Report

The issue register and issue report.

There is often confusion between the issue register and the issue report, what their purposes and when they are used.  The purpose of this article is to clarify this.

Put simply, an issue is something that has already happened (whereas a risk is something that MAY happen at some point in the future).

The starting up a project process is used pre-project, and it is here that the daily log is created.  The daily log is used to capture and manage amongst other things, any issues that may occur.

During the initiation stage, the project initiation documentation (PID) is assembled.  The configuration management strategy forms part of the PID, and it is at this time that the issue register is created.  Any appropriate on existing issues are being transferred from the daily log to the newly formed issue register for on-going management.

PRINCE2 is clear on this point, and that is that the issue register should only be used for those issues which are to be managed formally.  The daily log will continue to be used for informal issues.

The purpose of the change theme is to identify, assess and control any potential and approved changes to the project baseline and uses the term issue to cover any event that has already happened, was not planned, and requires some form of management action.

An issue can be a problem or concern, a request for change, or an off-specification which is defined as anything that should be provided by the project, but currently is not – or not forecast, to be provided.  I have described the issue and change control procedure in other articles, and therefore only wish to focus here on the use of the issue register and issue report.

Whenever an issue is logged on the issue register it must be accompanied by an issue report, and it is therefore important that both of these management products are kept updated and harmonised with each other.

The issue register and issue report to contain some identical information on a given issue, but put simply, the emphasis is that the issue register entry focuses on the description and definition of the issue, whereas the issue report focuses on the analysis of the impact along with the action recommendation, decision and ultimate closure.

The Issue Register and Issue Reports that have been rasied during a stage will be used as a reference for when creating the End Stage Report.

The issue register.

This is monitored by the project manager throughout the project and its purpose is to capture and maintain information on all formal issues.

Issue identifier and type.

This will typically be allocated by those providing configuration management (normally project support), and is an Alpha numeric code and a definition of one of the three issue types as stated above (requests for change, off-specification, or a problem or concern).

The Date issue was raised and who raised it.

Obviously, the date the issue was raised and the name of the individual who raised it.

The issue report author.  The name of the individual who created the issue report

Issue description.

This should be a detailed statement describing the nature of the issue, what caused the issue in the first place, and the impact of the issue if no action would be taken.

Priority and severity.

The configuration management strategy document will have chosen appropriate scales and description was to be used for priority and severity, and these should be used here.

An example of an approach to prioritise issues is called MoSCoW, and would be used for requests for change.  It stands for must have (essential), should have (important), could have (useful), or won’t have (not important for now).

Severity can use some form of alphanumeric description as there are many ways to do this.  The severity scales may be described as minor, significant, major, or critical, and these might accompany recommendation of which role is responsible for making a decision; for example project manager, project board, change authority, or corporate/programme management.

Status and a closure date. 

These fields show the current status of the issue and whether or not it has been closed and hence no further action is needed.

Issue report.

The information contained within the issue report may only include the first few fields, but it is updated throughout the life of the issue culminating when the issue has been closed.

When a project manager first forecasts that tolerance is to be exceeded, the first action is to block it on the issue register and create an issue report.  This may be sent directly to the project board, or it may accompany the exception report.

When a formal issue is raised for whatever reason, the project manager may give the issue report to the project board when seeking their advice or guidance.  Where the issue of the issue register can be dealt with by taking corrective action by the project manager, then information within the issue report will normally be included when it is time for the next highlight report to be sent to the project board.

Remember also, that if tolerance is set on a work package and or the team manager is now forecasting that this tolerance is to be exceeded, then this will be brought to the project manager’s attention via an issue of the issue register.

Here is the content of the issue report:

Issue identifier, issue type, Date raised, raised by, issue report author, and issue description. 

These contain exactly the same information for this issue as was entered into the issue register.

Impact analysis.

This describes a detailed analysis of the impact of this issue.  Such impacts should be described to include both the customer/user, business, and supplier areas.

Project aspects that should be considered for impact analysis include; project performance targets (time, cost, quality, scope), impact of the benefits within the business case, and the project aggregated risks (new risks created, existing risks modified, and the overall level of risk including risk tolerance.

Recommendation.

This describes the actions needed to resolve the issue and the justification for why these only best actions.  The project manager is responsible for making this recommendation.

Priority and severity.  These sections have already been entered within the issue register.

Decision approval plus decision and closure dates.

The decision taken which could include any of these:

• Approve the change
• Reject the change
• Defer a decision
• Request more information
• Grant a concession
• Ask for an exception plan

This should include a record of are there make the decision, the date that it was made, and the closure date if this has now happened.

For more information on how to pass your PRINCE2 Foundation and Practitioner exams CLICK HERE