The Unbearable Uselessness of Progress Reports

No one loves progress (status) reports. They take time to write. The writers believe they’re unread.[1] And as one wag put it, they mostly demonstrate the lack of progress.

The problem with these reports is twofold. One aspect, of course, is that the intended recipients are busy. The other is that the reports contain little to no information the recipient can act on, other than perhaps taking frustrations out on the project team.

Consider the sign pictured here, on one of the floating bridges across the lake into Seattle. It tells me what I’m about to be charged for crossing the bridge. My son took the picture the other day as we headed across the lake.[2]

Click image to enlarge.

Click image to enlarge.

Now think about the location of this sign.

It’s on the bridge.

It’s on the bridge that I am already crossing, already committed to. It’s not visible from any point at which I have a choice on whether to take this bridge or the free bridge a few miles south.

In other words, it’s a typical progress report, telling me an interesting fact, but not giving me information I can do anything with.

What Happens on the Receiving End?

As a business leader, I’ve been on the receiving end of innumerable status reports as well, almost all of them unrequested. Looking back, I had the following responses:

  1. Ignore it (about 60% of the time)
  2. Skim it and hope something jumps out at me (10%)
  3. Read through it in detail (10%)
  4. Look for some element that doesn’t feel right and question the project manager about it (20%)

Admittedly, I’m guessing on the percentages, but they’re in the ballpark. It might be useful to understand why I responded as I did.

Ignored it, for one of two reasons: First, I was busy. Reading these reports was a low-value use of my time, since they contained no “to-do” items. Second, if anything interesting had happened since the last status report, someone on either my own team or the project team would have notified me directly.

Skimmed it mostly out of a sense of obligation, because smart people had spent valuable time putting it together. In retrospect, this response falls into the category of “throwing good money after bad.” Were I still running a corporate department, I’d probably read only the first status report on a project to get a sense of the kind of information it contained, and then I’d create an Outlook rule to auto-file future reports.

Read it through for one of two reasons: When I received the initial report on a new project (or with a new project manager), as noted above, I’d peruse it. Second, if I knew the project was in trouble, I’d read it to see how the project team was disseminating (or lying about fudging) the bad news. (I’d get the real updates from my team or by speaking directly with the project manager.)

Nitpick Question a detail: Again, two reasons. With a new-to-me project manager, I’d dig into one area and grill the project manager on it, looking to see if she had a deep understanding of the project, project management in general, and risk management in particular. I’d push hard enough to get to some minor detail that she didn’t know about to be sure she would say, “I don’t know, but I’ll find out.” (And then I’d thank her and explain why I’d pushed so hard, in part to reduce the chance she’d think that what I really wanted was even more detailed status reports.) And sometimes, especially with a project that wasn’t going as well as I thought it should, I’d work hard to get at what was wrong, using whatever detail I’d picked up as a jumping-off point.

Did I ever receive new information from a status report? Of course.

Did I ever receive valuable new information from a status report, information I wouldn’t have gotten had I not read the thing, information that changed my next move as the project customer/client? I honestly don’t recall that ever happening. I was not a micromanager (I’d learned, finally, to stop doing that), but I did have strong teams in whom I placed great trust, and that trust was repaid by their staying on top of projects. (I also usually had back-channels to people on the project team, which gave me additional access to information. I didn’t develop these in order to go around the project manager, but when you’re at a company long enough and practice Management by Walking Around[3], you build relationships across levels and organizations. I considered those relationships precious.)

Incidentally, if on a project I discovered that I was the prime recipient of these reports, I asked the project manager to stop creating them and simply tell me when something significant happened, good or bad. Most of the time, however, I was one of a number of high-level recipients, and the project manager’s managerial chain was asking for them as well, perhaps to prove to themselves and their customers/clients that their teams were actually doing something.

Most of the status reports I received over the years were like the bridge-toll sign, either telling me what I already knew, or telling me stuff that wouldn’t change what I was doing. I found it frustrating that some overworked project team had put hours into creating a work product on which I might spend, on average, 30 seconds.

So What Should a Project Manager Do?

I suggest a legal project manager do one of two things.

First, ask the key recipient – who I hope is someone other than your manager – which of the following she prefers:

  1. Traditional scheduled, detailed status/progress reports
  2. As-needed tell-me-when-something-changes updates
  3. Scheduled brief status updates focusing on key changes and items requiring action or awareness

Second, if the recipient isn’t sure, try sending those brief updates (#3) as a mutually agreed experiment.

In my next article, I’ll describe an effective status-report format that matches the third item – easy to produce, valuable to the project manager as well as the client, and useful to (most of) your clients. Who knows – they might even read it!

[1] About twenty years ago, I started sneaking the following line into the lengthy and detailed status reports I was sending out: “The first person to read this and respond gets a free latte.” (Remember, I live in the latte capital of the known universe.) It cost me a few bucks about one week in every three to conclude that these carefully crafted documents were at best skimmed but were mostly ignored. So I stopped sending them. The only people who noticed were my team, who no longer had to waste their own time feeding me, on schedule, information to summarize.

[2] I know. Sunny in Seattle, right? It happens. Don’t tell anyone.

[3] Yes, MBWA is a real thing. Seriously. Get out of your office and try it! (Learn about it first, though. It’s not the same as BMBLNGS, pronounced “bumblings” – Bad Management By Looking Nosy, Glaring, and Snooping.)


  1. Great analysis Steven! It applies beyond the legal project management context of course. I can think of so many applications! Looking forward to your next post with the template. Thanks. Kari

  2. It would help if any project progress report was not only kept brief (1 pg. or less), but referenced written project scope, pre-determined milestone dates, contract change orders, risk management issues, corrective action, etc.

    In the public sector, for audits which the results are sometimes revealed to the electorate, a progress report can become a useful tool –provided the underlying support documents are there also.

  3. Think about Agile project dashboards that show project progress based on a prioritized list of items the project was commissioned to accomplish, and shows progress at a glance in a “burn-down” chart. These, coupled with daily 15 minute stand-up meetings, can pretty much negate the need for those weekly written status reports that everyone hates creating and hates reading. But – client involvement needs to be increased. :)