Why the Department Keeps Building and Retiring the Same Tool

Every state education department has, at some point, tried to build its own governance tool for schools.

It is almost always the same story.

A need is identified. A team is convened. A platform is specified. A vendor is engaged or an internal build is kicked off. The system goes live. Principals are trained, sometimes, or told to use it, often. Data starts flowing, partially. The project shifts into maintenance. A new Chief Executive arrives, or a new Minister, or a new strategic plan. The tool is reviewed. Its limitations are catalogued. A new version is commissioned. The cycle restarts.

South Australia has done this at least three times in the last decade. The other states have their own versions of the same arc.

This is not a criticism of the teams involved. Every one of those projects was competently run by people trying to do the right thing. The pattern is structural, not personal.

Why It Keeps Happening

Departmental tool-building fails for a specific reason. The tool is being built by the centre, for the centre, with the site as a data source.

Principals fill it in because they have to. The system is optimised for what the Department needs to report on, not for how the school actually runs. The data entry feels like extra work, because it is.

Within eighteen months, compliance with the tool starts to degrade. Sites that are resourced can maintain it. Sites that are stretched cannot. The data the Department receives becomes patchy. The patchiness is interpreted as a capability problem at the site, rather than a design problem at the centre. The response is usually more mandated reporting, which accelerates the degradation.

By the time the tool is retired, its reputation inside schools is irrecoverable. The next tool, when it arrives, inherits that reputation before the login page has even been built.

This is the cycle.

The Three Structural Problems

There are three problems that keep recurring across these builds.

First, the tool is scoped to a single Ministerial priority. Whatever the political focus is at the moment of commissioning becomes the centre of the product. When the priority shifts, the product becomes peripheral.

Second, the tool is built inside the ICT capacity of the Department. This means it competes with every other system the Department needs to maintain: payroll, enrolment, reporting, finance, HR. When budget or attention gets squeezed, the governance tool is usually first to be deprioritised. Maintenance falls behind. Features that were promised do not land. Users lose confidence.

Third, the tool is designed without a sustainable relationship to site practice. It is rare for a Departmental build to have embedded users from Principals, Deputies and Administrators throughout the build and the lifecycle. Where this does happen, the tool is usually better. Where it does not, the tool becomes a reporting artefact rather than an operational one.

Each of these problems is solvable in principle. In practice, the incentives inside a Department make them extraordinarily hard to solve in the same build.

The Opportunity Cost

The cumulative cost of this cycle is not just the build budgets.

It is the ICT capacity that could have been used for the things only a Department can do: integrations with payroll, enrolment, safeguarding databases, finance systems. Every year spent rebuilding a governance tool is a year of system-level integration work deferred.

It is the capability loss when a build is retired. Institutional knowledge about what worked and what did not leaves with the project team. The next team rediscovers the same lessons at the same cost.

It is the trust erosion. Each generation of retired tooling makes Principals more cynical about the next announcement. By the third cycle, launch communications are treated as noise before the login even opens.

And it is the data graveyard. Each retired system leaves behind schema, historical records, and partial datasets that either get migrated poorly or abandoned entirely. The sector's ability to look at longitudinal patterns in its own governance data is significantly worse than it should be, precisely because of this history.

What the Alternative Looks Like

The alternative is to not build it.

Not as a surrender. As a structural choice.

A governance tool for public schools does not have to be built inside the Department. It can be licensed as infrastructure, the same way no Department builds its own email system or its own video conferencing platform.

When it is licensed:

• The Department stops spending ICT capacity on rebuilds.
• The lifecycle risk moves off the Department's balance sheet.
• Maintenance is funded by the vendor's other customers too, spreading the cost.
• The tool evolves on a vendor's roadmap, which is usually faster than an internal build's roadmap.
• When a Minister changes or a strategic priority shifts, the tool does not need to be retired and rebuilt. It reconfigures.

This is the shared rail model. The Department still decides what the tool reports. The Department still configures the compliance calendars, the frameworks, the reporting expectations. What the Department stops doing is carrying the software lifecycle itself.

What a Vendor Has to Prove

For the licensed model to work, the vendor has to prove a specific set of things.

Sovereign Australian infrastructure. Not a US-hosted cloud service with a marketing overlay. Actual Australian data residency and Australian legal jurisdiction.

ISO 27001 alignment, with evidence. Not aspirational. Actual.

A procurement pathway the Department can use without custom contract drafting. Go2Gov, panel placement, or standard DfE contract terms.

A commercial model that scales with the portfolio, not with the site. The pricing cannot assume twelve Principals independently signing cheques. It has to assume a centre-deployed, site-configured, centre-reported architecture.

Founders and an engineering team who are not going to be acquired, pivoted, or become subsidiaries of a company whose priorities sit in a different jurisdiction.

And, critically, a product that is usable by Principals. Because if the tool does not reduce friction at the site, the licensed model fails the same way the internal builds did.

The Policy Case

There is a policy case for this beyond procurement convenience.

Public education departments have, collectively, spent a significant amount of public money building and retiring the same category of tool. That money came out of envelopes that could have funded teacher development, student support, infrastructure, or capability programs. The rebuild cycle is a tax the sector is paying on the absence of shared infrastructure.

A licensed, shared-rail approach lets Departments step out of that tax.

It also creates a healthier ecosystem. A vendor with multiple state Department customers has the scale to invest in product depth no single Department could afford to build. Features funded by one jurisdiction become available to all of them. The professional practice of public school governance starts to travel across borders, because the infrastructure carrying it is shared.

Take the Next Step

If this article speaks to your situation, two routes from here.

Go deeper on the verb. Read the Oversee cornerstone. It is the deep page that sits underneath every article in this category.

See it on your site. Book a Governance Review. 45 minutes. No deck. We measure what the friction is costing you and whether EthosGov reduces it measurably.

---

Part of the EthosGov resources library. Governance infrastructure for public school systems. Lead. Improve. Assure. Oversee.