It’s been 7 months since I wrote my last weekly status report.

It feels so freeing to say that. 7 months! 🙂

Have you ever seen one of these things? Here’s what we did this week, here’s what we’ll do next week, the project is red/green/yellow (oh, my).…

Status reports where I have worked have always been a murky combination of facts, speculation, and hope. A true crime story that’s written mid-investigation.

And the speculation is amplified when you have multiple layers of report contributors. Often, the front line manager sends a report to the middle manager, who adds to it or refines it, who then sends it to an upper manager. At more than one company I’ve had to write end of week status reports on Wednesdays just so it would make it to the person it needed to get to by Friday.

Huh?

It’s easy to see how we have so many watermelon projects in our industry. You know, green on the outside but red if you look inside.

Why do we do this to ourselves?

Status reports give well-intentioned managers a sense of security and control. They can “know” what’s going on in just a few short bullet points, without ever interacting with the people doing the work.

Though it’s certainly felt like it, in my experience people do not demand status reports as some form of punishment. They ask because they really have no idea how a project is progressing. The work isn’t visible.

“But I need to know where we are!”

I’ll largely ignore that nearly every status report I’ve read was stale and/or misleading, meaning we don’t know where we are anyway. The report is all theatrics. A reenactment to make it appear that we have a grasp on status.

I’ll offer an alternative.

Do you want to know the status of a project? Look at the backlog. Look at the cumulative flow diagram. Most importantly attend the demos and play with the product for yourself. These artifacts are cheaper and easier to produce than a handwritten report, and they’re always correct.

Let’s dig a little deeper into how this would replace a status report.

I’m a huge fan of cumulative flow diagrams, also known as a juiced burnup chart. In one glance you can see the rate that items are being completed vs being added. This alone gives you a more accurate picture of “where we are” than any stories told in a status report.

But that’s just the start of CFDs.

You can quickly see where items are stacking up. Maybe the queue for development is growing faster than the testing queue. Something is slowing work down in that phase. Perhaps the environments are flaky, or the team is getting dragged into too many meetings, or someone keeps taking the teams chairs because there aren’t enough in one of the meeting rooms (all real stories).

The CFD will not tell you what that problem is, but it will tell you that it’s time to get up and talk to the team.

When something doesn’t look right, have a discussion. That’s right, walk over to the team and ask questions. Offer your help. Unblock them. Give them cover so they can focus. Chain their chairs to the desk.

“But this all takes time!”

Yup, probably. If things aren’t going perfectly, this is absolutely more time consuming than having an email plopped in your inbox. But we need to look a the full cycle time and avoid optimizing a local problem.

The whole point of a status report is to raise awareness of current conditions and improve the team’s ability to perform. Seeing problems early and working with teams to remove blockers means faster delivery overall, which is really what matters most.

Update 11/4/19

Matt Ashbourne had an insightful comment on this post. In most larger organizations each group will have their own status report charade. So there may be reports produced by product, engineering, and qa. As if it wasn’t bad enough to get one incorrect view of what’s going on, you now have multiple incorrect views, all influenced by their own biases.

Though I have had managers tell me they liked this process because they could see if the “stories match up” – hows that for dysfunction?