Better Reports – How to Take Business Communication to the Next Level

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

Time to read: 10 minutes (150 wpm).

Step 1: Determine the audience

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:

• Tech status report – usually the audience is the tech leadership and the goal is to report the status of the tech deliverables and upcoming milestones.
• Business flash – the audience is the business leaders and they want to see the overall status but also metrics, progress against the goal, and high-level risks.
• Launch announcement – the audience is broader and the goal is to announce the launch of a new product or enhancement.
• Escalation – should be separate from the status report and provide information for a blocker. The audience is usually the decision-makers who can help unblock the project and/or solve the problem.
• Raising awareness – this is a communication that aims to educate the audience about a risk, an issue, or in general a problem. It is not necessary for the audience to solve a problem or take action.
• Personal achievements – this is a report that you send to your direct manager in order to share with them your achievements in the past week/month/quarter. An example can be found here: How to Approach a New Direct Manager.

Step 2: Building blocks of better reports

Subject and header

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.

Executive Summary

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.

• Use bold, italic, underline, highlight to capture attention.
• Explanation should be as brief as possible – do not make it lengthy.
• Do not contradict what you wrote here later on.
• Review and rewrite sections as many times as you need to reach the least amount of words that convey the message (given you have enough time).

Project Information

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.

Risks

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.

Milestones

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.

Contacts and References

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.

Step 3: Format the better reports

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.

• Text paragraphs appear well on all devices.
• If you want to include tables, make them simple – some rows with very few columns (3-5).
• Paste complicated tables as pictures to improve scaling.
• Make the header of the email a table with no borders, this will help scale appropriately on all views.
• Test, test, test. Print the email to make sure that printing is also possible and looks OK.

Step 4: Time the better reports

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.

Step 5: Determine the content of the better reports

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.

• Escalations – you can call them out (“yesterday, we escalated to leadership that risk xyz is red and is blocking the abc deliverable”) but the escalation itself does not belong here.
• Polling the audience and asking them questions – the status report is a push one-way communication, you cannot expect the audience to answer random questions in it.
• Call to action – you can also not expect that certain stakeholders will do somethin based on what the report says.

Step 6: Add supporting artifacts

• PDF version of the report. Export the email or the text editor file that you have used. Store the PDF in a shared location and make it accessible to everybody. This becomes your project’s history.
• Project information page – a wiki page that describes your project.
• Status mailing list – in order to avoid the clutter, I always have a status mailing list where I keep the main stakeholders. I usually send my better reports with this list in the To field.
• Interest mailing list – another list where anybody can subscribe. I usually keep that list in Bcc.
• Shared location of project-specific files – charter, requirements, project plan.

Summary