Shipping software to universities — what actually goes wrong
Lessons from the field after rolling out PRASH to 300+ tenants. Procurement, change-management and the silent killers of campus IT projects.
We shipped PRASH — a rent and tenant operations platform — to Parul University over fourteen months. Three hundred and forty-two active tenants at go-live, six concurrent operational teams, and a regulatory environment that punishes documentation gaps. Looking back, the things that almost killed the project weren't the things we'd planned for.
Most write-ups on enterprise software roll-outs are about engineering. This one isn't — almost every failure mode we hit was organisational. If you're building software for a university, a college group or any large educational institution, these are the four things we wish we'd known going in.
1. Procurement is the project
The single biggest delay we faced wasn't a technical one — it was the procurement cycle. From the day a department head says yes to the day a purchase order is signed, expect six to fourteen weeks. There are usually three approval layers (department, finance committee, vice-chancellor's office), and each one wants something you didn't put in the previous version of the proposal.
What worked for us: writing the procurement note before the technical proposal. Treat the PO document as the actual project artefact — because if it's wrong, nothing else matters. Include the support SLA, the IP terms, the exit clause and the payment milestones. Get someone from the university's purchase office to review the draft before formal submission; they will know what their own committee will flag.
2. Change management beats feature richness
The estate management team at our client had been running the rent operation in spreadsheets for nine years. They were good at it — better, in many ways, than our software was at launch. The first three weeks after go-live were the hardest of the project, not because the software was broken, but because two senior staff who had owned the spreadsheet workflow felt — correctly — that their expertise had been written out of the system.
What worked for us: making those two people the named owners of the configuration. Every business rule in PRASH lived in a configuration screen they controlled. We removed our engineering team's ability to change those rules in production. Once the workflow was theirs again, adoption flipped overnight.
- Identify the spreadsheet owners before the kickoff meeting — they are your real stakeholders
- Make them co-designers, not training recipients
- Hand them the keys (config, reporting, exception flows) on day one
- Resist the urge to "tidy up" rules they have refined over years
3. Data migration takes three times as long as you think
The university gave us five Excel files at the start. We assumed those were the source of truth. They were not. The actual source of truth was four spreadsheets, two Tally exports, a printed deposit register going back to 2017, and a WhatsApp chat history. We spent six weeks reconciling these into a single dataset — six weeks that were nowhere in our original plan.
What worked for us: running data migration as its own discovery sub-project, in parallel with the build. We hired one analyst whose only job was to chase down, validate and normalise the historical data. By the time the application was ready, the data was clean — and that staff member became the de-facto data owner inside the university, which solved a problem we hadn't known we had.
4. Outages are political events, not technical ones
Two weeks after launch, the platform was down for forty minutes during fee-collection peak. Technically, it was a recoverable database failover that played out exactly as designed. Politically, it was a near-cancellation event — the finance head's morning had been disrupted, and the conversation in the next steering-committee meeting was about reverting to spreadsheets.
What worked for us: a same-day written incident report, addressed by name to the people who had been affected. Plain language, specific timeline, specific fix, specific prevention. Send it the same day, not three days later when the operations team has gone through five revisions of the wording. The transparency bought back trust faster than any uptime metric ever would have.
- Procurement timelines dominate everything — plan backwards from PO date
- The spreadsheet owners are your real stakeholders; make them co-designers
- Data migration is its own project — staff and time-box it separately
- Communicate outages in writing, the same day, by name
The technical work of shipping software to a university is straightforward — it's a multi-role web app with a defined operational scope. The hard work is everything else: navigating the approval matrix, earning the trust of the people whose expertise you're partly automating, and being honest about failure when it happens. If you're scoping a campus software project, budget twice as much time for those things as you would for any commercial deployment. You will need it.
We're happy to share the actual templates we used — the procurement note, the change-management plan and the incident-report format. If they'd help you, drop a line.
Want to talk to the team that shipped this?
We share notes, templates and a 30-minute call with no sales follow-up unless you ask for one.
