Avoid for project reportingA report or dashboard is only as good as the information it provides.  If it does not help the person reading the report, it will be seen as unhelpful and probably will not be used.  This means that it is a waste of time and effort for those reporting the report.  Likewise it creates the risk that important updates, calls to action, etc will be missed.

Below is a list of items to avoid when producing a project report or dashboard.

Acronyms

Every organisation has their own acronyms, the TLA’s and FLA’s (three letter and four letter acronyms).  This is absolutely fine when you have worked at an organisation for a while.  However, to someone new, they mean absolutely nothing.  So avoid using acronyms in the report or if you do, ensure you include the full description the first time you use it.

Technical Jargon

Many projects involve some form of technical change.  This can lead to updates using complex technical phrases within the update.  This is often confusing to non-technical stakeholders.  Therefore, always aim to use language that makes sense to non-technical readers.  Aim to write with the end user in mind.

Project Jargon

Similar to the point above.  When you are working on a project, it becomes natural to communicate using project references.  Remember that stakeholders to not have the same level of familiarity, many are not project professionals.  It is good to provide updates in the terms of outcomes / benefits as opposed to pure project deliveries.

Lengthy Updates

It is important to provide accurate updates.  However, this can result in a very lengthy (wordy) update.  This makes it difficult for readers to pick out the important points.  It can also discourage busy senior managers from reading the report all together.  Think about the important points that need to be communicated and then make sure that they are clear and concise.  Bullets can be very useful.  Imagine you only had 10 seconds, what would be the critical points you would want / need to communicate.

Data Overload

A project will naturally capture a lot of data.  Just because you are capturing the information does not mean it has to be included on the report.  A table full of numbers can be difficult to understand, especially if the report is being sent to recipients and not being talked to by the project or PMO manager.  Aim to only use summary data drawn from the detailed data tables.  Make sure the data presents a clear message that can be understood.

Font Size

To try and include as much detail as possible, the use of smaller font sizes may be considered.  While it does allow for more information on the page, it does get to a point where it is difficult to read.  Remember, this will be different for each individual.  Keeping above 10pt or 12pt is recommended (8pt for PowerPoint presentations).  This also helps ensure that updates are kept concise.

Mistakes

To be avoided at all costs.  A report will be devalued if it includes mistakes.  Remember, some readers will naturally pick-up data errors where as others will pick up spelling, grammar, etc.  Then there is misstated updates.  Always ensure that you spell check and proof read reports.  Where possible seek peer review before publishing.

Late Publication

After you have invested time in preparing a good report, don’t ruin the impact by publishing late.  If the report has a defined publication date, make sure it is met.  If the report will be reviewed at a meeting, aim to publish at least 24 hours (ideally 48 hours) ahead of the meeting.  This will give time for the report to be reviewed.

Conclusion

Avoiding the items listed above will help ensure that your reporting is in good shape and achieves the desired outcomes. This is important as a lot of time and effort goes into producing reports so the output must be valued.