In Defense of Status Reports

Status reports have a bad reputation these days, conjuring up images of the useless boss in Office Space asking for the TPS reports. I’ve certainly seen status reports used more for obfuscation than communication and (mis)used in situations in which a meeting would make more sense. The push to ditch reports and replace them with more in person communication came from a justifiably frustrated place.

But sometimes I think we’ve over-corrected and ended up at the other extreme. After all, “in person communication” means meetings, and those aren’t exactly heralded as the pinnacle of productivity, either. Recently, a friend told me about a weekly meeting at his company that involves getting all of the team leads together (there are about 15 of them) and having each one give an update on his or her project. There’s no established format to these updates, and the meeting usually lasts between one and two hours. The team leads hate the meeting, and scheme to avoid it. The next rung of managers (i.e., the people to whom all the team leads report) use the meeting to keep up to date on the various projects, so that they can then report on them up to senior management.

This sounds like a dreadful waste of time to me. It could be replaced by a status reporting mechanism. For instance, each team lead could be responsible for writing a short (less than one page) weekly report, listing:

• Overall status (e.g, on track, at risk, blocked)
• 3-5 items that were accomplished
• 3-5 items that will be tackled next
• A brief explanation of why the project is at risk or blocked, if appropriate
• Requests for help from management (e.g.,this project can not complete XYZ until senior management decides on ABC)

I can tell you from experience that after a week or two, a good team lead can produce a report like that in less than 15 minutes, which is a lot better than sitting through a two hour meeting. I can also tell you from experience that it is possible to develop a culture in which status reports are read and taken seriously, because I’ve worked in such a culture. Senior management asked about missing reports and followed up on issues raised in the reports. They did not punish managers who honestly reported their projects to be at risk or blocked. Instead, they looked for ways to remove the blocks and mitigate the risks. In this environment, we junior managers made sure to produce high quality, accurate reports.

If a company really wants to allow all team leads to follow what is going on with all the other projects, these reports could be posted to a company intranet. Otherwise, they can just go to the relevant managers, who can then schedule more focused problem-solving meetings as needed or take other action to remove blocks.

A company that is committed to a “no status reports” culture could at least institute the above format or something similar for their weekly meetings, so that those would be shorter and more focused. They might then evolve towards sending their status in ahead of time, and just talking about the problem areas at the meeting- which would be a huge improvement.

Of course, I don’t think all meetings can or should be replaced by status reports. For the teams actually doing the hands on work, some sort of in person status meeting usually works better- either the daily scrum advocated by Agile processes, a more traditional weekly status meeting, or something in between. For the middle managers who need to track the status of multiple projects and dozens of people, though, status reporting can be more efficient than meetings for all involved.

Every situation is different, and therefore there should be no hard and fast rules for when to use a meeting and when to use a report, but my rule of thumb is: meetings are better for small groups of people (up to about 10) working on closely related projects, while status reports are better for aggregating information from large groups of people organized into multiple teams working on often quite disparate projects. In short, meetings are great for line managers who are shepherding the day to day work, but reports are better for the upper level managers who need to be operating at a less detailed level, monitoring status of multiple projects.

We have a tendency to believe in magic bullet management solutions. Just do X and all will be well! Unfortunately, work is more complex than that. The manager has to look at what really needs to be accomplished, and pick the management tool that will best fit that need, preferably with the least impact on the line managers and their teams who are actually doing the work. Don’t leave status reports out of your toolbox. They are not fashionable or flashy, but sometimes they are just the right tool for the job.