Why can a new project wait so long to connect, even where the network has room for it? Part of the answer is the connection process itself.

Recently, we’ve spent a lot of time working with both network businesses and developers trying to connect wind, solar, batteries and, increasingly, large data centre loads. That has given us a useful view from both sides of the connection process.

The pressure to connect is building. In the DNSPS and TNSPS we work with, connection applications are up two to three times since 2023. Connection teams have stayed largely the same size and the process often hasn’t been revisited for a number of years.

Networks are dealing with more connection enquiries, a constrained network, larger loads, increasingly complex technical requirements and a regulatory environment that can be difficult to navigate. Bottlenecks can emerge at multiple points in the process and customers are placing pressure on governments and executive teams to prioritise their projects. Additionally, in response to uncertainty over connection timings and costs, some developers are progressing multiple sites or submitting enquiries across different networks as a hedge against uncertainty over where and when they might secure a viable connection. This creates more noise in the system.

For developers, the stakes are significant. A wind farm, battery, industrial facility or data centre can have compelling economics, land and funding, but without an agreed grid connection it may simply not proceed. Connection certainty therefore has a direct bearing on investment decisions.

Customers want to know:

• Where can we connect?
• How long will it take?
• What will it cost?
• What information do we need?
• What could delay us?
• How confident can we be that the pathway we’re pursuing will still be viable in several years’ time?

For network businesses, the challenge is just as real. They’re being asked to assess a growing pipeline of projects while managing finite engineering resources and network capacity. Not every project entering that pipeline will ultimately proceed.

More network investment will clearly be required, but building more infrastructure is only part of the answer. There’s also a significant opportunity to improve how the connection journey itself works.

So how can we reduce time to connect, cut through the noise and give developers greater certainty without compromising technical assurance, system security or decision quality?

From our observations, leading network businesses are progressing 4 key strategies:

1-Make it easier for customers/developers to get the application right the first time

A surprising amount of effort in the connection process is spent on avoidable back-and-forth. Customers want to understand where connection is feasible, what information is required, what studies will be needed, how the process works and how long each stage might take. Experienced developers build this knowledge over time but that is part of the problem.

A good process should not become easy only after you have learned how to navigate it through repeated experience.

For less experienced proponents, connection and registration requirements can be difficult to interpret. Requirements can involve several teams and organisations, making it difficult for the customer to understand what is really holding up progress.

There’s an opportunity to make the process much easier to navigate. Clearer guidance, digital forms, readiness checks and better self-service information can remove a lot of unnecessary interaction before an application is even submitted. For straightforward applications, this may involve automated validation and completeness checks.

For larger projects, the opportunity starts even earlier. Customers should be able to understand:

• Where connection may be more feasible
• Where network constraints exist
• What technical evidence will be required
• The likely process and milestones
• What may make the connection difficult or expensive
• Which assumptions need to be tested early

The better this information is, the fewer speculative enquiries networks need to investigate and the better prepared formal applications should be. Networks are also moving to a single “front door”, such as a dedicated team that qualifies and triages enquiries and applications, for more consistent and responsive service and upfront fees are also increasingly used to reduce speculative requests and to recover the cost of connection teams.

Better network visibility can change customer behaviour

Improving self-service isn’t simply about providing more FAQs on the website. There’s an opportunity to provide far greater visibility of the network itself. A developer considering several potential sites should ideally be able to understand where constraints exist and where there may be a more practical connection pathway before committing significant development expenditure.

Digital network tools can allow customers to test different locations, connection sizes, load profiles or operating assumptions and understand the likely implications before submitting a formal enquiry. That changes the conversation from “Can I connect here?” to “Where and how could I connect most effectively?”

This benefits both sides. Developers can make better siting and investment decisions earlier and Networks receive fewer speculative enquiries and better quality applications.

Visibility matters once the application starts too

The same principle applies once a project enters the formal process. Customers should be able to see what has been submitted, what has been accepted, what is missing, what is under review and what needs to happen next. They should also know who owns the next action.

