A former provost, who is now a college president, told me that IR is “The Keeper of Truth.” This seems logical, as IR should be the point of contact for both internal data analysis and external data reporting. Most importantly, there needs to be consistency and operational definitions guiding these activities. But, what if this is not the case at your institution? What if your institution has multiple truths? This article focuses on my experiences at one institution and includes ways I helped developed a common data language, as well as aspects that will undermine success in this endeavor. Developing a common data language can be addressed in three steps: (1) Trust, (2) Operational Definitions, and (3) Communication.

Trust

First, IR must be seen as a trusted office that is not seeking to promote its own agenda. From the moment I started working at this institution I had informal conversations with key functional staff in Admissions, Financial Aid, Registrar, Student Success, Finance, Athletics, and the faculty to better understand their experiences at the institution. A key reason to do this was to help them learn about the office of IR and trust my background and intentions. If colleagues do not trust you, they will not support you or use your data. In addition, building a level of trust makes it easier to have difficult data discussion down the road.

Operational Definitions

The second step is to develop operational definitions. At this institution, there was no agreement about how to quantify the number of students enrolled in a program. Although the IR office produced data, some faculty were pulling their own numbers. This became a major issue when a senior administrator provided the university president with enrollment figures that were drastically different from IR’s data. For example, while the IR office was counting enrolled students as those students who were enrolled in a course in a specific term, this faculty member was using a broader definition. The faculty member’s calculation included the number of students who could register for a course, even if they had not done so, and included all students who were enrolled in a course (IR’s definition), all students who had been accepted into the program (but had not registered), and all students who were active in the institution’s student information system (students remain active in the system for 365 days after their last registered class). Not surprisingly, the data from the staff member was almost double the figures from IR, causing confusion.

Communication

To fix the above problem, IR “formalized” the definition of students enrolled in a program, developed and shared an easy-to-access dashboard for faculty/staff, and provided the provost with a detailed explanation of the issue. This is the third step in developing a common data language: communication. Although the faculty member has continued to use their data in discussions, other senior staff are aware of this and use IR’s data.

Always take opportunities to communicate information to your colleagues. For example, at this institution, I presented during a faculty development seminar, which helped introduce more people to the field of IR and its importance. I discussed historical lagging measures of student success (e.g., graduation rates) and new leading measures that can be more actionable (e.g., first-year early momentum metrics).

Not all problems can be fixed in a such a straightforward manner (and one could argue that the current issue is not fully resolved), and institutional/personnel challenges can undermine success. High staff turnover creates confusion, loss of institutional memory, and difficulty documenting processes. For example, at the institution I am referencing, I was the fourth person to oversee the IR office in four years, and I struggled with this lack of continuity because I did not have a solid foundation from which to develop my understanding of the institution. Finally, if specific people are not utilizing your data, seek to understand why. Are they actively undermining you for a reason you can uncover, or do they need help understanding why the IR method is more appropriate? Although it is hard work, creating a common data language is imperative because you want your institution to have a single data voice, and IR should be that voice!