Ever begin work on a ‘quick query’ or management report that can supposedly be ‘whipped together’, only to find out it’s not going to be as simple as everyone originally thought? It’s a common misconception that ‘reports are easy’ and ‘queries are simple’.

Collecting data for reports can become complex. Some organizations have built entire data warehouses to make sense of their own information. The presentation of that data can be just as perplexing; a page sprayed with statistics is about as useful as staring at wallpaper. Most important of all, if you aren’t collecting proper requirements for your reports, you might make the worst mistake of all - not providing your client or customer with what they asked for. At least, what they thought they asked for.

Often, requirements gathering falls to the wayside for reporting, particularly internal management reporting and adhoc query requests. In cases where requirements are collected, the right questions are not asked. You can’t take the same approach as you would when collecting requirements for a new user interface or changes to business rules.

Here are some guidelines that will help keep your reporting and query requirements gathering on track:

  • Audience. Is this report internal or external?If it’s external, consider an even more rigorous requirements gathering process than what is described in this article.If the report/query is internal, you still need to nail down who will be using the report.An IT manager is going to tolerate a little more technical jargon than your HR manager.
  • List the conditions of your report.Things like ‘the query should only contain customers in Canada’ or ‘only include cars that are accident free’ should be stated up front.For you techies, this is essentially everything in the ‘where’ clause.
  • List the output.Whether the report results are a simple MS Excel listing or a colourful multi-page report with charts and graphs, there are going to be data elements in the output. Find out exactly what these data elements are. Be specific.If the report request asks for ‘Name’, find out if that means ‘First Name’, ‘Last Name’, or ‘Last Name, First Name’.
  • Calculations.  Is there calculated output on the report?If so, get those calculations down on paper.If ‘Quantity’ and ‘Price’ are in the output, make sure that ‘Total’ is listed in the calculations section of your requirements as ‘Quantity * Price’.
  • Grouping. Do you want to see totals by department? By Office Location? By Province?
  • Sorting. Do you want the output sorted by department, office location or province?
  • Output format. Is this report to be presented in an existing report container, like the User Reports module in a off-the-shelf product like Microsfot CRM?Or should the output be in Excel, a CSV file, a pdf, etc.?
  • Frequency. Is this a one-time report, or something that needs to be available on demand? Is it a recurring report, and if so how often?Daily, weekly, monthly?
  • Distribution.How should this report be delivered (particularly if it’s a recurring report)? An email with a link to a SharePoint file?Or perhaps the report is simply placed on a network drive for the user to view at their leisure.
  • Privacy/Security.Is there private information (like SIN) that has been requested within the report? If so, you might want to run this past your company’s security officer or legal authority, if you have one.Also, is there sensitive data (like employee salary information) on the report?If so, make sure only those with the authority to view that information have access to the output.
  • Some other cosmetics to consider:
    • Letterhead – should this report be on company letterhead?Often times, a ‘quick query’ is not done with the proper headers/footers and this can be embarrassing if the report ends up in the hands of your CEO.The safe bet is always use the proper letterhead.
    • Duplexing – should the report be double sided?
    • Window Envelope – should the report fit in a windowed envelope? This is probably not a concern for most internal reports/queries, but you are best to get in the habit of asking.
    • Number of pages – is there a limit on the number of pages for the report output? Again, not likely a concern for internal reports but it’s best to get in the habit of asking this as well.
    • Charts/graphs – as the old saying goes, a picture is worth a thousand words. If there is an opportunity to represent data graphically, you are best to do so.
    • Other communication/brand guidelines – does your organization have a standard set of guidelines for reports (fonts, font sizes, header footers, margin spacing, etc)? If so, make sure you adhere to them.

Whether you are the one requesting a new report or the one building it, remember that you need to collect requirements. Use this article as a checklist to help guide you through the process.