Need to know total sales by region last quarter? Build a report. Need to know how many projects are currently over budget? Build a report. Management has a slew of questions that need answers?  Build more reports. Reports, reports, reports. We need more reports.

Sound familiar? Whether you’re in management requesting them, on the IT team building them, or someone on staff sifting through them, chances are your organization has a huge list of internal management reports or queries that just keeps growing.

When a manager asks questions no one has answers to, the usual solution is to create a report or query. But does anyone ever stop to consider the implications of writing a report? How much time it will take to develop and test, and what will be involved in maintaining it? There’s a common misconception that reports can simply be ‘whipped up’. If your organization tracks time, run a query to find out how much is spent building reports and queries. Uh-oh, don’t already have a query for that? Try asking your IT department how much work goes into writing reports before you dive into creating a query in your time tracking system. The discussion will probably take less time than the query, and there are some things numbers on a piece of paper can’t tell you.

Back to the problem at hand - your growing list of reports and queries. It’s important to realize, and communicate, that creating new reports take time. Even with a mature infrastructure for building internal reports, it still takes time. A few hours here and a few hours there can add up quickly. Here is a shortlist of things to consider before jumping to the conclusion that building a report or query is the best thing to solve your problem:

  1. Is this really necessary? Are you looking for information to solve a problem, or to satisfy your, or someone else’s, curiosity?  If it’s the latter, consider if it’s truly worth the cost and effort.
  2. Do you already have a report with this information? Maybe there is a report that was not specifically designed to provide the information you need, but the data could be extrapolated with a little creativity.  Maybe an adhoc, one-time query was requested sometime in the past? If you have a history of such requests, search it.
  3. When do you need the information? The time to build a report varies based on the complexity of your data and the complexity of the requested report. But a common misconception held by those outside of the IT industry (and by some within the industry) is that reports are easy. Some of the largest, most complex projects we’ve worked on have been ‘reports’. Consider situations where you are cross-referencing data between multiple systems - perhaps you need some data from your POS, your accounting system and your HR system. Now you are looking at some form of data-warehousing on top of your report and you’ve opened another can of worms. Of course, reporting can get complex even if the data you require is conveniently contained in one database. Throw in a few crosstabs and some aggregate functions and you add complexity to what, at first glance, seems the most simple of reporting jobs.

  4. Explore other avenues. Are there other ways to gather the information besides running reports? Here are a few different avenues you can explore:

    1. If you don’t need precise numbers, discuss or poll your coworkers - their past experience may be enough to give some rough figures.
    2. Check the internet. Let’s say you want to know which browser the majority of your customers are using. Sure, you could run a query on your own internet statistics, but this is the sort of thing you can assume is going to be similar to other companies, at least within North America. Web browser market share is readily available on the internet.
    3. Be creative with your existing systems. You want to know how many people live in a specific city but don’t have a report for it? Well, how about the search window in your system? Can you search by city, and if so, will the search give you a listing with a count? If so, problem solved.
  5. Maintenance. Ever consider how much it will cost to maintain a report? Well you should. If you build it, they will run it. And keep running it. And keep expecting it to return valid results. Unless you explicitly build it into your requirement that the report is for a one-time purpose only, a user will, at some point down the road, find the report and run it, so hopefully you include reports in your regression testing. We’ve seen many software systems with custom reports that don’t even run anymore, let alone return accurate data.

If you read point #2 (Do you already have a report with this information?) and thought to yourself, “yeah sure, there might be a report that does that but good luck finding it,” then you should consider building a report register. Have someone sort through your reports and document a short description of each. The format can be as simple as a listing in a Microsoft Word document (ok, this is another report but it’s well worth it). If you have multiple systems with reporting/query modules, combine them in your register. This is short-term pain for long-term gain. If you have custom built software, or user designed reports in your off-the-shelf software, you might be surprised (or not so surprised) to find you have duplicated reports. Having a report register will avoid duplication of work and, in cases where you already have a report for a given data request, it will speed up turnaround time.

The next time someone suggests building a report, pull out the above list and be sure it meets all the criteria before moving forward.

For a related article, please see the following:

The Report That Requirements Forgot: A Guide for Collecting Requirements for Reports