Highlight Report – for management control.
At an End Stage Assessment, or an Exception Assessment, either the next Stage Plan or an Exception Plan approved by the project board, tolerance for the next stage is set, and the frequency of the highlight report for the next stage are stated.
The Highlight Report is created by the project manager and provided the project board with summary information about the status of the stage and the project. The highlight report is also distributed to other key stakeholders as defined in the Communication Management Strategy document. Typically the Highlight Report will be asked for on a monthly basis, but its frequency will depend on many factors within the stage, for example how complex, risky, or lengthy the stage is.
The highlight report can be given verbally, but for audit purposes is best given in some form of written medium (an email would be fine!) The highlight report is meant to be short and focused, possible two side of A4 and should only take around 60 minutes to create it. Remember that the project board is managing by exception, and they expect that the highlight report should merely discus small deviations and issues if any…
Typical Contents of a Highlight Report.
The sections below are fairly self-explanatory:
Date. Either today’s date, or the date that you created the highlight report.
Period. The reporting period or a date range that covers the highlight report information.
Status Summary. Just that. A sentence or two is normally sufficient. The project board and other relevant stakeholders need to get a flavour of what information is within this particular highlight report. If there was a significant event during the reporting period you may summarize it or possible give a general synopsis of project progress.
This reporting period.
Work Packages. Just a ‘body count’ here! Work packages that are pending authorization (from the project manager), in execution, and those that have been completed during this reporting period.
Products completed during this reporting period. Obvious!
Products planned, but not started or completed during the period. This is important as you are bring to the attention of the project board via this highlight report, and off-plan activities or product milestone dates.
Corrective actions taken during the period. Usually related to the above section to show that Any off plan activities or products are being dealt with. Be sure to advise whether such off-plan actions are having the desired effects.
Next reporting period.
Work Packages to be authorized. Just a ‘body count’ here! Work packages to be authorized (from the project manager), in execution, and those that have been completed during the next reporting period.
Products completed in the next reporting period. Obvious!
Corrective actions to be completed during the next period. Usually related to the above section as a carry over from the current situation to show that Any off plan activities or products are being dealt with. Be sure to advise whether such off-plan actions are having the desired effects.
Project and stage tolerance status. Show the total tolerance for each, how much has been used, and the amount of tolerance remaining. Comment if any tolerances that are nearing escalation, but for the present time you are not forecasting tolerance deviation. You may wish to justify such statements!
Requests for change. Any that have been raised at any reporting period in the past, and a status update and forecast.
Key issues and risks. These may have already been touched on (in terms of any deviation from plan, above). The risk register should contain the latest status, and should be simply summarized here. If there is a risk or change budget, you may like to show actual and forecast spend.
Lessons Report. This should include any lessons that have been applied, or those that you feel should be. The full lessons report is created at project closure, but there may be any here that deserve implementation for the greater good of the project.
PRINCE2 recommends the following Highlight Report actions:
Typically checkpoint reports occur on a weekly basis, and the project manager will want to collect this information to form the basis of the Highlight Report. Also, the risk and issue registers are used to gather status on these topics for inclusion within the Highlight Report. The specialist team will have been creating the specialist products, carrying out quality checking activities, and getting the requisites approvals as detailed in each Product Description. Therefore a rich source of progress is information can be gleaned from the quality register for inclusion in the highlight report.
There may be lessons to be learnt since the last Highlight Report, and these can be gathered from the Lessons Log. The project manager may wish to request a Product Status Account from configuration management to gather the most up-to-date information on product creation progress when prepping the latest highlight report.
Throughout the stage the project manager would have been using the Stage Plan as a reference point to monitor and control the stage, and in doing so, keeping the Stage Plan updated with actual progress.
The Stage Plan, any revisions, and deviations is also a source of information to include within the highlight report.
The project manager’s main responsibility is to ensure that the stage completes within tolerance, and in doing so will normally take many small corrective actions. These corrective actions should be summarized within the highlight report to give confidence to the project board that the stage is being managed appropriately.
The project manager will want to refer to the previous Highlight Report to note any promised or forecasted activities, and ensure that these have been carried out, or state a reasonable reason why these have not been done. The Highlight Report will be distributed to members of the project board, but the Communication Management Strategy should be referred to for other stakeholders that need to be sent copies.
For more information on passing your PRINCE2 Exams - CLICK HERE