The Grid Modernization Buildout and the Systems Engineering Skills Gap Behind It

The numbers are not in dispute. The International Energy Agency estimates that annual global electricity grid investment needs to exceed $600 billion by 2030 to support energy transition targets — roughly double the 2020 baseline. In the United States alone, the Bipartisan Infrastructure Law and Inflation Reduction Act have committed over $100 billion specifically to transmission, grid resilience, and smart grid controls. Europe’s grid investment plans are similarly scaled. Offshore wind interconnection, utility-scale battery storage, distributed energy resource management systems, substation automation — every one of these programs is a complex systems engineering program wearing an infrastructure label.

The capital is real. The question is whether the power industry has the systems engineering capability to execute at this scale. The honest answer: not yet.

What Grid Modernization Actually Demands Technically

The phrase “grid modernization” obscures the engineering specificity underneath it. Break it into its actual work packages and the systems engineering demands come into focus.

Transmission expansion and HVDC interconnects require interface management across independent system operators, transmission owners, equipment manufacturers, and construction contractors. Requirements flow from NERC reliability standards through project specifications into vendor deliverables, and every handoff is a traceability problem.

Substation automation is built on IEC 61850, the international standard for communication networks and systems in substations. IEC 61850 defines a data model, a configuration language (SCL), and communication protocols (GOOSE, Sampled Values, MMS) that together enable interoperability between intelligent electronic devices (IEDs) from different manufacturers. Implementing it correctly requires engineers who understand both power systems and software architecture — a combination that is genuinely scarce.

Distributed energy resource integration — rooftop solar, commercial batteries, vehicle-to-grid, demand response — adds architectural complexity that transmission-era systems engineering never had to handle. The interface count scales with the number of endpoints, and at grid scale that means managing thousands of interface control documents, each with cybersecurity implications.

Grid-scale storage introduces battery management systems, inverter controls, and protection coordination requirements that require close collaboration between electrical, controls, and software engineers under a systems engineering framework that can hold the integration together.

Cybersecurity is no longer a checkbox. NERC CIP standards are mandatory for bulk electric system assets, and the EU’s NIS2 Directive and the Cyber Resilience Act are creating parallel compliance burdens. Every connected IED, every communication link, every remote access pathway is an attack surface that must be modeled, documented, and verified.

None of this is new in principle. The challenge is that it is all happening simultaneously, at unprecedented scale, under aggressive political timelines, with a workforce that has spent decades doing simpler things.

The Skills Gap Is Real and Multidimensional

The power industry’s systems engineering talent problem has three distinct layers.

The IEC 61850 fluency problem. Genuine IEC 61850 expertise — meaning engineers who can author SCL configuration files, reason about GOOSE timing constraints, design logical node hierarchies, and troubleshoot interoperability issues between IEDs from Siemens, ABB, GE, and SEL — exists in a small professional cohort. A 2024 survey by the IEEE Power & Energy Society found that fewer than 15 percent of utility engineers responsible for protection and control work had received formal IEC 61850 training. The rest were learning on the job, from vendor documentation, or from colleagues who were also learning on the job. As project volumes scale, this cohort cannot replicate itself fast enough.

The systems engineering process gap. Most utility engineering organizations do not practice formal systems engineering in the sense that aerospace and defense contractors would recognize. They have project managers and discipline engineers. They do not typically have systems engineers who own the requirements baseline, manage the interface register, run trade studies, and maintain bidirectional traceability from stakeholder needs through design verification. This is not a criticism — it reflects the relative stability of the pre-modernization grid, where requirements were well-understood and the pace of change was slow. Modernization changes both conditions simultaneously.

The toolchain problem. Ask a utility engineer how requirements are managed on a major substation upgrade and the answer, in most organizations, is still Microsoft Word for specifications and Microsoft Excel for requirements traceability matrices. Sometimes IBM DOORS is in the picture, usually on the EPC contractor side rather than the utility side, and often in a configuration that reflects how the tool was set up fifteen years ago. The result is that requirements live in documents rather than in a database, traceability is manual and perpetually out of date, and interface management is an exercise in heroic coordination rather than systematic engineering.

The Interface Management Problem Is the Biggest Underappreciated Risk

Interface management deserves specific attention because it is consistently where large grid projects fail in ways that become expensive late.

