The university platform decision is made before procurement opens

By the time a university publishes a tender for a new student platform, the outcome is largely fixed. Not because the evaluation is rigged, but because the decisions that determine success were taken months earlier, informally, by people who did not think they were making a procurement decision at all.

We have run this process from both sides — advising institutions on selection, and building the platforms that result. The pattern is consistent enough to be worth writing down.

The requirement list is a record of the current system

Most requirement catalogues are assembled by asking departments what they need. Departments answer by describing what they currently do, because that is the only concrete thing available to them. The catalogue that emerges is therefore a specification of the existing system, with its accumulated workarounds promoted to the status of requirements.

This matters because the workarounds are usually the expensive part. A registry team that maintains a parallel spreadsheet because the current system cannot handle a particular progression rule will write "must handle progression rules as per current process" — and the new platform inherits a rule that exists only because of a limitation nobody remembers.

The useful question is not what do you do but what must be true when this is finished. Those produce different lists. The first produces four hundred requirements. The second produces perhaps thirty that actually discriminate between vendors, and a long tail that every serious product handles identically.

Weighted scoring hides the decision rather than making it

Scoring matrices feel objective. In practice they tend to launder a judgement that has already been made, because the weights are chosen after the criteria, and the criteria are chosen by whoever drafted the document.

Two specific failure modes recur:

Undifferentiated criteria dominate the total. If two hundred of your three hundred criteria are things every credible vendor does, they contribute noise proportional to their weight and drown out the twenty that matter. The scores converge, the decision comes down to price, and the institution buys the cheapest system that ticked boxes rather than the one that fits.

Scores are given for the demo, not the product. A vendor demonstrating on curated data with a pre-sales engineer is showing you the best possible day. What you need to know is the worst plausible day: clearing, results release, a failed integration at the point of enrolment.

A more honest structure is to separate criteria into three groups — disqualifying, discriminating, and noise — and to score only the middle group. Disqualifying criteria are pass/fail and need no weight. Noise criteria should be acknowledged and dropped. What remains is a short list of genuine trade-offs, which is what a decision actually is.

Integration is the hard part, and it is scored last

Student platforms do not exist alone. They sit alongside finance, HR, library, access control, VLE, timetabling, CRM, and a set of local systems that exist nowhere else. The value of the new platform is largely determined by how well it participates in that estate.

Yet integration typically appears late in the requirement document, described in general terms ("must provide REST APIs"), and scored as a single line. Every vendor scores well. The differences that matter — whether the API exposes the entities you actually need, whether it supports the volumes involved in a results run, whether events are available or only nightly extracts, what happens when a downstream system is unavailable — are invisible at that resolution.

Our recommendation is blunt: pick your three most consequential integrations and make each one a scored scenario with a defined payload and volume. Ask vendors to describe, specifically, how the flow works, where the data lands, and what the failure behaviour is. The answers separate products faster than any other question.

Data migration decides the timeline

Migration is where optimism concentrates. It is usually estimated as a task rather than a discovery process, which is a category error: you cannot know how long it takes to clean data until you have looked at it.

Three things reliably surprise institutions:

• History is heterogeneous. Records from before a previous system change often follow different rules, and the people who knew those rules have left. Decisions about how to represent them are academic-policy decisions, not technical ones, and they need committee time nobody scheduled.
• The definition of a student is contested. Applicant, offer-holder, enrolled, interrupted, withdrawn, alumnus, and the transitions between them are modelled differently by different systems. Reconciling them is the actual work.
• Cleansing has no natural end. Without an explicit standard for "good enough", teams polish indefinitely or stop arbitrarily.

Estimate migration by sampling before you commit to a date. A week spent profiling the real data will change the plan more than a month of planning.

Governance failure looks like technical failure

When these programmes go wrong, the post-mortem usually blames the platform. Occasionally that is fair. More often the platform was asked to arbitrate a disagreement that the institution had not resolved.

Universities are federated by design. Faculties have legitimate variation in how they assess, progress and award. A platform can accommodate variation, but somebody has to decide which variations are policy and which are habit — and that decision is neither the vendor's nor the implementation partner's to make.

The programmes that go well have a named decision-maker with the authority to say this variation stops. The ones that struggle have a steering group that escalates to consensus, which in a federated institution means the most permissive answer wins, which means configuration sprawl, which means the platform is blamed for complexity it was instructed to absorb.

What we would do differently

If you are early in this process, the highest-leverage moves are unglamorous:

1. Profile the data before writing requirements. It will tell you which requirements are real.
2. Cut the requirement list to what discriminates. Everything else is pass/fail or noise.
3. Turn the top three integrations into scored scenarios with real payloads and volumes.
4. Name the person who can rule a variation out of scope, and make sure the institution knows who that is.
5. Buy the implementation separately from the licence where you can, so the incentive to under-scope the rollout is not sitting with the party who benefits from a fast signature.
6. Treat the demo as marketing. Insist on a hands-on evaluation against your own data, however small the sample.

None of this requires more time than a conventional procurement. It requires spending the same time earlier, on questions that are harder to answer.

The reference call is worth more than the demo

Every vendor supplies references, and most reference calls are wasted because they are conducted as a courtesy. The institution asks whether the client is happy, the client says yes, and both parties get on with their day.

The calls that are worth having are specific, and they are best made to someone in the equivalent role to yours rather than to the executive sponsor who signed the contract. Registry staff will tell you things the CIO does not know.

Questions that reliably produce useful answers:

• What did you have to change about your processes, and which of those changes were unwelcome? Every implementation forces some change. You are looking for whether the changes were reasonable, and whether the vendor was honest about them in advance.
• What took longest, and was it what you expected? If the answer is data migration or a particular integration, you have just learned where your own risk sits.
• What is the upgrade like? This is the question that separates products. A platform that is pleasant to implement and painful to upgrade will cost you far more over a decade than the reverse.
• Who from the implementation team is still on your account? Turnover on the supplier side is a leading indicator of trouble that will not appear in any reference summary.
• If you were starting again, what would you do differently — not about the product, about your own process? This is where institutions are most candid, because the answer does not reflect on the vendor.

It is also worth asking for a reference the vendor did not nominate. An institution that ran the same procurement two years ago will usually take the call, and they have no stake in your outcome. Sector networks make this easier in higher education than in most industries, and it is an advantage worth using.

Where we sit

Raversys works on both halves of this. Our product discovery and strategy practice covers the selection side — data profiling, requirement triage, integration scenarios and the governance question — and we have run it for institutions choosing between platforms rather than buying from us.

Where an institution decides to build or extend rather than buy, that becomes a custom development engagement, and our higher education work includes full university management platforms as well as selection advice.

The two are deliberately separable. An institution that engages us for selection and then buys someone else's product has had a successful engagement, and we would rather be useful at that stage than sell a platform into a decision that has not been properly made.