An effective status report is not a myth, it is actually easy to achieve.

Goals of a Status Report

You do not create a status report because someone told you to create them. You create a status report only when it benefits the project. There are three effective uses of a status report:

Get help (escalating) when you need help.

Keep stakeholders in the loop so there are no surprises.

Get visibility for the accomplishments of the people on your team.

Problems of a Status Report

There are also potential downsides of creating status reports. This doesn’t mean you should avoid creating a status report. It means you should avoid status report mistakes.

A bad status report takes a lot of energy (and time) to write, making it expensive.

A bad status report is difficult to read, causing it to fail to communicate.

A bad status report covers up problems or cries “Wolf!” when things are under control.

Elements of an Effective Status Report

The following is one example of an effective status report format. Other formats can work. This one does. We’ve been using it for months on multiple projects, with great success. On one of our projects, the first status report in this format was forwarded around by the project sponsor for people to “check this out!” Ever hear of that happening to one of your status reports before? In a good way?

There are five components in this status report format.

The scannable forecast.

Last week’s accomplishments.

This week’s planned accomplishments.

Issues and resolutions.

The legend.

The Legend

Normally, we run through a list in order. In this case, we will show the last section first. The legend explains how to read the first section, the scannable forecast.

You can define any number of different statuses for a project. “Red, Yellow, Green” is the most common. A couple years ago, we proposed this metaphor for status reporting:

A great way to do this is with a stoplight metaphor (at least in the US, where green = go, yellow = caution, red = stop). We can provide a little color in our reports to make the status details and rollup easy to scan. When someone is the audience of a status report, its because the reader needs to know what is going on, but isn’t involved – and likely is reading status reports from other teams. We need to present a document that gives a quick visual that guides the reader to pay attention to the most critical elements.

Red. Immediate action (by the reader) is required to fix this.

Yellow. We’re at risk of failing to meet expectations. There’s a plan in place, but we thought you should know. Want to know more?

Green. Meeting or exceeding the plan. No need to spend cycles on this one.

It works, but it isn’t great. You’ve all seen it, because it is adequate. However, using red, yellow, and green to provide a scannable status can be confusing – even if your readers aren’t colorblind. Does red mean the project is delayed? Yellow usually means a project is at risk. But is it “at risk, help is needed” or “at risk, FYI, help is not needed.” That’s part of why we recommended the weather forecasting metaphor. Thanks again to Johanna Rothman for originally sharing the idea.

The Scannable Forecast

When you look at the above, even without knowing any details you know:

The project is in worse shape this week than it was last week.

The project will get worse before it gets better.

The team has it under control, today, but might need help next week.

Last Week’s Accomplishments

The bulleted list is extremely effective for scannable details. The secret – use three to five bullets. More bullets means you’re sharing too much, and fewer than three is not enough. You’re reporting to a project sponsor who has placed trust in you to manage the details. Your sponsor, when things are sunny may not even read the details, just relying on you to say “everything is great.” The only time that you need to share more details is when things are stormy. And those details (1) will come up in the issues section, and (2) will come up in conversation.

When someone on your team does something noteworthy, dedicate one of your bullets to that accomplishment. If you have a dozen of these, then refine your definition of noteworthy. You should already be providing feedback to your team about their work. Noteworthy accomplishments should be broadcast up the chain. Its a reward for their hard work. Don’t under-report, and don’t over-report. The people who consistently do great things will begin to get a positive reputation where it counts. As a bonus, you will get acknowledgment for being a good manager.

This Week’s Planned Accomplishments

This is what you intend to do in the next week. When your project sponsor does want to get a little more insight, perhaps to make sure that she believes that you will resolve things, she will read these details. Again – a three to five item bulleted list is appropriate.

Issues And Resolutions

