Battle of the Methodologies: Why Systems Engineering Beats Pure Agile in OT Projects in Energy Sector

I’ve spent most of my career in the railway and energy environments focusing on large scale projects with critical systems and operational technology (OT). Often, I’ve seen technology upgrades control systems, secondary systems, industrial comms overhauls, or cyber tooling rollouts—tackled like your standard IT sprint.

It is quick, it is flashy, and it gets executives nodding particularly with the promise of an uplift to regulatory frameworks/maturity models. But when you’re dealing with long asset lives, operational stability on the line, and regulators applying (well deserved) pressure, that approach starts to crack.

A proper systems engineering mindset, backed by Reliability, Availability, Maintainability, and Safety (RAMS) analysis, isn’t just better—it’s essential for keeping critical systems operational without nasty surprises.

Classic Constraints – Speed versus Quality

Walk into most technology project meetings, and you’ll hear talk of backlogs, sprints, and “minimum viable products.” It makes sense for web apps or CRM tweaks, but for control systems these aren’t sufficient as the nervous system of the operations. From my time consulting on such projects, the pattern is clear:

Teams frame everything as “IT change,” even when it ripples through field devices, comms networks, and ops rooms. Requirements come as user stories—”As a trader, I want real-time Distributed Energy Resources (DER) visibility so I can balance the network.” Fine for features, but where’s the bit on failover times, cyber zoning, or how these plays with legacy operational equipment? Late-stage UAT becomes a firefight, with network planners and safety leads scrambling to sign off.

Please don’t get me wrong—agile has its place, but treating OT like a software drop ignores the physics of power systems.

Energy vs Rail: Lessons from Signalling Projects

Look across the fence to rail OT—signalling, Communications-Based Train Control (CBTC) and European Train Control System (ETCS) Australian projects such as Metro Operations or High Capacity operations don’t risk pure agile, even in traditional day to day  changes to signalling technologies.  They mandate systems engineering and RAMS from the jump, replacing fixed-block systems with moving-block tech while proving safety through fault trees, hazard logs, and RAM models. Take a look at the comparative table below:

Rail’s hybrid model where waterfall gates for signalling design and agile for software —delivers capacity boosts without compromising punctuality or safety. Energy sector could borrow such a model. Imagine SCADA upgrades with rail-style RAMS proving no added outage risk –the stakes are similar — public safety, billion-dollar assets — but rail’s discipline shows why pure agile falters in true critical infrastructure projects.

The Good, The Bad, and The Ugly of Agile in Energy OT

Horses for Courses

Agile shines in a few spots. Those demo sessions? Gold for winning over skeptical stakeholders who hate endless Gantt charts. And with DER exploding and regs shifting (hello, National Electricity Regulator updates!), the flexibility to pivot mid-project keeps things relevant. Vendors love it too—syncing sprints with their SaaS cycles cuts through procurement headaches.

Where It Falls Flat

Here’s the rub: energy OT is a web of interactions. One comms tweak can cascade into protection misoperations or blackouts. Agile backlogs chase features, not system-level outcomes like availability or safety degraded modes.

Lifecycle gaps hit hard. No one’s modelling Mean Times Between Failures (MTBF) or repair loops upfront, so you are blindsided by spares shortages years later. Regulators want evidence—safety cases, compliance trails—not a Jira board. And ops teams? They’re not built for constant flux; it spikes error risks and burns out control room staff.

I have seen projects ship “value early,” only for the full system to need a rip-and-replace because no one stress-tested the interfaces.

Systems Engineering: The Missing Piece

Systems engineering flips the script. It’s not about drowning in docs—it is structured thinking from day zero. Start with a Concept of Operations (ConOps): what does success look like in steady state, storm conditions, or cyber incidents? Then layer in requirements that stick—performance targets, resilience specs, human factors—all traced to business drivers like outage minutes or capex efficiency.

In energy, this holistic lens catches the gotchas. Architecture views span substations to control centres, flagging single points of failure early. Trade-offs get quantified: more redundancy here, simpler maintenance there. And it scales to long lives—config control, modularity for upgrades, even decommissioning plans.

Pair it with agile execution: engineer the frame, sprint the builds. I’ve pitched this hybrid to clients, and it lands because it delivers fast wins without the chaos.

RAMS: Making Reliability Real

Enter RAMS—Reliability, Availability, Maintainability, Safety. This isn’t just some fluffy concept; it is founded on maths and models proving your OT upgrade won’t tank grid performance.

Picture a SCADA rollout. RAMS runs Monte Carlo sims on outage risks, pinpoints weak spots in comms bearers, and sizes redundancy. Maintainability? Designs for hot-swaps and remote diagnostics slash downtime. Safety weaves in: how does a partial failure affect protection schemes?

For Distribution Network Service Providers (DNSPs) chasing network reliability targets, or generators dodging production losses, RAMS turns gut feels into boardroom ammo. “This option costs 10% more upfront but saves $2M in forced outages over 20 years.” Regulators eat it up too—tangible assurance for DISP, Essential Eight, or safety duties.

In my projects, skipping RAMS meant retrofit pains; doing it early saved millions and headaches.

Five Ways to Fix It

Enough theory—here’s how DNSPs and generators can address these:

1. Classify OT Right: Label SCADA, teleprotection, or security platforms as systems, not apps. Kick off with systems engineering gates, agile inside.
2. RAMS at Concept: Workshop hazards and metrics before budgeting. Shape everything downstream—like rail ATC and CBTC systems.
3. Own the Non-Functionals: Set hard targets—e.g., <5min Mean Time To Response, 99.99% uptime—and verify them like functionals.
4. Trace Everything: User stories link back to system requirements. No orphans.
5. Assure for the Long Haul: Build artefacts that double for regs—RAMS reports, interface docs, V&V matrices. Ops gets stable baselines per release.

Parting Shot

Pure agile in OT feels good short-term but bites long-term—rail proves it with signalling wins that energy could emulate. Systems engineering with RAMS builds resilient grids that hum for decades, not sprints. For Aussie energy players staring down net-zero and cyber threats, it’s not optional—it’s how you stay ahead. I’ve lived the difference; your next project deserves it.