Chapter 17

Templates for Reporting

In This Chapter

Templates for reports made during the project

Templates for reports and the end of the project and after it

This chapter covers templates you can use to help you prepare reports. At the start of the project consider what reports you’ll need and put the details in the Communications Plan for the project (part of the PMP – the Project Management Plan).

As with all reports, small is beautiful. Think critically about the items on each template and remove any headings that won’t be relevant for your current project. Where you do need a heading you should include it in your report (obviously enough) but then be careful to put only essential information in that section. Writing huge amounts of excessive information just makes unnecessary work for you in writing the report, and wastes the time of those poor people who must now plough through it all.

Managers with any experience value concise reports and won’t be at all impressed with unnecessarily lengthy ones. Provided that the report contains the required information, busy managers will be much more pleased with a short document than with a long one. If you’re new to projects and project management you may have assumed that writing a lengthy report demonstrates that you’re very conscientious and doing your job well, but actually it doesn’t.

Team Progress Report

This first reporting template is for reports from Team Managers to the Project Manager to inform him of progress in the current Work Package (assignment). The report should be produced at regular intervals, usually weekly.

Think carefully when setting up team progress reporting and don’t ask your Team Managers to provide information that you already have. One well-known project management method is very poor in this respect and in all progress reports it has sections for information that’s already readily available. That’s silly and just wastes everyone’s time. If you’re using a particular project approach, such as a method, alongside this book, be critical as you think through what information you’ll need … and what you won’t.

• Work Package ID: The Work Package that the team is currently working on.
• Date: The date of the progress report.
• Progress: Brief information on what has been achieved, such as the completion of particular sub-products in the Work Package and whether the work is on time or ahead or behind the schedule on the Stage Plan.
• Spend: If the team is spending money, a short account of what money has been spent and what has been committed (orders placed, for example).
• Staff resource: The detail of what time has been spent on the work will be in the next section. In this section the Team Manager can make any observations on the overall use of resource, such as that the team is working 10 per cent faster than expected and with fewer errors than anticipated. This will help the Project Manager with forward projections for the stage.
• Timesheets: Usually attached to the report, the specific information from team members on how much time they have spent on the different activities as listed in the Stage Plan.
• Outlook: The Team Manager can add any comments on the outlook for the next reporting period, usually the week ahead. For example that the work rate will increase because two team members will be back from annual leave.

Stage Progress Report

This report is for the Project Manager to tell the PSG about progress, but the report may be copied to others as well such as the Programme Manager if your project is part of a programme of projects.

The Stage Progress Report is produced at regular intervals, often monthly but the Communications Plan will record the PSG’s requirement for reporting. The report may be circulated before a Stage Progress Meeting, or provided in it and perhaps in the form of a business presentation with notes.

• Stage and report ID: Such as Stage 3, month 2.
• Date: The date of the report
• PM comments: The Project Manager’s comments on the running of the stage in the last reporting period.
• Delivery: Delivery of products in the stage compared with the delivery set down in the plan. Product delivery is a key progress indicator and you can show this graphically on a colour coded Work Flow Diagram. You can see an example of this diagram at the start of Section 3 in this book which covers planning, with shading representing the colours.
• Spending: A brief financial report on what has been spent, again compared with the plan.
• Outlook: The Project Manager’s assessment of how well work will progress in the next reporting period based on experience so far in the stage.

Dashboard reporting where you report information using graphs and things like ‘petrol gauge’ graphics is particularly effective for Stage Progress Reports. In my company, Inspirandum, I’ve devised a three page report using such things and including, importantly, the colour coded Work Flow Diagram to show product completion. I provide this report example in my governance briefings for senior staff in organisations because the measures I use are all factual and evidence-based even though managers can take in the graphical information at a glance; fantastic for really effective project governance.

Stage Completion Report

This report is prepared for the Stage Gate, the PSG meeting held at the end of each Delivery Stage. It may be circulated by the Project Manager beforehand or presented at the Stage Gate itself.

• Stage ID: Such as ‘Delivery Stage 6’.
• Report date: The date the report was compiled.
• PM’s comments: the Project Manager’s assessment on the stage, such as that it tracked very closely to plan or that there were many more Requests for Change than expected.
• Costs: The final cost of the stage, compared to the stage budget.
• Resources: The use of staff hours compared to those estimated in the Stage Plan.
• Quality: Confirmation that the required quality was delivered and a reminder of anything that failed to meet its quality requirements but a decision was made to accept that rather than spend more time and money.
• Stage Gate decision factors: In this section the Project manager should draw to the PSGs attention any factors that he thinks could affect the decision on whether or not to go on to the next stage. For example that the benefits projections in the Business Case are now stronger, or that the negative risk levels have risen considerably in the past stage. These factors will be included in other relevant documents, such as the Risk Log, but it’s extremely helpful to the PSG if the Project Manager (who is involved in the project day-to-day) draws attention to them.

Project Completion Report

• Project and date: The project name and the date of the report.
• Completion data: Final figures on cost, delivery date against the plan, team performance and achievement of quality.
• Initial benefits (if any): A lot of benefits won’t be seen clearly until after the end of the project and are then covered in the Project Evaluation Report. However if any benefits have come on stream at the end of the project, or even before the end, they can be measured now and reported now.
• Lessons: Things that may be of help to similar projects in the future.
• Project Manager’s comments: The Project Manager’s assessment (normally brief) on how the project went and how well it worked. He should not merely duplicate the lessons information from the previous section of the report, though.

Project Evaluation Report

This report is for after the end of the project when benefits have been assessed and measured, and you can also assess the suitability of project deliverables now that they have been in operational use for a while.

• Quantifiable benefits: A list of the benefits shown in the Business Case and for each
  • Expected benefits
  • Actual measured benefits
• Non-quantifiable benefits: A list of the non-measurable benefits as shown in the Business Case with an assessment for each as to whether it seems to have been achieved or not and whether that is as much as expected, the same or more. Have a look at the reminder below on non-quantifiables.
• Product effectiveness: an assessment of how well project deliverables have been in the first period of operational use.

Non-quantifiable benefits are, by definition, impossible to measure meaningfully. When reporting on them try to be as objective as possible and do your best not to either talk them up on the one hand or dismiss them on the other. It’s possible that you may be able to assemble and report some evidence, even though you can’t measure it reliably.

For example, you may have anecdotal evidence from a few regular customers that the new website delivered by the project is much easier to use. Perhaps a few retail outlets in the UK should take note of such evidence when they do an ‘improvement’ project and replace a great website with one that you can’t find your way around, let alone place an order.