Business Intelligence: Making Data Reporting More Effective

Attention to analytics for higher education is growing. Campus Technology recently published an intriguing interview with Florida State University, highlighting the success of FSU's initiative to build end user ownership of data reporting, and Tech Therapy this week podcasted an interview with the president of the University of Maryland, Baltimore County on making the transition from reliance on anecdotal evidence to reliance on ready and available data.

While the Campus Technology article focused on the technological solution employed, Brian Parish, president of IData Incorporated, suggests that for institutions that are revisiting their data reporting, process and communication may be more critical to sharing knowledge across your institution than the tools and technology that will provide the vehicles for that sharing. Here are Parish's tips for making data reporting more effective.

Shift the Focus from Data to Information

"Reporting is not a technology problem. The barrier is knowledge; you need to create reports that help end clients solve problems, and this means you need to help the end user frame the question. You need to understand the purpose of the report, why they need this. You need to share information, not just data."
Brian Parish, IData Incorporated

Parish suggests the need to encourage dialogue at the start of the reporting process between IT professionals (who understand the data architecture), IR professionals (who understand how to turn data into information), and the end clients (who know what they want to use the data for) -- or, at larger institutions, between business intelligence analysts and end clients.

"You have to start with understanding the end client's business needs," Parish advises. "Why the user needs the data is the one field missing from most reports." But it is key for any data request to include:

  • Who is requesting the data
  • Who else will need to view it
  • The purpose of the request -- in clearly defined terms

Here's an example. Suppose you have a request for a listing and count of all bursar holds. The lack of specificity in the request may lead to the end client getting data that isn't useful to them. For instance, do they want a count of holds or a count of students? Active students? Active holds? Which holds?

Also, who will use this information? Different users (for example, the bursar, the enrollment manager, the registrar, and the CFO) may have different assumptions and different ways of defining a hold. And what do they want to use this data for? "Communicating the purpose of the data request clarifies assumptions and allows for constructive dialogue on new ideas for how to report this information," Parish suggests.

For example, if you know that the reason for the request is that the university has many students calling in to say that they are unable to register online, and that the school suspects that many of these students are on bursar holds, then you can get at what the key stakeholders most want to know. In this case, they may want to know the causes of the holds, and what impact these holds are having on registration numbers.

Asking the question, "Why do we want these data?" and engaging the end clients in this conversation will allow you to both send them a report that helps them solve the actual problem, it will help you anticipate the next question they need to ask, and it will help you build trust across the organization. "Trust is eroded quickly," Parish suggests, "by people getting wrong numbers or numbers they don't understand." Basing data requests in a conversation about what information the end client needs and for what purpose rebuilds trust by limiting opportunities for incorrect assumptions and by positioning IT as partners in solving difficult institutional problems. This is the partnership you want to achieve: If you help me understand what you need to do, I can help you get the right information.

Documentation and Transparency

"Knowledge of the data is often bottlenecked in a handful of people. Democratize the data through training or documentation."
Brian Parish, IData Incorporated

"Even a data warehouse is usually a brain dump of that handful of people," Parish warns. "Don't rely on an overly simplified data warehouse. Regardless of whether or not you have a data warehouse, in either case it remains critical to ensure you are fostering conversation and knowledge-sharing across IT/IR silos. A data warehouse is a great vehicle for this knowledge-sharing, but it by itself will not solve the problem. You can roll out the perfect solution and the perfect delivery, but if the end user doesn't understand or trust the data, they are not going to use it."

Parish recommends striving for transparency in the reporting process, in the decision making, and in the sources of the data. Often there is resistance to sharing this because it is assumed that the information will be too technical for the end client -- or that it is IT's job, not the end client's, to understand the data reporting process. But documentation is critical so that the end user can track back where the data is coming from, and knows who to ask questions of.

For a given report:

  • Define terms in a viewable location (this will help you avoid repeating the work later)
  • Document who "owns" those definitions (for example, perhaps IR defines ethnicity, but the registrar defines what constitutes a "returning student" versus a "new student")
  • Document the purpose of the report and who requested it
  • Document the data sources (unless there are definite security reasons for not doing so)

Parish adds, "Once you have this structure in place, it builds trust. The end user needs to see that there is a process."