You report issues when you are (or anticipate being) cloudy or stormy. You don’t waste your sponsor’s time on trivial issues that you can resolve on your own. These are issues that either definitely require escalation, or may require escalation. Again, you’re working a three to five item list. On your project, you will potentially manage ten times as many risks, and you could track them in a spreadsheet, etc. Those are the issues you are working. These are the issues you need help to resolve. And only the issues you need help to resolve.

Note that this isn’t just an issues section – it is issues and resolutions. When you inform a stakeholder that you need help with a problem, the first thing you need to do is propose a solution. Imagine the following exchange:

“I need help” – “What do you need?” – “I need you to ….”

Much better than

“I need help” – “What do you need?” – “I don’t know. I need help determining what I need.” – “I know what you need, you need help updating your resume.”

For every issue, propose a solution.

The issue section is also not meant to be a standalone document. Here’s another bad exchange:

“I need help” – a couple days go by – “I solved your problem for you. And I’m replacing you with someone I can rely on.”

Your project sponsor shouldn’t have to ask what you need her to do. She should, however, want to know why you think the proposed solution is best – and you should talk to her about it, not present a rationale within your status report.

Practical Experience

I’ve created many status reports using this format. They take anywhere from 15 minutes to 45 minutes, almost always under 30 minutes. When they did take any significant time, almost all of that time was spent in thinking about the content to report in the “Planned Accomplishments” section. And that is not time that I spent writing a status report – it is time I spent planning, on those occasions where I procrastinated in my planning, and the writing of the status report triggered a brief planning exercise.

Brevity in a report goes a long way. As does regular face-to-face (or at least phone-to-phone) conversation. A status report alone better not be the only way you communicate. It should be a light-weight artifact that (1) starts the important conversations, (2) preempts the time-wasting conversations, and (3) provides an archive that you can review later, to see the full arc of the project, gain insights, and run your next project even more effectively.

Post navigation

12 thoughts on “Effective Status Reports”

Good post and great set of pictures to display status.
One thing that I have seen missing from many statusreports is the possibility for people to express how they are feeling. This for me is an important measure – if people don’t feel positive (which is sometimes easier to detect first for someone than specific issues) – it often points to certain things that might be risky or negative.
I use a simple scale :-( 1 2 3 4 5 :-) (but inspired by this article should probably think of some smiley faces vs sad/angry!)

I agree with you about the importance of maintaining morale / excitement, and addressing dissatisfaction. I’ve never seen that handled via a status report before, and personally, I’ve always addressed that in one-on-one conversations.

Can you tell us a bit about how the dynamics of informing / expressing work for you in status reports? I’ve always assumed (I know, that’s never good) that people would be uncomfortable expressing their concerns if they were being publicized. One thought would be an aggregated “team is content” or “team is fired-up” status.

This is a fairly comprehensive article on the subject. The weather idea is interesting. I think what would’ve been nice in this article was to probably add as section about the resources involvement in the status report, and how will the PM react to all the resources’ optimism.

If I’m understanding what both you and Roeland are saying, there is a glaring absence of info about “how the team is doing.” Great point. To date, I’ve always handled that communication ad-hoc and as needed (like when things are stormy). I’ve also had few senior managers proactively ask me about how my team is doing on an ongoing basis. Those conversations have always been (when initiated from above) at/before review time, or during ad-hoc “time to see how everyone’s doing” exercises. I definitely haven’t supported folks who wanted that information in the context of a project – so it never occurred to me to include it in this status report.

I’d love to hear more from y’all (and others!) about your experiences. This may be a great opportunity to incorporate that info and educate the readers both about the status and the importance of knowing it. So chime in!

Quite refreshing and to the point, and best part it make you read. Though the nature of report is mundane, but important we sometime lose track on how to and what to communicate, and just keep on adding details, which might not be needed at that point.

@sehlhorst on Twitter

Who Should Read Tyner Blain?

These articles are written primarily for product managers. Everyone trying to create great products can find something of use to them here. Hopefully they are helping you with thinking, doing, and learning. Welcome aboard!