A vice-chancellor we worked with once asked a simple question: how many active students were enrolled in the institution at that moment? She wanted the number for a board report she was writing that afternoon.
She got three answers within an hour. The registrar’s office said 14,720. The finance team said 14,683. The student affairs department said 14,756. All three numbers were produced from the institution’s official systems. All three were technically correct, depending on which definition of “active” you used (registered for at least one course, financially current, attending classes). None of the three teams had realised the others would count differently.
The board report went out with the registrar’s number and a footnote acknowledging that “minor variances exist between departmental counts.” The vice-chancellor spent the rest of the week trying to understand why a university with twenty-five thousand staff and students could not, at any given moment, tell her exactly how many students were enrolled in it.
She was discovering, in real time, what running a university actually involves. The answer wasn’t that her institution was badly managed. The answer was that universities are more complex than they look, in ways that don’t usually become visible until somebody asks a question the institution can’t quite answer.
What’s actually happening on any given Tuesday
A modern university is best understood not as one institution but as a set of overlapping operational systems that share a student population.
In any given week during semester, the same student is being tracked by their faculty for academic progress, by the registrar’s office for enrolment status, by finance for fee compliance, and by student services for engagement. They are also being tracked by the library for resource use, by IT for system access, by examinations for assessment readiness, and by their academic advisor for personal development. Each of these tracking functions is owned by a different department, operates on a different cycle, and answers to a different policy framework. None of them, on its own, has a complete picture of the student.
Scale this across twenty thousand students. Multiply by the number of staff who interact with each of them. Add the cross-cutting operations that have to coordinate across all of these departments simultaneously: the academic calendar that sets every assessment, registration, and submission deadline; the financial calendar that drives billing and collections; the governance calendar that schedules committee meetings, audit reviews, and senate approvals. On any given Tuesday in October, a midsized university is running thousands of concurrent workflows, most of which touch each other at unpredictable points.
This is not the operational profile of a corporation. A corporation usually runs one or two primary value streams, supported by horizontal functions. A university runs eight or ten primary operational streams, all of which are equally critical, all of which interact with each other, and none of which can be reorganised away without breaking something else. The complexity is structural, not accidental.
This is also why a simple question like “how many students do we have right now” can produce three different answers from three different departments. They’re not wrong. They’re each looking at a different facet of the same operational reality, and the reality is too multi-faceted to compress into a single number without choosing a definition first.
The academic calendar creates synchronisation spikes
What makes university operations harder than most other large-institution operations is the calendar.
A retail business has continuous operations, smoothed by hour and day. A bank has continuous operations, with predictable peaks around month-end and year-end. A hospital has continuous operations, with reactive surges driven by external events. A university has none of this. A university has a series of synchronisation spikes built into its operating year. A synchronisation spike is a period when almost every department must act simultaneously, on shared data, against a hard deadline set by the academic calendar.
Orientation week. Registration period. Mid-semester assessments. Finance reconciliation. Examination week. Result publication. Convocation. Each of these events forces the entire institution into one operational cycle for as long as it lasts, and the cycle is non-negotiable because the academic calendar holds.
Between the spikes, the institution looks relatively calm. During the spikes, the same systems and the same people are doing five times the work they normally do, often with the same staff numbers and the same infrastructure. The institution that copes well during spike weeks is not the one with more staff. It’s the one whose systems can take the surge without breaking.
This is why university operations software matters more in higher education than equivalent platforms matter in most other sectors. Most enterprise software is designed for steady-state operations with predictable load. A university’s platform has to handle weeks when the entire institution is doing the same thing at once. If the system can’t smooth the spike, the staff smooth it by hand, and the cost of that smoothing is what shows up later as audit findings, data inconsistencies, and the kind of operational spreadsheets that quietly become the system of practice.
Multi-campus makes everything multiply
The moment an institution becomes multi-campus, the operational complexity stops adding and starts multiplying.
Each campus has its own faculties, its own registrar’s office, its own finance staff, its own examination centre, its own minor academic calendar variations. The institutional policies are the same, in theory. The implementation of those policies, in practice, varies by campus, by faculty, by historical precedent, and by the personalities of whoever happened to be in charge during the formative years. A multi-campus university running on disconnected systems doesn’t really operate as one institution. It operates as a federation of campuses that happen to share a logo.
The coordination problem this creates is severe and rarely well solved. A student who registers at one campus may need to attend classes at another. A scholarship awarded by the head office must be applied to a student record held at a specific campus. A senate decision made at headquarters must be implemented identically across every campus, by staff who do not all use the same systems and do not all work to the same data definitions.
One multi-campus institution we worked with discovered that its scholarship policy was being applied differently at three of its four campuses. Nobody had decided to vary it. Each campus had interpreted the senate’s original wording slightly differently during local implementation, and the central office had never compared the results. By the time the discrepancy was found, six years of cohorts had been awarded scholarships under three different effective rules at the same institution.
Multi campus management software exists for this reason. The institutions that handle multi-campus operations well are not the ones with separate platforms per campus. They’re the ones whose platform treats the institution as one entity with multiple physical locations, and which enforces the same rules at every site by default. Anything less, and the institution finds itself running parallel universities under one name.
The visible and the invisible university
Most observers see only the visible university: the academic calendar, the lectures, the exams, the graduation ceremony. From the outside, it looks orderly. Students arrive in September, study for a year, sit exams in May, and graduate in July. The cycle repeats.
Underneath that visible layer is the operational layer that makes the visible one possible. The student who arrived in September was admitted through a process that began nine months earlier. The fees they paid in October were calculated against a fee structure that was revised by senate in July and configured into the finance system in August. The exam they sat in May was scheduled against a timetable that was negotiated by academic services in March and reconciled with examination resourcing in April. The transcript they will receive in July is being assembled, right now, from records that are being updated across at least five different departments.
None of this is visible from outside the institution. Most of it isn’t visible from inside the institution either, unless you happen to work in one of the affected departments. The vice-chancellor from the opening of this piece had been running her university for six years before the enrolment question made the operational layer visible to her in a way it hadn’t been before.
This is why simple questions about a university tend to surface complicated answers. The simple question lands on the visible layer. The honest answer requires somebody to traverse the operational layer underneath, and the operational layer is usually being held together by enough informal coordination that no single person can describe it confidently.
What coordination at this scale actually requires
The institutions that operate well at this level of complexity have one thing in common. They have a single source of truth for institutional data, and every department draws from it rather than maintaining its own version.
This sounds obvious. In practice it’s rare. Most universities operate on systems that were chosen at different times by different teams, each of which produced its own dataset, and the data has never since been fully reconciled. The finance system has its student count. The academic system has its student count. The student services system has its student count. The integration between them is patchy, manual, and outdated. The three counts diverge. Nobody is willing to say which one is right.
Fixing this is harder than it sounds, because consolidating onto a single source of truth requires the institution to decide, for every important data point, which definition is the authoritative one. That’s not a technical decision. It’s a governance decision, and it has to be made by people who have authority across all of the affected departments. The hardest conversation is usually the one where the finance director and the registrar both have to accept that their count is not the authoritative one, and that one of them will have to change the reports they have been producing for years. Most institutions defer the conversation indefinitely, because somebody loses every time it happens.
The institutions that have done it report a different operational profile. The vice-chancellor who asks how many students are enrolled gets an answer in minutes, from a dashboard that draws from the single source. The board report doesn’t need a footnote about variance. The institution finally knows itself, at the resolution that decisions actually require.
Where this leads
The vice-chancellor from the opening eventually got her institution onto a single source of truth, though it took two years and a great deal of governance work to get there. The conversion involved consolidating six overlapping student datasets, reconciling four different fee structures across three campuses, and persuading each department head to stop maintaining their own counts.
By the end of that work, she could open her dashboard during the Monday meeting and read out a single, authoritative figure. The number she got wasn’t a compromise between three departmental versions. It was the institution’s actual position, calculated against agreed definitions, updated in real time.
The cost of getting there was real. The cost of not getting there was higher. Every operational decision the institution made in the two years before the consolidation had been made on imperfect data, with some level of confidence that depended on which department had produced the report. The institution had been managing itself through approximation.
It hadn’t always known that. Most universities don’t.
