I believe that most people who either request or write reports start at the wrong place. Everyone seems to start at the data side and this, in my opinion, is incorrect. In order to create a good report, you need to start at the other end, the "The Why of It". This helps create requests that, in the long run, result in better reports. Remember, when you are working on a report from either side, the goal of everyone is to get the most usable report, minimizes the number of re-writes on the technical side and thereby less aggravation of the side of the requester. So now, let's look at some of the main reasons reports are created.

First, you have the decision report. Data presented in a manner that allows the recipient to make decisions based on some measure(s). Usually this is a high level summation but supporting data may be required, at least until the summaries are verified correct. The format best suited for this is probably a graph or a DataCube and would present data such as, is it time to add another full-time professor, based on use statistics, it is time to add another building or parking lot, etc.

Second, you have the report that make someone's job easier buy consolidating data from a number of locations into one report. Flags might be added to allow the user to target certain records that need attention. In other words, data is presented in a manner that allows the recipient to rapidly scan through data that might otherwise take numerous screen or reports to find and consolidate it into one report. Examples of this might be refunding students, processing payments, should we add another class, etc.

Third, we have the error report. Data is presented in a manner that allows the recipient to find error in the database and gives them enough information to correct those errors. This could be presented in either a spreadsheet or a printed report with groupings on errors. These usually show the errors, which students have those errors and could also show what needs to be done to correct the errors. Examples of this could be improper coding of admitted students, students not enrolled but registered for classes or no or incorrect birth dates.

Next, we have the external request. These are usually from government agencies, or in the case of the Institutional Research Office, from offices external to them in the institution. These reports and extracts, with their formatting, are required by the requesting agency and are usually very specific in nature. I have done numerous, usually extract, for these and they usually are not straight forward and require code conversion andreformatting of data.

Finally, we get to my favorite request of all. These are from those folks who believe the report designer can read their mind and know what they want and how they want it. These are the requests you get walking though down hall and they contain phrases like; "You know what I need", "Just format it in a standard format" and the like. These, I hate to say, go to the bottom the pile, usually never to surface again. I have found that these types of requests usually just fade away because the user forgets they asked to it.

As you can see, these reasons have some features that overlap and reports can contain parts from multiple areas. If you think about the types of reports you use or the reports you have written, I'll bet you can put them in one of the above categories. Once the why is determined, it's time to look at the "What of It"