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.
This is a really intriguing idea to me. I’ve not asked my staff for status reports because I don’t want to waste time, but I’m worried we end up wasting more time in meetings instead.
You can always try asking them which method they’d prefer!
(Sorry for the delay in approving your comment- it was stuck in moderation but I didn’t get the usual email.)
[…] year, I wrote a post defending status reports. Now it is time to defend […]
[…] what I do when I run a project. I’ve been picking off some aspects- how to slip a schedule, how to write a status report, etc- and I have also identified some things you have to think about no matter what type of project […]
[…] a manager and about the benefits of transparency for Chronicle Vitae, and I’ve written here in defense of status reports and about how meetings don’t have to suck. I don’t think I’ve ever written about […]
“We have a tendency to believe in magic bullet management solutions”
Yes! This comment really resonated with me. Instead of magic bullets, how about some common sense. Of course regular reports are useful, there a good way to communicate about progress but also sometimes you need to get together to talk about progress …