Most Groups Choose the Wrong System for the Right Reasons

I have sold nursery software, bought it as an operator, and assessed it in diligence. The same failure shows up from all three seats, and it has almost nothing to do with the software.

Selection processes go wrong long before anyone books a demonstration. They go wrong at the point a group writes down what it wants, because what most groups write down is a list of things their current system does badly. That is a list of complaints. It is not a decision about how the group intends to operate.

What follows is the five places I see it break.

1. The Requirements List Is Written Backwards

Ask a group what it needs from a new system and you will get the frustrations of the last two years. Occupancy reporting that nobody trusts. A funding process that takes three days a term. Invoices that go out wrong.

Every one of those is real. None of them is a requirement. They describe the system you are leaving, not the group you are trying to become.

The question that produces a good requirements list is what the group will look like in three years, at what size, with what central function, and which decisions will need to be made weekly rather than termly. Answer that and the requirements write themselves. Skip it and you will buy a better version of what you already have.

2. Nobody Prices the Migration

Data migration and parallel running are the two largest costs in any system change and they appear in almost no proposal, because they are not the vendor's costs. They are yours.

Historic funding records, child records, staff qualifications and safeguarding files rarely map cleanly from one system to another. Somebody has to decide what transfers, what is archived and what is rekeyed. That work lands on the people who are also running settings.

The groups that come through a migration well are the ones that budgeted for it as a project with a named owner. The groups that struggle are the ones that treated it as something the vendor would handle.

3. Integration Is Treated as a Feature, Not an Architecture

Integration appears on evaluation matrices as a row with a tick in it. That tells you a connection exists. It tells you nothing about what flows, in which direction, how often, and what happens when it fails.

The joins that matter are the ones between your nursery system, your finance system, your funding process and your safeguarding records. Those four are where the group's operating data lives, and the quality of the joins decides how much manual work sits underneath your reporting for the next five years.

A group buying a system is buying an architecture whether it thinks about it or not. Better to think about it.

4. The Demonstration Is Run for the Wrong Audience

The people in the room for a demonstration are usually the people who will report on the system. The people who will live in it every day are usually in a setting, working.

That matters because the two groups are optimising for different things. Head office wants visibility. A room leader wants to record an observation in nine seconds while supervising eight children. A system can be excellent at the first and hopeless at the second, and only one of those failures shows up in a demonstration.

If a nursery manager and a room leader have not used the system unsupervised, on their own device, with their own hands, you have not evaluated it.

5. Total Cost of Ownership Is Never Modelled

The licence fee is the visible number and usually the smallest one. Around it sit implementation, migration, training, the internal time cost of parallel running, integration build and maintenance, and the ongoing cost of whatever the system does not do that somebody now does in a spreadsheet.

Model those across five years and the ranking of the shortlist frequently changes. Groups that model only the licence are comparing the cheapest part of four different numbers.

What to Do About It

Three things, none of which involve talking to a vendor.

Write the operating model first. Size, structure, central function, decision rhythm. The requirements list is a consequence of that document, not a substitute for it.

Build the total cost of ownership model before the shortlist, not after it. If you cannot populate it, you are not ready to choose.

Put the people who will use the system daily in front of it, unsupervised, before anyone signs anything.

Our Technology Selection Framework sets out the evaluation criteria we use, including the questions most groups do not think to ask.

The system is rarely the constraint. The clarity about what you are asking it to do almost always is.