Effective Status Reports

An effective status report is one that

• Instantly conveys the state of the project.
• Creates a minimum of overhead for the project team.
• Gets you help when you need it, and latitude when you don’t.
• Is fun / energizing to the author and the readers.

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:

1. Get help (escalating) when you need help.
2. Keep stakeholders in the loop so there are no surprises.
3. 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.

1. A bad status report takes a lot of energy (and time) to write, making it expensive.
2. A bad status report is difficult to read, causing it to fail to communicate.
3. 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.

1. The scannable forecast.
2. Last week’s accomplishments.
3. This week’s planned accomplishments.
4. Issues and resolutions.
5. 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.

[Update 28 Apr 2007: We have a much improved metaphor for tracking project status – weather forecasting.]

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:

1. The project is in worse shape this week than it was last week.
2. The project will get worse before it gets better.
3. 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.