School technology projects do not usually fail during the build. They fail in the first week of term, in front of everyone, and the post-mortem almost always finds the same cause: the plan had no slack in it.
The structural problem
Most infrastructure work in schools happens in the holidays, because that is the only time the buildings are empty. A summer break gives you a decent window; a two-week break between terms gives you almost nothing once you subtract public holidays and the days staff are actually on site.
So the plan gets built backwards from the immovable date, which produces a schedule where every task starts the moment the previous one finishes. That plan works only if nothing goes wrong. Nothing going wrong is not a thing that happens in infrastructure.
What actually goes wrong
The same small set of things, over and over:
- Delivery slips. Hardware ordered in good time arrives four days late. Everything downstream compresses.
- The building is not what the drawings say. A conduit is full, a wall is not where it should be, an asbestos register turns a two-hour job into a two-week one.
- An undocumented dependency surfaces. The bell system, the door controllers or the PA turn out to depend on the switch you just replaced, and nobody knew because the person who installed it left in 2019.
- A third party doesn’t show. The carrier, the electrician, the cabler. Schools are rarely anyone’s highest-priority customer during holidays, because everyone else is doing holiday work too.
- Testing was scheduled with an empty building. Which tests nothing about how the system behaves with 800 people in it.
The specific failure of week one
The most common pattern I see is a project that technically completed. Everything is installed. Everything was tested. Everything works.
Then term starts and the wireless falls over at 9:05am because thirty devices per classroom is a completely different load profile to the four laptops used during commissioning. Or the new authentication works perfectly for staff accounts, and nobody tested a student account because there were no students on site. Or the printers work from the staff network and not from the student one.
These are not exotic faults. They’re the predictable consequence of validating a system in conditions that do not resemble its operating environment.
What to do instead
Finish a week early, deliberately
Plan the work to complete with a full week of buffer before students return, and treat that buffer as part of the project rather than contingency to be spent. If you finish on time, that week is used for load testing and staff familiarisation. If you don’t, it absorbs the slip. Either way it earns its place.
Stage the risky thing first
Sequence work so the item most likely to surprise you happens at the start of the window, not the end. If the recabling is the unknown, do the recabling first. Discovering a problem on day two of a three-week window is a manageable event. Discovering it on day sixteen is not.
Test with realistic load
You cannot fully simulate 800 students, but you can do far better than four laptops. Bring in a class worth of devices and run them concurrently in one room. Use synthetic load generation on the wireless. Log in as an actual student account, on an actual student device, on the actual student network.
Map the dependencies before you touch anything
Before replacing any core infrastructure, walk the site and identify every system that might be hanging off it. Bells, PA, door access, alarms, CCTV, HVAC controls, the eftpos terminal in the canteen. Schools accumulate these over decades and they are almost never documented.
Have a rollback that someone has actually thought about
Not “we’d put the old one back”. Specifically: is the old equipment still on site, still configured, and can it be reinstated in an afternoon? Keep the old kit in the comms room until week three of term, not until the day the invoice is paid.
The awkward conversation worth having
Sometimes the honest answer is that the work does not fit in the window available. A two-week break is not enough to recable a building, replace core switching and migrate authentication.
Saying so is uncomfortable, because the funding often has a deadline and everyone wants it done. But a project split across two holiday windows, delivered properly, is far better than one compressed into a single window and delivered broken. The cost of a failed week one, in staff goodwill and principal confidence, is much higher than the cost of waiting a term.
I have never regretted delivering less, later, and having it work.