How worthy are your status reports ? This is a question that every project manager should ask before he or she starts publishing them. Check the Dilbert above  It is well acknowledged , that a status report is a key tool to communicate information to your stakeholders. But these reports can go beyond than just communicating information.There are two kinds of status reports, one that the management recognizes as a reliable source of information for decision making and the other is just data that is archived or deleted. One common myth associated with status reports is that they are mundane and a non value add “deliverable”, one possible reason for this myth is due to the fact that often status reports are generated and published without putting much thought into them. They then turn out to be monotonous, non productive and time sucking “zombies”. These are the types which neither the publisher or the reader find informative.

Here are 5 key areas and 5 tips for making those mundane status reports more useful and effective.

The Content

The content on a status report has always been subject to debate. However a key driving factor that influences the content of your status report should be the type of the status report you are publishing. For example the content on a project status report would be different from is expected from a program or a portfolio status report. Similarly a QA status report would focus more on execution and would contain matrices around test execution.

Let’s look at three common status report examples.

• Project Status Reports – At minimum a status report for your project should contain the overall status of the project, along with the status on scope,schedule, and budget. The report should also contain the next steps or upcoming milestone or deliverable. Project specific risks and issues can also be induced in the project status report.

• Program Status Reports – A program status should focus on the over status of the program in relation to the organizations goal or vision which the program was initiated to enable. Risks and issues that affect the program will be part of the report. A high level status of the projects under the program will also be part of the program status report. However remember just concatenating all the project status reports under your program will not make up your program status report – Another common myth.

• Portfolio Status Reports – A portfolio status report on the other had would contain the health of the organizations or the departments investments on planned and on going initiatives. If generated correctly the portfolio status report will be used for prioritizing initiatives and / or allocating investment between initiatives within the portfolio.

Tip – It is often helpful to have baseline matrices and relevant qualitative data included in your status reports.

The Audience

I once recollect a few years back when I was a project manager on a project which rolled up to a program,for a couple of months I was not in the distribution list for the Program dashboard that was being published. While I might be at fault this, partially as I had failed to do my stakeholder analysis correctly. I kept on-course with my project time-lines and deliverable, whereas on the other hand the program had it invoked a risk mitigation plan to counter a schedule risk. The result – Though my project was all “GREEN” and on-track, it no longer aligned to the overall program’s vision. Needless to say that there was a lot of re-planning that followed. The point I am trying to make is that no matter how well you have captured your project or program status in your reports, it does a little until it gets published to the correct audience. Keep the audience for your status reports in mind when you conduct your stakeholder identification and analysis.

Tip – Refrain from including confidential information in your status reports. Always remember status reports are intended to have a wide audience.

The Format

There is no “one size fits all” when it comes to the format of the status report. The report should be crisp,clear and concise. Avoid the temptation of of rendering 3D graphics in your status reports, if you have that kind of an urge  . Again the driving factors here are the content, the audience and what the audience will use the status report for will determine the format of your status report. It makes sense reuse report templates from your organizations process assets, but make sure that the template can convey the information you want to publish. Do not sacrifice information to accommodated format – Common sense.

Tip –  Avoid creating status reports in a format that requires a special or patented software to be installed on your subscribers system.

Report Generation

In an ideal scenario the status reports generation should be automated. This has a two awesome benefits to this – One it adds credibility to the report and secondly you will not spend too much time or do end up doing rework for your status reports. The best kind of automation will include both generation of the reports and publishing it to its intended subscribers. Most enterprise project, program and portfolio management systems (EP3Ms) like HP’s PROPEL and Oracle’s Primavera allow you allow you this kind of automation. Investing time early on to get your team and stakeholders getting used to this is valuable.

Tip – Publish your status reports to a project wiki or a project content management system. This will also enable the chronological tracking of the status.

Consistency

There is perhaps nothing more frustrating to a stakeholder than inconsistency in the status reports. The inconsistency can be related to the format of the reports, the frequency on which the reports are published and even related to the legends and the color coding used on the reports. Unless the situation warrants it is critical to maintain this consistency in your status reports. In cases where you do need to have an exception, be sure to call out the reason for the exception within the report itself.

Tip – If you are publishing your reports on a weekly basis, be sure to publish your status reports at the last day of the week or the first working day of the following week.

What are your experiences with status reports? Do find them useful or do you see yourself in a Dilbert situation above ?