The person who wants to replace the institution’s student management system and the person who approves the budget for doing so are often working from very different mental models of what the problem is.
The registrar or IT manager who lives with the current system knows its limitations in granular detail. They can describe the exact sequence of steps required to reconcile term-end records, the specific error types that reappear every intake, the workarounds their team has built to compensate for missing functionality.
The decision-maker approving the budget — typically the vice chancellor, bursar, or board — sees a system that is “working” (in the sense that the institution is still functioning), a significant capital outlay, and an implementation risk. The question they are asking is not “what are the system’s limitations?” It is “why should I spend significant money on something that is not visibly broken?”
Building a business case is the work of translating between these two perspectives.
Lead with cost, not features
Feature comparisons are persuasive to people who understand the features. Decision-makers who do not work in the system daily are not moved by a list of capabilities the current platform lacks. They are moved by numbers.
The most effective business cases quantify the current cost of the status quo:
Staff time on manual processes. Measure the actual time your team spends on activities that an integrated system would automate: data re-entry between systems, reconciliation exercises, manual report production, correcting errors caused by re-entry. Assign a cost to this time using average staff salary figures. This number is often surprisingly large.
Error correction and rework. Track the number of data errors — billing disputes, incorrect registrations, record discrepancies — that occur in a typical term, and the staff time required to resolve them. Include any student experience costs where errors resulted in complaints or escalations.
Compliance and reporting overhead. Calculate the time required to produce standard regulatory and accreditation reports. If producing a report that should take minutes takes a day, that gap is a quantifiable cost.
Opportunity cost. The staff time absorbed by manual processes is staff time not spent on student services, counselling, and the activities that actually improve student experience and retention. This is harder to quantify but often the most compelling part of the argument for institutional leadership.
Build the ROI model
Once you have quantified the current cost, building the return on investment model is straightforward:
Investment: Total first-year cost (licence, implementation, training, and an honest estimate of internal staff time for the implementation).
Annual saving: The staff time and error correction costs eliminated by the new system, converted to a monetary value.
Payback period: Investment divided by annual saving. For most institutions, this is 12 to 24 months.
Net benefit over three years: Three times the annual saving, minus the investment.
Most decision-makers want to see a payback period under two years and a clear positive net benefit over a three to five year horizon. If your numbers show this, you have a fundable business case.
Address the implementation risk head-on
The single most common objection to replacing a student management system is implementation risk: what if the migration goes wrong, what if staff cannot learn the new system, what if it fails during examinations?
This objection is not irrational. Student management systems are operationally critical, and implementations that are poorly planned or poorly executed do cause disruption. The business case needs to address this directly.
Reference institutions. Identify comparable institutions — similar size, similar programme mix, similar current technology environment — where the platform has been implemented successfully. Decision-makers are significantly more comfortable when they can see that institutions like theirs have made the transition without catastrophic disruption.
Phased implementation. A phased implementation — starting with admissions and student records, then adding fee management and examinations once the core system is stable — reduces the risk of simultaneous disruption across all functions. Present this as the implementation approach, not as a concession.
Parallel running. Committing to a period of parallel running, where both systems are operational before the old one is switched off, addresses the “what if it fails” concern. It adds cost but significantly reduces risk.
Vendor support commitments. Document what support the vendor is committing to during implementation and go-live. A vendor who will have staff on-site during the first examination period on the new system is a meaningfully different risk profile than one who offers email support.
The timing argument
Business cases for technology investment are often shelved and revisited periodically without ever getting approved. The element that gets them over the line is usually urgency: why now?
Common urgency arguments in higher education technology:
Upcoming accreditation review. If the institution has an accreditation review in the next 18 months, demonstrating structured data management and reporting capability is a live requirement, not a future aspiration.
Staff dependency risk. If the institutional knowledge required to operate the current system is concentrated in one or two individuals, and those individuals are approaching retirement or have expressed intentions to move, the risk of losing that knowledge is acute and quantifiable.
Enrolment growth. If the institution is targeting enrolment growth, the current system’s capacity constraints will become binding sooner rather than later. The cost of the new system scales more favourably with growth than the cost of adding staff to manage manual processes.
Competitor positioning. If peer institutions in the market have moved to modern, integrated platforms, the gap in operational efficiency and student experience capability is a competitive disadvantage that compounds over time.
Presenting the case
A business case for institutional leadership should be concise — a five to ten page document plus supporting data, not a comprehensive technical specification. The structure that works:
- Current state: What the institution is doing today and what it costs.
- Future state: What the new system enables and what it costs.
- ROI model: Payback period and three-year net benefit.
- Implementation plan: Phased approach, timeline, risk mitigation.
- Recommendation: Clear ask for approval, with a proposed decision timeline.
The supporting data — the staff time measurements, the error logs, the vendor reference contacts — goes in an appendix for decision-makers who want to verify the numbers.
If you are in the process of building a business case and would like a sounding board on the financial modelling or the risk narrative, we are happy to help.
