Project Status Reporting
Overview of Project Status Reports
What should be included in a weekly project status report? This is a question to which there is no right answer. It depends on a number of things. The size of the project; the criticality; the corporate culture; the organisational structure. Hopefully, this white paper will answer some of the questions and will give you guidance to solve the rest in your own environment.
Project Status Reports Criteria
A starting point is to look at what are the important things in a project. It will vary project to project but here are a few typical criteria for project reporting.
- Schedule. How is the project progressing against the schedule
- Budget. How is the project progressing against budget
- Risks. What risks have been identified and how are they being
managed - Issues. What new issues have arisen and how are they being managed
I have also seen the following covered in a weekly status report
- Communication. How is the project communicating with stakeholders
- Quality Management. Statistics on how quality is progressing on the project. For example lost man days due to injury and defects identified in testing
- Resources. How much time certain resources are spending on the project
- Benefit delivery. Any anticipated changes to the benefits the project will delivery
- Glossary changes. Any new terms added to the project glossary
- Project Team Members movements. Where particular project team members will be over the reporting period
- Meeting Schedule. Meetings scheduled over the coming period
As you can see, a project status report can become a book in itself if you let it. Some culling is required or the Project Manager will never get anything done because all the time is taken up producing reports.
Project Report Timing
Another question is how frequent should a report be produced. For most projects, the frequency is weekly or fortnightly. If the project is very small, a monthly report may be warranted, but a lot can happen in a month and the purpose of a report is to keep stakeholders informed. Most projects aim for a weekly status report.
Another tip regarding timing is to not automatically make the report on a Friday. For a start, if all projects report on Friday, the report will go on a pile of other reports and may not get the attention it should. Of course, if you don’t want someone to read it….. but we won’t go there.
If a Project Office is organising reports, it is better to spread them over a week unless some consolidation of information across projects, at a single point in time is required. Project 1 on Mondays, Project 2 on Tuesday, etc.
Project Status Report Focus
Another key point is to make the focus the exceptions. Don’t spend pages saying everything is going to plan. The point of the report is to get attention focused on the bits that are not going to plan. The status report should be an exception report. It should bring the spotlight onto the issues the project team want the readers to focus on. This of course implies that the report will be short and succinct. The next few sections cover what might be in a weekly status report.
Reporting against Schedule
What is the reader interested in hearing about the schedule? The progress against the schedule is essentially the progress against milestones. There are basically three questions that need to be answered.
- Did the project achieve the milestones due since the last report?
- What milestones are due before the next report?
- Has anything happened that will impact the final delivery date?
So, the report needs to list the milestones due since the last report (including any that were outstanding at the last report) and identify if they were met or not. It then needs to list the milestones due before the next report.
To address the third point, if there is a change to the final delivery date, it needs to be identified and explained. If everything is still on track, there is no need to make mention.
Reporting against Budget
I tend to take the view that budget should not be included in the weekly status report. For a start, it may not be appropriate for everyone who sees the weekly report to know the financial situation. There is also the issue of timeliness of reporting. Often the budget is only reconciled once a month due to reporting limitations from the general ledger system. My suggestion is that reporting is done monthly as a separate report to a subset of those who receive the Weekly Project Status Report.
We have a separate white paper on project budget and expenditure for those interested. The key point is that reporting percentage of budget used to date is meaningless. You need to establish a cash flow at the start of the project and report against that projection. Typically, the start of the project uses up only a small portion of the money and the main expenditure comes later.
Reporting should include:
- Budget to date
- Expenditure to date
- Accrued expenditure
- Expected total expenditure including scope changes or variations
- Explanation of how this varies from the total budget
- Any likely variations to the cash flow
Another section could show:
- Value of scope changes proposed
- Value of scope changes approved
- Value of scope changes pending
All of the above figures should clearly identify if any of the parameters have changed from the previous report. Something as simple as highlighting changed figures is quite adequate.
Reporting Risks
Risks are another area that may be best handled by a separate report. If a regular risk review is carried out during the project, the new risk register may be circulated separately with new or changed risks identified.
My view is that only significant new risks should be mentioned in the weekly report in a comments section. For example:
“New Risk
A new risk was identified in that the project will face significant delays if supplier ABC cannot meet the deadline for delivery. We believe the impact of such a risk is high and the probability is medium. In order to reduce the risk, we are offering the supplier a bonus payment if the delivery is on, or ahead of schedule. For more information, see our risk register – risk number 42”
Reporting Issues
Wading through a list of issues is both mind-numbing and not likely to get attention. In any case, it is not so much the issue that is important. It is what you are doing about it. Each issue is a problem. To resolve that issue you need to undertake one or more actions. An action is:
- Someone
- Has to do something
- By a certain date
The reader of the report is probably interested in three components.
- What are any major new issues and what are you doing about it?
- Are there any action items due or overdue?
- What action items are due in the next reporting period?
New major issues can be handled in the same manner as risks. Include information in the comments. Not all issues are worthy of the exception reporting approach as they may very well be under control and not need to be circulated for general information. Remember the exception reporting. For example, if there was an issue raised regarding the availability of a certain key person, and you are confidently working to get their participation confirmed, it probably doesn’t warrant a mention in a project status report.
Other Reporting
For the vast majority of projects, anything else is superfluous. It is nice to have lists of meetings etc, but should you really include them in a weekly status report? Probably not if you want to follow the exception reporting approach. If your organisation does insist on additional details, I suggest you look to a separate monthly report with the financial information.
Project Information Repository
If you are pulling all this information together on a weekly basis, it makes sense to have the information in a format that lends itself to quickly extracting the key details. One approach of course is to use a tool such as the Project Perfect Project Administrator (PA) software. PA will generate a report automatically for you. If you don’t have access to such a tool, you need to set up spreadsheets and documents that can be easily cut and pasted into a report. You don’t want to re-key existing information into a report template.
Typical Report
The sample below is generated from Project Administrator but you can easily make a report template that looks the same. As you can see, there are no milestones overdue. Those in the last period were completed on schedule. Also, there are no action items overdue.
Conclusion
I have often said to people that the value of a weekly report is not in the information it contains. It is in the preparation. If once a week a project team have to produce a status report it focuses the team on ensuring things are up to date. It makes them review milestones and action items and address any outstanding tasks. Nobody wants to produce a report showing things overdue.
| On one occasion, whilst managing a group of projects, I had one of my project managers tell me that the first thing he did when he came in on Fridays was to run the weekly report from Project Administrator. He knew the report had to be sent to me by close of business that day. He then spent the next few hours chasing people to get things completed by 5:00 pm. He told me that he usually cleaned up five or six items each Friday that wouldn’t have gotten his attention otherwise. |
Any piece of paper that generates action is better than a piece of paper that takes time to read yet does not result in any activity. You might even ask why the latter should be produced at all but unfortunately, most paper falls into the latter group. A project status report should be a piece of “action” paper. Keep this in mind when you report on your project.
Copyright Project Perfect