It's important that you keep the Project and Programme Board informed about the progress of the project throughout its life cycle. Timely, well-constructed reports will help the Board understand issues affecting project delivery and enable them to make decisions.
You should only compile a report at logical points to inform on progress or status as necessary. Reporting for the sake of producing a report is only going to add to your workload. As part of the Project Start-Up Gateway, you need to agree with the Programme Manager what reports you need to provide, what they will look like, and when you will provide them. This will partly depend on the project type and category. However, there are two reports that you will always need to produce, regardless of the type of project:
- a periodic Traffic Light Report, which gives an update on progress, risks, issues, budget and decisions required
- an End Project Report, which gives a summary of performance and achievements on completion of a project.
Traffic Light Reports
The purpose of the Traffic Light Report is to provide the Project Director and Project Board with summary of the key aspects of the project. These are:
- Overall status and progress against the plan
Each of these sections should provide a brief narrative summary together with a ‘Traffic Light’ status – red, amber, or green – based on the tolerances you agreed with the Programme Manager at the start of the project.
How often you produce a Traffic Light Report will depend on the size and scale of the project. A monthly update on progress is usually sufficient for most projects and often helps to re-focus your mind on what the issues with the project are and what the next steps need to be. (It’s worth noting here that if you produce a report every month, it doesn’t necessarily mean you have to have a Project Board meeting every month.)
End Project Report
The End Project Report is used to inform the Project or Programme Board that the project has been completed and is ready to close. It contains information on:
- How well the project performed against the baseline PID
- How well the objectives have been met
- Lessons learned
- Follow on actions and a date for a post-project review.
Follow on actions are used to highlight further work that could or should be done once the project has handed over the product to the users. This might include things like:
- Training needs
- Change requests that were rejected but still might be worth investigating
- Project issues that weren’t resolved
- Actions for any future review of the project.