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
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.
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.
Step 2: Building blocks of better reports
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.
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.
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?
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.
A few tips that I have gathered:
- 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.
These are a few sections that DO NOT belong in a weekly status report:
- 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
There are also a few items that you can prepare to make everybody’s life easier and link them in your better reports:
- 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
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