That sounds simple, but it can be difficult where an application depends on multiple internal teams,  external advisers and market and system operators. From the customer’s perspective, however, there’s only one journey. A well-designed process makes the pathway clear from the beginning.

Redesign the workflow, don’t just digitise the form

A good digital connection process should do three things well:

1. Tell the applicant what is required
2. Prevent incomplete submissions from progressing
3. Show everyone what needs to happen next

Digitisation isn’t converting an existing PDF document into an electronic form. It is redesigning the workflow itself, removing email chains, removing duplication and re-keying of information and manual status tracking.

For complex projects, access to a knowledgeable person who can resolve ambiguity, coordinate different teams and help navigate difficult technical issues is enormously valuable. Technology should make that person’s job easier, not remove them from the process. It should free experienced people from administrative work so they can focus on the decisions and relationships where judgement matters.

2-Apply effort in proportion to complexity and risk

Not every connection needs the same process. At one end of the spectrum are large, technically complex generation, storage and load projects that require sophisticated engineering studies, network modelling, commercial negotiations and careful assessment of system impacts. At the other are relatively straightforward, standard connection requests that can still consume significant employee time.

Where network conditions are known and technical criteria are clear, routine applications should increasingly be capable of straight-through processing. A customer submits an application, software checks whether the information is complete and the application is assessed against predefined technical and network criteria. Where it falls within acceptable parameters, an outcome can be provided automatically. Human intervention is then focused on exceptions and higher-risk applications.

This type of risk-based processing is already commonplace in industries such as banking, insurance and telecommunications. There’s significant potential to apply the same thinking to electricity connections.

Use scarce technical expertise where judgement is required, not where a rules engine can provide the same answer.

Complex connections still need to be challenged

The same principle applies at the more complex end of the spectrum. Technical assurance cannot be compromised and grid impact studies, modelling and system-security requirements exist for good reasons. But that doesn’t mean every activity in today’s process should automatically be preserved.

For every requirement, it’s worth asking:

• What risk is this information intended to address?
• What decision does this study support?
• Has this information already been provided elsewhere?
• Does this activity genuinely need to be repeated?
• Does this approval need to sit at this particular point on the critical path?
• Is the level of process proportionate to the underlying risk or change?

These questions matter because processes accumulate over time, and there is often resistance to remove process steps (even if they are now redundant). The energy industry has also changed significantly and processes need to evolve with that reality. Hybrid facilities, battery retrofits,  sophisticated OEM control systems and complex ownership structures are increasingly normal. The relationship between who owns an asset, who operates it and who can technically control it can be very different from the industry structure that existed when some regulatory frameworks were originally developed. The objective isn’t to remove necessary controls, it’s to make sure the effort being applied is proportionate to the risk being managed.

Find the work being done twice

This leads to another obvious opportunity. Large connections can involve a network business, system or market operator, regulators, OEMs, developers, consultants and technical advisers. Every party has legitimate responsibilities, but from the developer’s perspective some activities can feel repetitive.

Similar information may need to be provided in different formats, and technical assumptions may be reviewed by several organisations. Models may move backwards and forwards between parties, and changes requested by one participant can trigger reassessment elsewhere.

What genuinely needs to be done more than once?

More standardised data requirements, common modelling approaches, clearer technical guidance and better sharing of information could reduce duplicated effort without weakening technical assurance. There’s also an opportunity to capture information once and reuse it. Digitisation shouldn’t require the same information to be repeatedly transcribed into different forms and systems. If information has already been validated, the default should be to reuse it unless there’s a genuine reason not to.

AI can help, but only once the foundations are right

AI and software can support the process in several ways. Rules engines can automate routine assessments. AI can identify missing information and interrogate technical documents. Workflow platforms can show project status, bottlenecks and resource demand. Digital network tools can help customers explore potential connection locations.

More sophisticated modelling could test alternative load profiles, generation configurations or flexible connection scenarios. Customer-facing tools could answer common questions without an engineer having to respond manually.

But technology should support a better process, not compensate for a poorly designed one. Automating unclear responsibilities, unnecessary approvals or poor-quality data simply embeds those problems in software.

