Producing better reports is the cornerstone of climbing the ladder of corporate success. If you work in any corporate environment, then most probably you have to deal with (write but also read) lots of reports. This activity has become so common that we sometimes neglect the importance of quality and we feel like we don’t need to invest time in the process unless there are issues.
This article will present a better way of doing reports, concentrated on better planning, better execution, and more value delivered to the readers. First of all, use it for reference for your own reports. But also, use it for insights about improving the reports you are reading. The tips will be useful for any type of report but I will mostly concentrate on project status reports and use this for all examples.
Time to read: 10 minutes (150 wpm).
Your first step is always to determine the audience of the report and the requirements of the audience. This will usually also determine the type of the report. These are a few examples to consider:
The best way to determine and analyze your audience is with avatars. Imagine specific people reading the communication and anticipate their requirements. If possible, show a draft to them and ask them for feedback. In any case, be prepared to take feedback positively after the first few iterations. Remember that the report is FOR the audience, not for you.
Obviously, the building blocks depend on the type of the report and its goal. Below, I have listed a few important blocks that are part of most reports.
You will most probably send the report over email. In order to facilitate readers, pick an informative subject and stick to it. Thus, some readers can create email filters to move the emails to a folder and read them later. Consider appending the date of the report and any other dynamic content at the end.
The header contains title, logo, date, status, and important links (project info page, information about how to subscribe and unsubscribe). Do not underestimate the logo because many people are visual and it will help them identify the report within milliseconds. I also prefer adding flags for regional projects and/or launches (e.g. EU flag or US flag) for visual aid.
These are a few lines that summarize the contents. Do not assume that top-level leadership will read beyond this part. So anything that aims to capture their attention should be here.
I usually put it right after the Executive Summary for the first few issues and then I move it to the end. Here, I describe what the project is about and its goals.
Immediately after that I answer the question “so what?” Why are we doing this project or program. Why should the reader care about this project?
This section contains a list of all currently open risks. With mitigation steps, status, owners, and deadline. This is probably the second most important block. After the readers read the news about the project (executive summary), they want to know what issues does the project face. Along with that, they need to know who owns the issues, what he or she does about that, and by when they will see results.
This is the last of the important blocks. This part lists all milestones and deliverables with due dates, owners and status. This is the path ahead for the project and gives information about what comes next.
The granularity depends on the audience but I would advise you to go beyond code complete and QA complete and add the actual high-level tasks.
This section informs the reader whom they could contact with questions – the business owners, the tech owners, the lead team members. Use emails, aliases, mailto links, anything to make it faster for the reader.
The References section contains general information – date of next report, link to the information page.
Think of the report as a website – some people will view it on their 13” laptops, others will view it on their 22” monitors, and a third group will use their mobile devices. This means that a better report appears equally readable on all of those. The only way to assure that is to plan and test accordingly.
A few tips that I have gathered:
Choose a cadence, day of the week, and time for the report. This again depends on your audience. And stick to these for a while. Make sure you send the report exactly on the chosen day and roughly at the same time (+/- half an hour). Your stakeholders will learn to anticipate the report around the time when it is supposed to come.
If you absolutely have to delay the report because you need to review it again and change it, still send it on the day you are supposed to send it. The status report represents a snapshot in time. Anything that happens after or around that time can be presented in the next issue.
A weekly status report is just what it says – a report that describes the current state of the project at a given time. Make sure you know the type of your report and only add the relevant information.
These are a few sections that DO NOT belong in a weekly status report:
There are also a few items that you can prepare to make everybody’s life easier and link them in your better reports:
Using status reports properly can be a powerful communication tool for engaging with the stakeholders of a project. The better reports can have many shapes and usually differ depending on the audience. But there are some general tips that are valid for most cases.
Feel free to use the information in this article to review and improve the way you are preparing your reports. Or even to help improve the one you receive as a stakeholder.
Originally published at www.fromgnometogoliath.com