(2003-11-21) Rands On Status Reports

Dean Goodmanson baited me into noting this piece by Rands In Repose on Status Report-s. Some random thoughts to hopefully flesh out later: (disclaimer: I don't enjoy being a member of a large organization)

• I hate Status Report-s even more than Planning. They're usually requested by micromanagers who never add anything to the process but just want to "stay informed".

• each "audience" that Rands identifies has a different Context, so can one report serve them all? That's why people have a hard time writing them.

• I'm dubious about over-general "communication problems", no we are not cogs

  • who cares what those schmoes over in the support group are doing, anyhow? You've got an engineering organization to build. Well the person who cares is the Product Manager who needs support and engineering to work together. If you don't have strong product people but just some mushy matrix crap then a Status Report won't save your ass.

• this is key when you want them on board when you're proposing that two month slip to improve quality. Who is the Onsite Customer for that project? Also see Agility Vs Conflict.

• The other major consumer for Status Reports is, well, everyone else in the company... Let's say you've had an open issue on your status report for four weeks now. No we don't want everyone reading each other's status reports. This is definitely a hit-or-miss thing and having Status Report-s isn't likely enough to solve the problem to justify the overhead.

• (Wiki-s are) great for a random mix of evolving information, but, at the end of the week, someone has to generate a Status Report and that person's life will be easier if they don't have to do a damned thing. Yikes, picking a Collaboration Ware tool/practice based on how easy it makes it to generate Status Report-s????

Alternatives:

• remember the Team Is The Focus. Let them use what they want to communicate/document. But (a) get in on the Intranet, (b) get it into a Vertical Search Engine, (c) have an RSS feed for browsers, so people can nosh quickly a little more widely than they would otherwise.

• have Onsite Customer-s or the equivalent to provide a FeedBack loop. Increase the speed at which you deliver benefits to those customers. That's what belongs in a steenking Status Report.