Simplify the process. Clarify decision rights. Improve the data. Then automate.

3-Manage the pipeline as a portfolio, not a queue

Networks often manage connections as a queue, serving applications in the order they arrive. That’s largely a management choice, not a rules requirement, although prescribed timelines, such as the response to a connection enquiry, still apply.

In practice, projects differ in maturity, likelihood of proceeding, effort required and impact on the network. They also compete for the same network constraints and the same specialists.

The rapid rise in data centre and other large-load connection requests makes this much more urgent. When network capacity and specialist resources are constrained, how should a growing portfolio of projects be managed?

Not every project in the pipeline will proceed

Projects can sit at very different stages of maturity. One may have land, funding, customers and approvals in place. Another may be requesting a very large connection but still be at an early stage of development. Both can appear in the connection pipeline and both can absorb engineering and planning resources, but they may have very different probabilities of actually proceeding.

This matters because the headline size of a connection pipeline doesn’t necessarily tell you what will ultimately connect. Developers also have good reasons to preserve optionality. Where connection availability is uncertain, proponents may investigate several sites or approach several networks before deciding which project pathway is viable. Individually, that behaviour makes sense. Collectively, it can make the connection pipeline much harder for networks to interpret.

Arrival order doesn’t answer every question

Connections can also have very different implications for networks and the wider economy. Some may enable critical infrastructure or major industrial development. Others may support renewable integration, use existing network assets more efficiently or create opportunities for coordinated network investment.

This raises a difficult question for networks, regulators and policymakers.

How should scarce assessment, network and delivery resources be allocated when more projects want to connect than can realistically progress at the same time?

There may be no single right answer, and networks operate within regulatory obligations, including prescribed timelines, that rightly require fair and transparent treatment of connection applicants. But simply accumulating more projects in a pipeline has costs too. It consumes scarce engineering resources, makes network planning harder and increases uncertainty for customers that may genuinely be ready to proceed. It also makes it more difficult for management to understand where resources should be focused.

What managing a portfolio looks like

The opportunity is to manage major connections more deliberately as a portfolio. Networks need to be able to answer questions such as:

• Which applications are credible?
• How mature is each project?
• Which projects are waiting on the network, and which are waiting on the customer?
• Where are the bottlenecks?
• Which projects are absorbing significant engineering effort but making little progress?
• Where are specialist resources overloaded?
• Which network constraints affect several projects?
• Where should scarce resources be focused next?

That requires more than a dashboard. It requires consistent workflow stages, agreed readiness criteria, reliable data, clear decision rights and transparent governance.

Prioritisation needs transparent rules

The opportunity then is to use the information collected on each project to prioritise. Set readiness criteria and stage gates, and deliberately direct scarce specialist time towards credible, ready projects and the constraints that affect several projects at once. Use transparent criteria so customers can see how those decisions are made. Because queues are largely a management choice, changing how the pipeline is managed is largely within the control of the network.

This isn’t about arbitrarily choosing winners. It’s about having a much clearer picture of which projects are genuinely progressing and where scarce resources are being consumed.

Score projects on maturity, effort and complexity

Some networks are developing a simple scoring approach to help with this. It looks at the project itself, its status, size, location, scope, energisation date and maturity. It also looks at the proponent, including their experience and track record and the stakeholder and community sentiment around the project. Those factors are converted into an effort score and a complexity score.

The scores help in two ways.

1. First, they show where to focus. A project can be highly complex but at an early stage of maturity, in which case it doesn’t need the network’s attention yet because it isn’t about to happen. Conversely, a project that looks simple on paper, such as an expansion by an existing major industrial customer, can still absorb a large share of a team’s effort.
2. Second, the scores shape how the work is governed. High-effort, high-complexity projects might go to a steering committee, with regular reporting, a stakeholder management plan and a communications plan in place. That rigour manages the reputational risk as well as the delivery risk.

Prioritising isn’t the same as treating customers unequally. Prescribed timelines, such as the response to a connection enquiry, still apply. Within them, applying the same criteria to every project is what makes the process fair. And once a project has reached offer and is committed, the job changes from prioritising to delivering against that customer’s needs and schedule.

