We’ve posted tips about targeted communication – tailoring the message for the audience. Anthony Mersino has an excellent post from January of this year about how to write a good status report. He provides seven excellent guidelines for status reporting, and all of them around providing the message our audience cares about, as effectively as possible.
Status Reports are important
Good teams can work around a project manager who doesn’t communicate effectively. They just bypass the problem and communicate with each other. But a project with poor outbound communication is doomed. Outbound communication is communication from the operational team to the client, stakeholders, management, other departments, etc.
As product managers, we spend most of our time focused on what things need to be done. We risk forgetting about the actual doing of those things. Sometimes we’re in an organization where we aren’t directly involved in the execution of the plan. In that situation, we are consumers of status reports from the program and project managers who are making our visions into reality.
If we aren’t providing status reports, we’re receiving them. Either way, we want them to be great. Specifically, we want them to be targeted, accurate, and easy to quickly absorb. We also want the reports to make it easy for the reader to get more information when she needs it, and know when she doesn’t need more information.
The reader of a status report is asking two questions. Our status report needs to answer them.
Will you meet your commitments?
If not, how can I help?
Our favorite tips
Three of Anthony’s tips hit the bullseye for us.
- Write for the reader, not the writer (#2)
- High signal to noise ratio (#6)
- Communicate status against the plan (#7)
Write for the reader, not the writer
Anthony tells us
Add value with a message that is clear, shows the way, and guides the reader on whether to take immediate action, begin to worry, or relax and let you do your job.
(photo courtesy of Katina Kober)
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.]
Be careful not to be a hero, chicken-little or pollyanna.
No interesting project happens exactly to plan. When the team is dealing with chaos, change and uncertainty, we have to make a judgement call. Is this something we’re capable of resolving, or do we need to bring in the big guns? If we need help, we have to ask for it. That’s why status reports were created. Top-down organizations empower their teams to make stuff happen. They use status reports to mitigate the risk that something will go wrong. When something does go wrong, they can fix it, or at least minimize the pain.
Don’t flag everything as yellow (unless it is). These are the warning signals to our audience that something might go wrong, but hasn’t yet. Every warning in the status report requires our reader to get more details. These are problems that are “at our capacity” – we need to be able to deal with them. But we also need to communicate the risk that we can’t. Most readers will react to yellow items by making a note to followup (so make sure we follow up!). They might look for more information (so provide it), to validate that they don’t need to be involved yet.
If everything is green even if it shouldn’t be, we destroy the power of our communication vehicle, and damage our credibility. The reader of the status report needs to know that green means “at least as good as expected/promised.” Our audience needs to be able to ignore the green stuff when she’s swamped with other urgent problems.
High signal to noise ratio
Report on only the most important stuff. Write brief, scannable information. Bulleted lists and hierarchical presentation of information are great techniques to use. Break the report up into sections. The sections could be functional breakouts, or product-area summaries. Start with a summary, end with the same summary. On ratios, think about it in terms of time.
- 10 minutes. The reader of the status report should know what it says after no more than 10 minutes of looking at it.
- 2 hours. A report should take no more than a couple hours to pull together, when we are tapped in to whats happening on the project. We already know the important information – the time is spent organizing and filtering. If each draft is shorter than the previous one, we’re on the right track.
- 200 hours. We should spend about an hour to summarize no less than 100 hours of project work. A weekly status report for a team of 5 represents 1% overhead, and takes 10 minutes (under 1% of the reader’s time) to read. A period of more than two weeks per report loses the sense of immediacy and urgency that would be required to actually fix something that is broken. And that’s the whole point – to allow our audience to respond to problems, and plan for change. If the problem happened three weeks ago it better already be addressed by the time the report is written.
Communicate status against the plan
The red/yellow/green metaphor works best when it presents status in context. When the reader of the status report approved our product development plan, or our release schedule, that created the context. Will we meet our commitments? That’s the main message. Tracking against the plan can also make it easier to write the status report.
[Update 2006-10-01: Reporting progress against a set of deliverables can be accomplished very effectively with a burndown graph.]
Summary
The reader of a status report is asking two questions. Our status report needs to answer them.
Will you meet your commitments?
If not, how can I help?
