Monday, August 18, 2008

The Acid Test for Custom Reports

OK, I'm speaking to the people who work in small entrepreneurial comapanies here. For those of us who chose to work in a dynamic entrepreneurial setting do it for the rush of immediacy. The ability to move quickly. to stay light on our feet, and make real change.

Lots of times, in performance meetings, someone at the table (ok, it's usually me) will pipe up and say "How hard would it to be able to just find out ..." It's a theoretical discussion only.

Someone has a new report request.

Maybe its something they've thought through, and is going to revolutionize the way we do our business.

Maybe its just idle curiosity.

The tech people at the table immediately tend to jump on the "How do we do this?" bandwagon, totally bypassing the "Is this something we should be allocating valuable resources to?" train.

And usually, at first blush, the answer looks and feels like ...pretty quickly.

But how often is that true?

Sometimes, what happens at that point, is someone pipes up and "authorizes" the report, based on the assumption that someone else can whip it up over sandwiches today at lunch.

Then that someone else spends the whole afternoon on it, because they ran into a few unforeseen stumbling blocks. Oh, and by the way, they have a couple of questions about how the reports should be formatted...so now followup meetings are being scheduled, and the person who first requested the report, is now piling on additional feature requests, unchecked. And the dominoes start to topple....

The project has outgrown the petrie dish, and is limping hideously through the corridors of your place of work, wreaking havoc. People have forgotten its original, innocuous status as a "theoretical discussion". The hours invested in it have infused the project with the value of human sweat.

Let's take a peek a few weeks down the road, and go ask how much time the new report is saving? A couple of possibilities (terribly overgeneralized of course)

1. The person who first requested the report has a new spring in her step, and has lost the haunted look that comes from too many hours manually calculating stuff that is better done by a computer.

This is the result you're going for. Congratulations.

That young genius is probably going to start poring over the reports and come up with a great recommendation that will materially alter how you do business...save you a gazillion dollars, and pay for the implementation 40 times over before next week's meeting.

2. The person who requested the report has relegated it to the pile of "stuff I don't need to babysit anymore." Ask her how it's progressing, and she'll pull a report for you while you wait. ....and oftentimes discover that the data is being pulled incorrectly or the report is garbled, or not in a format that is useful to anyone. ***By virtue of having been authorized in the first place, the project has been elevated to the status of "stuff worth doing properly"****. At this point countless additional hours may be sunken into the pursuit, before any kind of cost:benefit analysis happens.

3. The person who first requested the report is completely buried. The time requirement to analyze the implications of the new report is consuming them and they no longer seem to have time to stop and think about how much benefit the new information affords them(factoring in all of the data exceptions, annotating the performance anomalies that affect the data output, and closing the knowledge gap between the data and the information that data stands proxy for).

The Three Things That Should ALWAYS Happen Before Anyone Builds a Custom Report

1. Write a SPEC. Even for a little thing. This process is great for shining a light on the holes that are so easy to gloss over in discussion. We sometimes want to rush past this step. We know exactly what we want. We think we have expressed it clearly. We think there is no room for error.

I'm married to a system architect. I've tried asking him to just whip me up a report (I am a self-confessed data junkie). Without a written spec, he refuses, even when I assure him its quick and easy. Even when I say pretty please or bat my eyelashes.

Try this. If is a simple report, it will only take you a few minutes to write out the functional spec. Describe all the inputs, the data sources, and all the possible outputs, depending on what inputs the report receives. This will bring you a lot closer to a shared understanding with the people who are building the report.

If having the report is not worth the time it takes to properly specify how it works, you probably don't need it.

2. Remember that data is only a proxy for information. It is imperfect, and prone to misinterpretation. It can act as a red herring, or mask important trends. Be sure that everyone involved understands how the data is being calculated. Call the data what it is, not what it is supposed to represent.

Create a A data Glossary of Terms.

3. Things automated are easily forgotten. Ensure you build in a mechanism for following up on the results of the report.

Final Notes

There is a lot of room for assumptions when people toss an idea about over the boardroom table. But programming a custom report is an exact science. Many a programmer has misinterpreted the requirement, and built a report that does not meet the need. And often the report that DOES meet the need is a LOT harder to build.