Our world today is swamped with data. More data than ever before is available to help us make decisions. Whether this abundance of information is actually helpful to decision-making or instead leads to analysis-paralysis depends largely on our system for prioritizing and reporting all that data.

Many of our colleagues are trying to use data to make sound decisions, so the need for access to data (via reports) is also increasing. The way we make sense of all the data is through reports.

As the amount of data has grown, the number of reports being requested has risen along with the complexity of these reports. Consequently, it takes the writer longer to produce a report. Just as one report is being developed and tested, three more requests can show up that need development!

What is the answer?

If budget is available, the quick solution is to hire consultants or additional staff to get more reports delivered. This begs the question, which reports should the “experts” or new staff work on?

If budget is not available, existing resources will need to shoulder the burden. So which reports should take priority when there are so many requests? You need to come up with a system.

How To Prioritize

1) Set Up a Report Request Process

Your process can use your institution’s existing Help Desk, or can be as simple as sending an email to a Report Request account. It’s important to note, however, that stopping someone in the hall and asking for a report is not going to cut it as a “Report Request Process”. Your process will require some discipline to maintain, but can be very successful if you stick to it.

2) Set Up a Goal or Desired Result

The data collected on the request can be simple or complex. The simpler the report request, the more time the writer can spend with the person requesting it to understand the nature and requirements of the report. Writers should never begin a report without knowing the desired result or goal! While building a report might feel like progress in itself, it’s not actually, and can lead to failure if the wrong development avenues are chosen.

3) Set Up a Ranking System

Once you have more than two report requests, you need a scheme to figure out which one to develop first. A common solution for many organizations is to rate or rank each report request on a scale, such as from high to low, important to regular, etc. In this system, the ranking is done by the report writer or report writers’ group. This works as long as the person doing the ranking knows how to rank the requests and progress gets made on the list of requests.

Some report writers find themselves working on reports for one user all the time, to the detriment of others and their requests. How does this happen? Despite a solid ranking scheme, report requesters (being clever little imps) often figure out what to say to get the ranking they “need”.  Some requesters know the system and lobby for a particular ranking. Others may know what to say to the request processor to get a certain ranking. This is just human nature. Nevertheless, it thoroughly messes up the ranking scheme and can destroy everyone’s confidence that they will ever get a report!

4) Get Requesters To Do Their Own Ranking

A better solution is to get the report requester to rank their requests at the time the requests are made, which can be done by asking a series of questions on the Report Request form. The report requester’s answers form the basis of the ranking.

It’s important to not ask vague questions in the ranking process. For example, asking whether the request is “high, medium or low” is a waste of time, since users almost always select “high”. Instead, ask questions like this:

• Is the report for an external agency?
• Will the institution be fined if there is no report?
• How long does it take you to produce the report now?
• Is the data for the report available in the ERP?
• Is this a new report or based on an existing report?
• Frequency of use?
• Who is going to read the report?
• Is the report on-screen only? CSV? Banded?

Additional questions along these lines can help rank a report request. Such questions are much easier to rank and produce a good list of ranked reports. Users have more difficulty gaming this system, so the integrity of the system is maintained.

Expect interruptions to the normal report development process. Additional reports enter the system and displace currently ranked reports. The ranking system may get overridden by executive management.

Share Your List Of Ranked Reports

It is important to have a list of reports in ranked order and make the list available to all requesters. You can do this by emailing the list weekly to each requester, or posting it on an internal web page. The list should show both completed reports as well as those in development, so that end-users can see progress being made. Also, if a report gets bumped down the list, the requester will need to know about it.

Report writers are not the bad guys when it comes to ranking reports. Wherever the report ends up on the ranking scheme list, that’s just the way it is. But when a report gets bumped down, the reason why needs to be clear. One solution is to have a process in which the requester can revisit their report to update their ranking answers. (Don’t get too worried about this step unless there are lots of reports waiting to be developed.)

When Rankings Get Overridden

Another issue with ranking reports is when the boss (manager, c-level executive, etc.) overrides a ranking and asks the report writer work on their own report instead. Obviously, this can be very annoying to other requesters. Cutting the line may be the boss’ prerogative, but if it happens often enough it should be added to the ranking system so that other requesters know to expect it. The weekly list should also reflect that certain reports were moved ahead by the boss.

Finishing Reports

Writers should be flexible enough to change a report based on user comments. Writers shouldn’t try to be perfectionists, just make sure the report meets its own requirements. That’s it. Don’t be tempted to “gold-plate” or gussy up the report with extra features that are not required, especially when the user did not ask for them.

Flexibility only goes so far, so report writers need to be aware of changes to the scope as opposed to fixes for required items.  Adding “address line 3” might not affect the report greatly, but adding alternate address processing might cause quite a bit of reworking to the report.

Is It Finished Yet?

One more important thing to note: Once a report is finished, it stays finished! The writer spent time gathering requirements and developed the report to meet those specific requirements. At the end of the process, the user needs to accept the report without making (further) changes in scope. Otherwise, changes to the scope will require a new report, which means a new request should go on the list.

Still think prioritizing report requests sounds like a hopeless task? Take heart! Adding questions to the Report Request Process in order to prioritize reports can be done fairly easily. Your reports can then be developed in order of priority and the status communicated to requesters on a weekly basis. Although additional time is required to set up and maintain the process, the system will soon pay valuable dividends by relieving frustrations and providing a method for developing critical reports in an efficient manner.