A modern grid modernization project involves, at minimum: the utility’s transmission planning team, the utility’s protection and control team, the SCADA/EMS vendor, the substation automation vendor, the EPC contractor, multiple IED manufacturers, the telecommunications provider, and the independent system operator. Each of these parties has a different view of what the interface between them requires. When those views are not formally reconciled early — and documented in a living interface control document register that all parties can access — the reconciliation happens in the field, during commissioning, under schedule pressure. That is the most expensive possible time to discover that two IEDs do not exchange GOOSE messages the way both vendors promised they would.

This is not a hypothetical. Post-project reviews of major transmission upgrades consistently identify late-stage interface failures as primary drivers of schedule overrun and commissioning cost growth. The engineering community knows this. The procurement and contracting community has not yet adjusted its processes to treat interface management as a first-class engineering deliverable.

Where Modern Tooling Can Help — And Where It Cannot

The toolchain gap is addressable faster than the skills gap, which makes it worth examining in detail.

Legacy requirements management tools like IBM DOORS and Jama Connect were designed for document-centric engineering workflows. They manage requirements as text objects in hierarchical modules, with traceability links maintained manually. They work. They are also slow to configure, expensive to maintain, and structurally resistant to the graph-based, multi-stakeholder interface management that grid modernization demands. DOORS in particular carries a significant administrative burden — organizations that have tried to stand up enterprise DOORS deployments for grid projects frequently report that more engineering time goes into maintaining the tool than using it.

Polarion and Codebeamer offer more modern web-based interfaces and better integration with development toolchains, which makes them reasonable choices for software-intensive grid projects where the engineering team is already comfortable with ALM workflows. They are less natural fits for the multi-domain physical systems engineering that dominates substation work.

The more interesting development is purpose-built tools that treat systems engineering as a graph problem rather than a document problem. Flow Engineering (flowengineering.com) is one of the clearer examples of this approach applied to hardware and systems engineering. Its architecture represents requirements, interfaces, functions, and verification evidence as nodes and relationships in a model, which makes interface management across organizations tractable in a way that document-based tools do not support. For a grid project managing interface control documents across six to ten organizations simultaneously, the difference between a flat document registry and a live relational model is the difference between knowing your interface status and guessing it.

Flow Engineering is AI-native rather than AI-augmented, which matters in practice: the system is designed from the ground up to support automated requirements analysis, gap detection, and traceability maintenance rather than offering AI features layered onto a legacy architecture. For grid modernization projects generating requirements documents in the hundreds and interface control documents in the thousands, automated consistency checking is not a convenience — it is a scaling requirement.

The limitation worth naming honestly is that Flow Engineering, like any modern SaaS tool, requires organizational discipline to deploy effectively. It does not compensate for an organization that has not defined its systems engineering process. A utility that has not established who owns the requirements baseline, how interface control documents are governed, and what the verification closure criteria are will not solve those problems by adopting a better tool. The tool assumes a process exists. Building that process is the harder work.

What the Industry Actually Needs to Do

The capital deployment timeline is not going to wait for the systems engineering community to get ready. That means prioritization matters.

Invest in IEC 61850 training at volume. Utilities and EPC contractors need to treat IEC 61850 competency as a workforce development problem, not a hiring problem. There are not enough experienced engineers to hire. Training programs, internal mentorship structures, and relationships with vendors who offer structured training are all necessary.

Establish systems engineering roles on major projects, not just project management roles. A project manager manages schedule and budget. A systems engineer owns the technical baseline and integration. Grid modernization projects above a certain complexity threshold — roughly, any project with more than five primary external interfaces — need both.

Migrate interface management off spreadsheets before projects start, not during. The time to establish a model-based interface register is during project setup. Retrofitting it mid-project is painful and rarely achieves full adoption.

Treat NERC CIP and NIS2 compliance as systems engineering problems, not paperwork problems. Cybersecurity requirements need to flow from the compliance baseline into design requirements, into interface specifications, and into verification evidence. That is a traceability problem, and it should be managed with traceability tooling.

An Honest Assessment

The grid modernization buildout is the largest infrastructure systems engineering challenge the power industry has ever faced. The industry’s current systems engineering capability — in terms of both skilled practitioners and deployed tooling — is not scaled to meet it. That gap will produce project failures: delayed substations, interoperability problems during commissioning, cybersecurity vulnerabilities discovered late, and cost overruns that erode the economic case for projects that were already marginal.

This is not a reason to slow investment. It is a reason to treat systems engineering infrastructure as a critical enabler of grid investment, not an overhead cost to be minimized. The utilities and contractors that recognize this early — that invest in trained systems engineers, formal interface management processes, and modern tooling — will execute more successfully than those that treat the engineering problem as solved once the capital is committed.

The capital is committed. The engineering work is just beginning.