The number on a supplier proposal is the license. It is clean, it fits on a slide, and it is the smaller of the two figures that matter.
The one that shapes the project is implementation: integration with the student information system and the identity provider, data migration, configuration against your academic policies, and the faculty and staff development adoption requires. Enterprise and student-system projects overrun their planned budgets and schedules often enough that the safest move is to plan implementation as a project in its own right. Its own scope, its own timeline, its own budget line. Panorama Consulting Group’s annual research has found this same pattern for years running (Panorama Consulting Group, ERP Report).
Why the figure is so easy to underestimate
A supplier’s implementation estimate is built for a typical customer, and no institution’s integration environment is typical. The estimate assumes a certain number of source systems, a certain level of data quality, a certain set of in-scope integrations. Reasonable assumptions in the aggregate, and rarely an exact match for your environment specifically.
On the institution’s side, the effort is scattered across offices. Procurement holds the license. IT holds the integration work. The teaching center holds faculty development. The registrar holds the data cleanup. Each estimates its own piece, and unless someone is actively adding them together, the true total does not surface until the project is already underway.
The fix for both problems is the same: build the number from your actual environment, early, with one person accountable for the whole of it.
Building a number you can trust
Ask for implementation scope broken out from the license, in hours by role, with a named answer for who supplies those hours. The supplier, a third-party integrator, or your own staff. “Implementation included” usually means a fixed allotment of supplier hours, and it is worth knowing exactly how many, and for what.
Write down what the estimate assumes about your environment, and what it becomes if an assumption turns out wrong. How many source systems. How clean the data is expected to be, which integrations are in scope versus billable separately. Those assumptions are the terms the whole estimate rests on.
Have your own people size their side independently, before they see the supplier’s number. The LMS administrator, the identity team, the instructional designers, the registrar’s data staff. Ask each how many of their hours it takes to get the product working and keep it working through the first year. The sum is the real internal effort the project demands.
Run an integration discovery before the shortlist closes. A working session between the supplier’s technical staff and your own LMS and identity teams surfaces the local workflows and customizations a generic estimate simply cannot anticipate. And it lets the finalists price the real work instead of the assumed work.
Budget for the second year. Implementation does not end at go-live. There is a stabilization period, a support model that either exists already or falls to your existing staff, and a renewal negotiation waiting down the road. A number that stops at go-live describes roughly half the actual effort.
Give implementation its own line and its own timeline. Two products can carry nearly identical license costs and still land a full year apart in time-to-working, entirely driven by how each one fits your environment. An evaluation that compares only licenses is comparing the smaller thing.
What good looks like
Institutions that land these projects close to plan tend to do three unglamorous things. They budget implementation at the size their own staff estimates, not the size on the slide. They put one person in charge of the whole figure, treating license, integration, data, and faculty development as a single combined number. And they build the governance calendar into the timeline so go-live lands in a term with room to absorb it.
None of that is especially sophisticated. It is just refusing to let the smaller, cleaner number stand in for the one that determines whether the project works.
Jack Wrightmann is a consultant at Wrightmann Education Technologists. Part of the Technology Procurement series.
References
- Panorama Consulting Group. The ERP Report (annual series). https://www.panorama-consulting.com/resource-center/erp-report/
- EDUCAUSE. (2025). Higher Education Community Vendor Assessment Toolkit (HECVAT). https://www.educause.edu/higher-education-community-vendor-assessment-toolkit