We have produced a simple to use, best practice project summary report template for Microsoft Word. This is free to download using the link below. You are free to use this in your projects and for educational purposes but please do not resell the template itself for commercial gain.
The project status report is an essential tool to allow the Project Manager to communicate progress and project issues to the Project Sponsor, senior executives and other project stakeholders. Producing this report on a weekly, fortnightly or monthly basis will be a key task for the project manager.
For larger projects I recommend that the Project Manager asks each Work Package owner to use this template to report progress on the work package up to them.
If you have any questions about how best to use this template or if you would like to recommend any improvements for the next version, please leave a comment below.
The Management Summary
The template has a header and footer block which will automatically repeat on each page. In Word you can double click on the header to edit it. From there you can delete our logo and replace it with your own. You can also replace <TODO> with your project name and update the report date.
Many busy directors and managers will only have time to read the summary. They only want to know if the project is on track and on budget. Only if it’s running into problems are they likely to read the detail.
Within this section you need to give your project an overall BRAG status (Blue, Red, Amber, Green), state the budget which was signed off for the project, what has been committed to date and your latest estimate to complete the project. You should add a brief summary to explain if your are under or over budget.
Project summary by Work Package
In most projects of any decent size you can split them down into work packages (Epics if you follow Agile). These are packages of work which need to be done to deliver the overall project. In a building project you might have a work package for clearing the site, another for laying the foundations and another for the electrical first fit. It is helpful to track the status of each work package. If they all have a green or blue BRAG status then your overall project status is green.
If you report in the summary that your project has an Amber or Red status then people will want to look at which work packages are causing the problem.
Project Key Milestones
All projects should have some key milestone dates. For example, the date you expect to gain access to a building site, the date on which a website is expected to be delivered to the client for testing, or the date your new App is due to go live in the App Store.
Senior management and the project sponsors will want to know if these dates have been hit (Blue) are on track to be hit (Green) at risk (Amber) or now unreachable (Red)
A simple Gantt chart view
Our template includes a simple Gantt chart view. You can use this to show when key work packages are scheduled to happen and milestones are due to be hit. This is helpful for busy Exec’s who just want to quickly get a view of when work is due to happen. These views, and having a clear plan, also give the project sponsor confidence that the project is being well run. The Gantt chart view is also useful when talking about the project to sponsors and other key stakeholders.
The template has months from January to December, but you will want to change these to reflect when your project starts and the length of time it is expected to run. For example it may be more appropriate for a short project to have twelve columns for weeks rather than months.
Change Control Requests
One of the main reasons projects fail is the poor management of changes to scope or requirements. Whenever scope and requirements are allowed to change the project plan and budget have to be reconsidered. There should be a formal process for handling a Change Request, using a Change Request form. There also needs to be a formal process for reviewing new CR’s (Change Requests) and accepting or rejecting them. For example, they need to be logged by the Project Manager and discussed by the Project Board or Project Sponsor / Client. For those being accepted, there needs to be clear signoff and the impact on cost and timescales recorded. For those being rejected, the reasons need to be recorded and feedback given to the person who raised the request. SLA’s (Service Level Agreements) for the review of Change Requests are common. For example, all CR’s will be accepted or rejected within 10 working days.
Experienced Project Managers know that most of the cost (if you are the client) or Profit if you are the developer, comes from Change Requests (CR’s). It can be argued that the Agile methodology better allows for Change than traditional Waterfall projects, BUT ever in Agile the PM (Project Manager) should carefully manage new Epics and Features and scope creep on User Stories.
Risk Register
The last section is the Project Risk Register. The identification of risks and the management of those risks is a key responsibility of the Project Manager.
I have written some related blogs on project risk management which you will find helpful:
Managing Risks out of your project / risk mitigation
Summary
I hope you find this Microsoft Word Project Summary Report helpful. Above I have stepped through each of the sections. You should now download the Word template and try using it for your project. It is a tried and tested template but do feel free to adjust it for your project or to meet the needs of your client.
If you have questions or feedback, do please post a comment below.
Click here to download our free Microsoft Word Project Status Report Template.
We also have a Microsoft Powerpoint Project Summary Report Template.
0 Comments