4-Build an operating model and ecosystem that works as one

Connection delivery rarely sits neatly within one team. Planning, network strategy, engineering, commercial, legal, customer, operations and project delivery functions may all play a role. For large connections, external parties such as system operators, OEMs, consultants and technical advisers may also be involved. And in many network businesses, the specialists required to progress connection applications also have substantial business-as-usual responsibilities.

That creates an inherent tension. When connection demand rises, additional work can simply be absorbed into existing teams. Projects compete with BAU priorities. Handoffs become bottlenecks, and different functions make different prioritisation decisions. No one necessarily has visibility of the entire journey.

Everyone can be busy while the customer still experiences delay.

The operating model needs to be explicit

Networks need clear answers to some fundamental questions. Rennie’s Operating Model Framework is one way to organise them. Applied to connections, the questions look like this:

These are operating model questions, and until they’re clear, technology can only do so much. Leading networks are giving each connection a clear end-to-end owner and setting decision rights. They plan capacity for connection demand against BAU and run a regular cross-team rhythm so people work in harmony.

A regular rhythm for people who dip in and out

Most of the specialists a connection needs aren’t there full time. They’re pulled in when their piece of the work arrives, then pulled back to their day job. A regular rhythm helps them work as one team. That might mean a cross-team check-in on each major connection, a shared place where progress and next actions are tracked, and agreed protocols for how and when specialists are brought in.

Put the right people on the right connections

Complexity and effort can shape the operating model as well as the process. Routine, standard connections are the strongest candidates for automation, and for outsourcing where that makes sense, while the complex, high-effort projects that need deep judgement stay with experienced in-house people. Networks will draw the line in different places. Whatever the split, standard connections still need reliable delivery, and the risk is that they slip while attention is elsewhere.

Cost transparency is part of the operating model too

Another issue becoming increasingly important is cost transparency. Connection customers are becoming larger and more sophisticated. Renewable developers, battery operators, industrial businesses and data centre developers increasingly expect to understand what they’re paying for, how those costs have been calculated and where risk and contingency sit within an estimate.

Some uncertainty is unavoidable. Engineering scope evolves, network conditions change and projects carry genuine delivery risk. But opacity can also arise because the underlying cost information is weak. If employee time isn’t recorded accurately, the true cost of providing connection services can be difficult to understand. Different teams may then include contingencies or risk allowances to protect against uncertainty.

Customers may question whether charges are reasonable. At the same time, the network itself may not be confident that it’s recovering the full cost of providing the service. Better cost models and clearer charging structures can improve confidence on both sides.

The customer experiences one journey

The same principles apply across the ecosystem of AEMO, networks and customers. Each has legitimate responsibilities, but from the customer’s perspective there’s only one connection journey. That means a clear owner for each next action, agreed decision rights and a shared view of where a connection is up to.

Customers should be able to see what has been submitted, what is outstanding, who owns the next action and what happens next, even when several teams and organisations are involved.

 A shorter, clearer path to connection

To conclude, for the foreseeable future connection demand is unlikely to slow. Electrification, renewable generation, storage, industrial development and data centres will continue to place pressure on electricity networks around the world. Physical network investment will be essential. But investment in infrastructure should happen alongside investment in the way connections are managed, prioritised and delivered.

Making grid connections faster isn’t about one big fix and it isn’t about weakening the standards that protect the power system. It’s about reducing avoidable work, making requirements clearer, applying technical expertise where it adds the most value, and giving everyone a better view of the path to connection.

The issue isn’t any one type of customer. If it isn’t data centres today, it will be something else tomorrow. The controls that matter manage volume, so a network can respond to real demand without over investing and stranding assets.

None of this is easy. Networks have to transform the process while they’re still processing a growing pipeline. It’s like laying the tracks while the train is already coming, and stopping the train isn’t an option.

The starting point is to target the places where customers and teams lose the most time, test changes on a handful of live connections and build from there. The payoff for getting this right is worth the investment  with less noise, greater certainty and a faster path to connection.

If you have any questions, please reach out to David Melis.