In short: A grid connection queue is what happens when scarce capacity is allocated by application order at close to no cost, which produces a queue far longer than the pipeline of projects that will actually be built. Little's Law, proved in Operations Research in 1961, relates queue length, throughput and waiting time for any stable queue, which turns a connection date into arithmetic rather than opinion. Serial processing explains why one withdrawal moves everybody behind it and why queues stall rather than moving slowly. A connection date several years later than the model assumed is a valuation problem, so the discounted cost of the delay belongs in the appraisal rather than in a programme update.
The development team has land, a planning consent, a signed option and a decent irradiance dataset. The connection offer says 2033. The financial model was built on 2029, the offtake conversation assumed 2030, and the equity partner's fund has a 2031 deployment window.
Nothing about the project changed. The date came from a process the developer does not control, based on a study of projects most of which will never be built, and it moved the value of the asset more than any engineering decision available to the team.
A queue is what you get when a scarce good is priced at zero
Connection capacity at a given point on the network is scarce, and in most jurisdictions it has been allocated by application order at a cost close to nothing. That combination produces exactly what economic theory predicts and what every operator now has: a queue far longer than the pipeline of projects that will actually get built.
The mechanism is straightforward. If holding a queue position is nearly free and the position has option value, the rational strategy for any developer is to apply early, apply for more capacity than needed, and apply at several points on the network for the same project. Every one of those applications is individually sensible, and collectively they congest the process for everyone including the applicant.
The scale of the resulting attrition is documented. Lawrence Berkeley National Laboratory's Queued Up series, in its 2024 edition, reports that of the projects that entered United States interconnection queues since 2000 and have reached a resolution, roughly eight in ten were withdrawn rather than built. That is the ratio that makes serial processing untenable, because the network operator is spending study effort on a population that is mostly fictional, while the real projects wait behind it.
Little's law puts a number on the wait
The relationship between queue length, throughput and waiting time is not a matter of opinion. Little proved it in Operations Research in 1961 and it holds for any stable queueing system regardless of the arrival or service distributions: the average number in the system equals the arrival rate multiplied by the average time in the system.
Rearranged for the question a developer cares about, the average residence time equals the number in the queue divided by the rate at which projects leave it, counting both connections and withdrawals as departures.
Take a region with 2,000 projects in the queue, of which 100 a year energise and 300 a year withdraw. Departures total 400 a year, so the average residence time is five years. If the operator doubles study throughput without anything else changing, departures rise toward 800 and residence falls toward two and a half years. If instead the withdrawal rate is cut by imposing milestones, and the queue stabilises at 900 projects with the same 100 energising and 100 withdrawing, residence is four and a half years, which is barely better despite a much healthier queue.
That second calculation is the one worth sitting with. Purging speculative applications improves the honesty of the queue and does very little to the waiting time on its own, because the departures you removed were also removing people from the queue. Waiting time falls when the operator's study and construction throughput rises, or when the arrival rate falls. Screening only helps to the extent that it frees study capacity that then increases throughput, which it does, but the effect is second order and the first-order claim gets made anyway.
Why one withdrawal moves everybody behind it
Serial processing has a specific pathology that explains why queues stall rather than simply moving slowly.
Connection studies are done in order, and each study assumes every project ahead of it in the queue is built. The network reinforcement a project triggers, and the share of shared reinforcement cost it is allocated, both depend on that assumption. When a project ahead withdraws, the assumption underlying every downstream study changes, the reinforcement requirement changes, the cost allocation changes, and the studies have to be redone.
With withdrawal running near eight in ten of resolved requests, this happens constantly. The operator spends much of its capacity restudying a queue that keeps changing beneath it, so the effort scales closer to the square of queue length than linearly, and each restudy cycle can itself trigger the withdrawal that starts the next one.
The commercial consequence for a developer is worse than the delay. Your allocated share of a shared upgrade is a function of who else is still in the queue. A project holding a 40 million allocation for a shared reinforcement can see that figure move by tens of millions when a large neighbour drops out, in either direction, with no notice and no recourse. Underwriting a project against a cost allocation that is structurally unstable is one of the least discussed risks in the sector.
Cluster studies, where a batch of applications is studied together and costs allocated across the batch by a defined rule, exist to break this loop. They convert a sequence of dependent studies into one joint study, which removes the restudy cascade at the cost of making every project in the cluster wait for the batch to close.
What the delay costs, discounted properly
Queue delay gets discussed as a schedule problem and it lands as a valuation one, so the arithmetic belongs in the appraisal rather than in a programme update.
Take a 100 MW project expected to generate 8 million a year of operating cash flow across a 25 year life, with a discount rate of 8 percent. The present value of that annuity at the point of energisation is about 85 million. Delay the whole stream by three years and every cash flow is discounted by an additional factor of 1.08 cubed, which is 1.26. The present value at today's date falls to about 68 million.
A three year queue delay has removed roughly 17 million, around 20 percent of the project's value, without a single change to its capital cost, its yield or its power price assumption. And that ignores the development cost carried through those three years, the option premiums on land, and the risk that the offtake counterparty's appetite changes.
Two decisions follow from that number and neither is obvious without it.
Paying for an earlier position, where a mechanism exists to do so, is worth up to roughly 5.7 million per year of acceleration on this project. Most developers treat acceleration payments and grid works contributions as cost lines to minimise rather than as investments to appraise against that figure.
And a smaller project available sooner can be worth more than a larger one available later, though the crossover sits further out than intuition suggests. On these assumptions a hundred megawatts in 2033 is worth about 49.8 million today against 40.6 million for sixty megawatts in 2029, so the larger later project still wins. Break-even against a 2033 hundred-megawatt project, at four years of acceleration, lands near 74 megawatts. For a sixty megawatt project to win you need roughly six and a half years of acceleration rather than four. Run the arithmetic before ranking on date, because the intuition that earlier always beats larger is wrong across a good part of the range.
The reforms, and what each one actually changes
Regulators across several markets have converged on a similar set of interventions. It is worth being precise about which constraint each one relieves, because they are often discussed as a single package.
Entry requirements and deposits. Land control evidence, planning status and a refundable deposit scaled to capacity. At 10,000 per MW, a speculative 100 MW application costs a million to hold, which is enough to change behaviour. This reduces the arrival rate of applications that were never going to build.
Milestones and exit conditions. Defined dates by which a project must demonstrate progress, with removal from the queue if missed. This raises the departure rate for stalled projects and, more importantly, makes departures happen early rather than after they have consumed study effort.
Cluster study processing. Batching applications and allocating shared costs across the batch. This attacks the restudy cascade directly and raises effective study throughput without adding engineers.
First-ready rather than first-come ordering. Reordering the queue by project readiness instead of application date. This changes who waits rather than how long the average wait is, and it transfers value from early speculative applicants to mature projects.
Connect-and-manage arrangements. Energising a project ahead of full reinforcement, with curtailment accepted until the works complete. This is the only intervention on the list that changes a developer's energisation date without changing the queue at all, and its price is a curtailment risk that has to be modelled rather than assumed away.
Planning a portfolio around a date you do not control
For a developer with a pipeline, the queue is a constraint to plan around rather than a fact to wait on.
Treat the energisation date as a distribution. Every project has a queue position, a cluster, a set of dependencies on reinforcements, and a history of how that operator's dates have moved. The output of the development plan should be a probability of energisation by year rather than a date, and the portfolio view should be the sum of those distributions.
That reframing changes the resourcing conversation. If eight projects each have a 40 percent chance of energising in a given year, the expectation is 3.2, and the probability that five or more land at once is meaningful. Development, construction and financing capacity all need to be sized against the distribution rather than the plan, which is the same discipline used for any pipeline with stochastic conversion.
Hold options rather than commitments wherever the cost of the option is small relative to the value at risk. Land options, extendable planning consents and equipment reservations that can be deferred all buy you the right to be wrong about the date. The 17 million computed above is the budget available for buying that flexibility.
And measure the operator you are dealing with. Connection dates move, and they move differently by operator, by voltage level and by whether a project sits behind a major reinforcement. Two years of your own offer letters and their revisions is enough to build a simple empirical distribution of date slippage, which is more useful than any published target.
The limit
The queueing arithmetic assumes a system in something like steady state, and connection queues are anything but. Application rates have risen sharply as storage and data centre load have entered the same processes, reform programmes are changing the rules mid-queue, and several markets have paused new applications entirely. Little's law still holds instantaneously, and using it to forecast a wait three years out assumes an arrival rate that is visibly moving.
There is also a limit on what any developer can do with this analysis. The queue is a shared resource governed by a regulated process, and no amount of internal modelling changes your position in it. What the modelling changes is which projects you fund, what you pay for acceleration, how you underwrite an unstable cost allocation, and whether you take a connect-and-manage offer with curtailment rather than waiting for a firm one. Those are real decisions and they are the whole of the available action set.
The data limit is the ordinary one. Queue position, cluster membership, reinforcement dependency and offer revision history exist across offer letters, operator registers and email, and almost nobody holds them as structured data. Assembling that for your own pipeline is a fortnight of work and it is the prerequisite for every calculation above.
Take your current pipeline, apply the three year delay discount factor to each project's cash flows, and rank the portfolio by what it is worth on the connection date you have rather than the one you planned.