Rolling Out Virtual Labs Across a School Group

Most edtech is designed, marketed and sold as though the buyer were a single school. A great deal of it is actually bought by someone responsible for twenty schools, or a hundred and twenty, and that person's problem is not the one the sales deck addresses. They are not asking whether the software is good. They are asking whether it will still be good in a school whose intake, timetable, technician capacity and network are nothing like the school where it was piloted.

We build for school groups, and the failure patterns below come from what group-scale buyers and heads of department consistently describe. They are worth writing down, because most of them are avoidable.

Why Do Group-Wide Rollouts Fail?

Rarely because the software was bad. Usually for one of four reasons.

The pilot school was unrepresentative. Pilots naturally happen at the school with the enthusiastic head of science, the good network and the technician who likes new things. That school will make almost anything work. Its success predicts very little about the school with two long-term supply teachers and a saturated wi-fi network.

The rollout was announced rather than adopted. Central procurement can buy licences. It cannot buy the willingness of a head of department to restructure a scheme of work. Software imposed from the centre without departmental buy-in reliably produces high licence counts and low usage, which is the most expensive possible outcome.

Nobody defined what success looked like before starting. If the pilot's success measure is "positive feedback", the pilot will succeed and tell you nothing. Groups that get value define measures they could actually fail against.

Technical variance was discovered late. Device estates in a group are never uniform, however much the IT strategy says otherwise. Finding out in week three of term that one school's Chromebooks are four years older than everyone else's is a recoverable problem in a pilot and a serious one at scale.

How Should a Group Structure a Pilot?

The instinct is to pick one school and run it for a year. We would suggest the opposite: pick three schools that disagree with each other, and run for a term.

Three because one school tells you whether the software works and three tell you whether it works across your actual variance. Choose deliberately for difference: the strongest science department and the most stretched one, the best-resourced laboratories and the worst, and if the group is international, more than one curriculum. If the software survives your hardest case, the rollout is a scheduling exercise. If it only works in the easy case, you have learned that for the cost of one term rather than one year.

A term rather than a year because the useful signal arrives early. If a department has not integrated the tool into a scheme of work within a term, a second term will not fix it, and you have burned a year of budget discovering something week eight would have told you.

What Should You Measure?

Four things, all of which a group can collect without much effort, and none of which is satisfaction.

• Usage depth, not licence activation. How many students completed multiple practicals, not how many logged in once. Activation is a vanity metric and vendors quote it because it flatters them.
• Teacher time. Ask departments to estimate hours spent on lab setup, supervision and marking before and after. It will be rough, and it will still be the number that persuades your finance director.
• Practical skill evidence. If the platform assesses process rather than answers, you have per-student data on technique and safety that you could not previously collect at all. That is worth examining for its own sake, separately from the procurement question.
• Access. Specifically: did the pupils who normally miss practical work take part? Students with attendance difficulties, medical needs, anxiety around laboratory environments, or SEND requirements are the group where virtual labs most often produce an effect that shows up in the data.

Should Procurement Be Central or Devolved?

Central for the contract, devolved for the pedagogy. That split matters more than it sounds.

Groups have real buying power and should use it: one negotiation, one data protection assessment, one integration with the MIS or LMS, one security review. Making twenty schools each run their own vendor due diligence is a waste of twenty people's time, and it produces twenty different answers to the same data protection question, which is a governance problem waiting to happen. Our list of questions to put to edtech vendors is written to be run once, centrally.

But the decision about how a tool fits into a scheme of work belongs to the department teaching it. A group that mandates specific usage patterns across schools with different intakes and different curricula is making a decision it does not have the information to make. Buy centrally, then let departments decide how much of it they use and when.

What Should You Ask Vendors That a Single School Wouldn't?

Five questions that only matter at group scale:

• Does reporting roll up? Can you see one school, one department, one region and the whole group, or does someone have to export twenty spreadsheets and merge them?
• Can content be shared between schools? If a teacher in one school builds something good, can the group's other schools use it, or does the work stay trapped where it was made?
• What is the device floor, honestly? Not the recommended spec. The oldest machine on which it genuinely works, because you own some of those.
• How does onboarding scale? Vendor-led training for three schools is easy to promise. Ask what happens at school fifteen, and whether they can train your trainers instead.
• What happens to our data if we leave? Ask before signing, not during the exit.

How Do You Scale After a Successful Pilot?

In waves, and led by the pilot schools rather than by the centre.

The most effective mechanism is a head of science from a pilot school talking to a head of science from a prospective one. It is more persuasive than anything a vendor or a central team can say, because the concerns are the ones only a practitioner thinks to raise. Groups that build this into the rollout, with a short session per wave run by teachers, get adoption curves that look completely different from groups that send an email announcing licences.

Expect the second wave to surface problems the first did not. That is the wave where you find the network issues, the timetable clashes and the departments who need a different implementation. Budget time for it rather than treating it as a failure of the pilot.

The Underlying Point

A school group's advantage is not that it can buy more cheaply. It is that it can run a genuine comparison, the same intervention in the same term across schools that differ in ways you understand, and reach an evidenced conclusion that no single school could reach on its own. Most groups do not use that advantage, and buy on a demo like everyone else.

If you are going to have the power to run a controlled rollout, it is worth designing one.

Related Articles

• Virtual Lab Software for Secondary Schools: A Buyer's Guide
• 10 Questions to Ask EdTech Vendors After the PowerSchool Breach
• Virtual vs Physical Labs: A Cost-Benefit Analysis
• The Critics Are Right: Most EdTech Is Useless