The questions your faculty information system cannot answer
Questions to Ask Before Renewing a Faculty Information System
Ask a faculty information system where a single number in a promotion dossier came from, and watch what happens.
Not who entered it. Not when. The source. Which CV, which self-report, which extract job, which human being typed 47 into a box three years ago and never touched it again. Most systems can tell you the number exists. Almost none can tell you why you should believe it. That’s what tenure dossier source data tracking software is supposed to solve, and mostly doesn’t.
That’s the question I’d fix first if I could only fix one: what is the source line behind every dossier claim? Faculty are the front-line workers of the university, the ones who deliver its two actual products, teaching and research. Everything else — every dean’s office memo, every provost’s report, every accreditation binder — is downstream of what those two products produce and how well we can prove it. If the provenance underneath a dossier is mush, the mush travels. It shows up in tenure cases, in program reviews, in grant reports that cite output numbers nobody can trace back to a source. Faculty are, without much argument, the most important and least well tracked part of the university. Fix the source line and you don’t just fix one field. You fix the thing every other field depends on.
Faculty Information System Evaluation Questions for Provosts and Deans
Once you start asking that question, a few others follow it like they’ve been waiting.
“Show me the audit trail for every change made to this dossier in the past year, including who and why.” Most systems log the change. Fewer log the reason, and reason is the part a search committee actually needs.
“When a CV lists a publication that isn’t in the repository, or isn’t in Scopus, which source wins, and how do you know?” Ask this in a room full of associate deans and watch the silence.
“What’s the process when a faculty member disputes their own data, and how is that dispute tracked?” Not whether there’s a form. Whether the form connects to anything.
“Can you break down workload and service obligations by department against our own targets?” This one sounds like a reporting question. Underneath, it’s a data-model question wearing a reporting question’s clothes — the same question as whether faculty information system integration with ERP and SIS actually holds together, or just looks like it does in the demo.
None of these are exotic. A provost could ask any of them on a Tuesday and expect an answer by Thursday. The fact that most systems can’t produce one isn’t really a feature gap. It’s a signal of what the system was built to optimize.
Ask this one and people start looking at me like I’m being difficult on purpose: “What is this faculty member’s current research focus?” You’d think this sits in a dropdown somewhere. It doesn’t. It’s scattered across a CV that’s a year stale, a departmental bio page nobody updates, a grants database that only knows what got funded, and a memory in the department chair’s head. Ask the question plainly and people assume you already have the answer and are testing them. You’re not. Nobody has the answer, reliably, across the whole institution. That’s the part that’s hard to say out loud in a meeting.
I’ve raised these gaps with vendors and with campus IT more than once. The answers cluster around a couple of shapes: too complex, not a standard feature. Sometimes it’s “would need significant custom development,” which is the same answer dressed up for a budget conversation. Sometimes the reason offered is a privacy concern, that opening up the audit trail or the source data would create compliance risk. Whatever risk is real runs through institutional policy and state personnel law, not FERPA — FERPA covers students and has nothing to say about a faculty member’s publication record. Real exposure sits where student data touches a faculty record — advising notes, recommendation letters — which is where FERPA-defensible faculty data security with row-level access actually matters, not in a publication list. When the wrong regulation gets cited as the reason something can’t be built, that’s usually a sign the real reason hasn’t been said out loud.
I don’t fully believe the other reasons either. What I think is actually going on is a design choice made a long time ago, quietly, without anyone voting on it: these systems were built for the administrator entering the data. The faculty member the data describes, or the dean who has to defend it in a hearing, was never really the audience. Your systems are built around what’s easy to measure. That’s rarely the same as what matters. A system that can log a change but not a reason was built by someone who needed the log for a different purpose than the one you’re using it for now.
A Faculty Information System Capabilities Checklist
You don’t need to burn down what you have. You need to change which question you lead with when you sit across from a vendor or your own IT shop. Stop asking whether the system can do the thing it was demoed doing. Ask it the question it was never asked to answer. Ask for the source line. See what comes back. Whatever comes back is the actual state of your faculty data. The dashboard was showing you something else.
Any real checklist also prices out the faculty information system cost per faculty line and asks what your exit strategy looks like if the vendor relationship sours in year four. That, more than any demo, is how to choose a faculty information system.
Nobody takes you aside anymore
Print taught a generation when to stop. What we lose when the machines absorb the constraints that used to form us.
Your AI agents need a water cooler
Coordination is a property of the room, not the org chart. What that means when your coworkers are agents.
On the death of the author and the birth of the detector
Why worrying about AI authorship is lazier, and more prejudiced, than it looks.
The work of being available now
A book on AI, judgment, and staying human at work.
The practice of work in progress
Practical essays on how work actually gets done.
Memory is (almost) solved. time is next.
AI can't tell if a memory is two minutes or two weeks old. The fix isn't making models feel time — it's cache invalidation: an as-of stamp on every fact, a clock in the context, and a freshness window for anything volatile.
Did the state change? A simple test for whether work actually happened
Either something exists now that did not exist before, or it does not. A simple test for whether work actually happened, and what changes when you build your systems so they can't record anything else.