CEDX Forge

Replacing a six-month build with three weeks of configuration.

The internal tool nobody had staffed for two years shipped in a sprint, with the same roles and audit trail as everything else.

Outcome

3 weeks to production

Customer
Gridworks
Sector
Electricity distribution network operation
A team working through a problem at a shared desk
A team working through a problem at a shared desk.
Scale
2,340 staff, 1.9 million connections
Duration
Three weeks from first workshop to production
Rollout

4 phases, in the order they happened.

  1. Week 1

    Data model and approval flow agreed with two switching engineers and the control room supervisor.

  2. Week 2

    Forge build: six forms, four tables, three roles from Gate, revision rules written in Script.

  3. Week 3

    Asset register connected through Link, two correction rounds, production release on the Friday.

  4. Week 7

    A second tool (jointing crew allocation) built in four days by Gridworks' own team, without us.

What changed, measured.

Every figure came from Gridworks. Where one is a median or a sample it says so.

3 weeks

First workshop to production

Against a six-month estimate held on the roadmap since 2022.

340

Planned outages a year

Now scheduled, revised and approved in one place.

4 days

Second tool, built without us

Jointing crew allocation, delivered by Gridworks' own team in week seven.

1

Audit trail

The platform's own, accepted at incident review without a separate assurance case.

The programme

The tool nobody would fund.

Every planned outage at Gridworks needs a switching schedule: the order in which circuits are isolated and restored, the plant involved, and sign-off from three separate parties. All of it was tracked in a workbook on a shared drive, under a naming convention that two people fully understood.

A replacement had been on the roadmap since 2022 as a six-month build with a number attached. It never reached the top of the list, because it was always smaller than whatever sat above it and never small enough to slip in beside something else.

Meanwhile: 340 planned outages a year, an average of fourteen revisions each, and a file that only one person could edit at a time.

Why the six-month estimate was honest.

It is tempting to say the estimate was inflated. It was not. The build would genuinely have taken six months, because most of the six months was not the tool.

It was authentication against the corporate directory, a permission model matching the three approving parties, an audit trail an engineer could defend at an incident review, and an integration to the asset register so that a switching schedule references real plant rather than a typed description. Those four are the same on every internal tool this company will ever build, and rebuilding them per tool is where the six months goes.

Forge is worth having precisely because those four stop being the project.

Three weeks, and the same audit trail as everything else.

Week one was the data model and the approval flow, drawn on a whiteboard with the two switching engineers who write most of the schedules and the control room supervisor who signs them.

Week two was the build: six forms, four tables, three roles, and the revision rules in Script. Roles came from Gate, so each of the three approving parties was an existing group rather than a new list to maintain. Week three connected the asset register through Link and ran two rounds of correction with the same engineers.

It is not a beautiful piece of software. It replaced a workbook, and it is measurably better than the workbook.

The six-month number was never wrong. It was the price of building the boring four-fifths again. We paid that once, on the platform, and the tool itself took three weeks.

Callum WhyteHead of Network Control, GridworksRunning CEDX Builder
Next

See what Builder does before you read another story.

Low-code apps on CEDX data. There is a full trial on builder.cedxsystems.com, and an engineer who has run a migration like this one will walk it with you.