Thursday, April 3, 2008

The Daily Report

I've noticed a trend recently. A couple of projects I work on or am aware of are feeling a need for project status reporting. One of these is in acceptance testing for a release. Another is just getting to the end of the first dev cycle and marketing/product management/other dev teams are just getting their first look at it.

What's In  A Report
In both of these cases (and in many other situations), there is a common set of information in the report:
  • an idea of what's done and what's not yet attempted
  • an idea of what issues there are and how bad they are
  • where to go for more information
Constructing the Report
Here's where we start to run into trouble. The contents of the report aren't usually in one system. Ideally we'd like to just run a query (in our defect tracking system, our ticketing system, our project management system, whatever. Often you're looking at multiple systems, however. If you're lucky, it's just two. If you're not, it's more.

The tempting thing to do is say to anyone who wants a status report, "Sure! Just go look it up whenever you want it!" Let the person who wants to know go figure it out. Be nice and send over the correct queries (or links that will do the queries for them).

Push vs Pull
Where our grand plan of "go look yourself" falls down is that reporting generally works best when it's push, not pull. It's a bit harder on the generator, but easier on the recipient. And the king of push is..... email.

So often we wind up constructing the report and emailing it out every day. This also provides the ability for the report generator (the person) to add a little commentary. The best way I've found to do this is to use a script to construct the basic report, and then to send it out by hand.

The problem is that any time you do reporting outside the system that actually holds the data, you:
  • Create work for yourself (whether writing a script or hand munging data)
  • Disassociate people from the location of reliable information. They can't get more info from email, and you're training them to look at the email, not the systems.
  • Drop information. You don't put everything from each system into your report, so some nuance is lost.
  • Duplicate information. This is bad in the same way code duplication is bad.
  • Remove the sense of time. Each report stands on its own, and getting the history of any issue still requires you to go to the primary source.

All that, and yet I still email out every night, and this group I'm watching is doing the same thing. Anyone else have a good idea how to balance push vs pull with aggregating data from multiple systems?

No comments:

Post a Comment