Product guides
Why school software projects fail before the demo
A school software project can fail before a vendor demo if the school has not agreed on the problem, owners, data, and first measurable outcome.
The demo is not the starting line
A polished demo can make every system look ready. It cannot decide which records your school trusts, who owns each workflow, or what must work on the first day of a new term. Those decisions belong to the school before the vendor conversation.
Start with one operational story. For example: an applicant becomes an enrolled student, receives a fee plan, joins a class, and becomes visible to the right family members. If the story breaks at a handoff, record the break instead of hiding it behind a feature list.
A short process map is enough to expose the first constraint. Put each handoff on one line, write the person responsible beside it, and mark the point where a missing or conflicting value stops the next step.
Five questions to answer before comparing products
Name the source of truth for students, guardians, staff, fees, and academic dates. Then name the person who can approve a correction. A shared system is only useful when the school has shared definitions and accountable owners.
- Which workflow causes the most re-entry or delay today?
- Which records must be correct before families receive access?
- Which roles may view, edit, approve, or publish each record?
- What can the school test with real but non-sensitive sample data?
- What result would justify moving beyond the first phase?
Treat data protection as part of selection
The GOV.UK guidance on procuring educational technology recommends involving the data protection officer early and checking responsibilities, security measures, sub-processors, deletion or return of data, breach notification, and staff access control. Those are procurement questions, not paperwork to postpone until implementation.
A vendor should be able to explain its product boundaries without asking the school to accept unsupported claims. Record the answer, the source, the owner, and the date it was checked.
A better next step
Before the next demo, create a one-page workflow brief. Include the current process, the desired first-phase process, owners, required data, permission risks, test cases, and the decision you need from the vendor. The brief makes the demo a working session rather than a performance.
