A Guide to Writing Status Reports - I'm Not Joking, I Totally Wrote an Article About That
A Guide to Writing Status Reports - I'm Not Joking, I Totally Wrote an Article About That
Writing status reports has a bad reputation. Learn how they can be valuable, and a great tool for your toolbox.
Status reports have a bad rap. They're often listed as the quintessential example of a broken corporate culture.
"I spend more time writing my status report than doing my work." - Random corporate drone.
When done right, status reports add efficiency to an organization, and are valuable for both the writer, and the reader. They're not boring, they're not red-tape, and they're not useless.
When done poorly, they're demoralizing for the writer, and a micromanagement crutch for the reader.
I firmly believe that you can make a status report a valuable tool in your toolbox, and you'll unfortunately be able to say to others, "Oh, my status reports are outstanding!" — because it's just not cool to be the person who says that.
What should a status report be used for?
The name "status report" is pretty generic. It can mean a variety of things. However, if I had to boil it down to a single definition:
Regularly summarize important information for stakeholders about a project or product.
Regularly
A one-off status report is usually a waste of time. Setting up a report takes a significant effort. You need to get a list of the stakeholders, figure out what they specifically care about, and format the information in a readable format. It is rarely worthwhile to do this once, and then toss it away.
A status report should be a regular part of your process. This means setting up the report to be efficient to recreate regularly. One key I found to be useful is to set up my status report in a way that it's easy to update from source data. For example, if I had a recruiting section in a status report, it would match the format of the source report from our recruiting tool. You're less likely to make mistakes if your report is automated, or at least easy to generate.
As for cadence, that depends on your stakeholders, and how fast your project or product is changing. If you're 5 days from launch, and you're on the edge of not making it, you probably need a daily status report. If you're 9 months from launch and things are slowly chugging away, a weekly report likely makes more sense.
Summarize
Everyone is busy. The purpose of reports in general is to synthesize (combine) information into a digestible format. Imagine a project team of 25 people. If all 25 people wrote up everything they did in a week, it would be a massive amount of text. You'd have to spend your week reading, to simply keep up with everything they're doing.
The only way people can keep up to date on the things they care about is through summaries. The goal of a summary is to carefully pick through all the things in motion, and create an easy-to-read version which enables someone to get the information they require efficiently.
If you think your status report is a pointless task, not useful, or busywork, you'll likely do a poor job at this. If you own a status report, make the thing useful!
Assuming you think the status report is useful, your job is to ensure that it is read by your stakeholders. How do you do that? Summarize. Almost anyone will read a 5 line status report. Almost no one will read a 250 line status report.