Most program failures in power infrastructure share one structural error: the interconnection is modeled as an activity rather than as a constraint.
An activity has a duration. It can be resourced, accelerated, overlapped, or run in parallel. A constraint has none of those properties. It has a date, imposed from outside, which the project must arrange itself around.
The interconnection queue is a constraint. Treating it as an activity produces a program that is internally coherent and externally impossible.
What the queue actually is
An interconnection queue is a sequencing mechanism for studies. Applications are processed in order because each study depends on the assumed state of the network, which depends on the projects ahead in the queue. That dependency is the reason position cannot be bought, escalated, or negotiated in most jurisdictions.
It also means your date is exposed to other people's decisions. When a project ahead of you withdraws, the studies behind it may need rework. When a cluster study is restructured, timelines move for everyone in it. These are not risks the owner can mitigate through diligence. They can only be absorbed through float.
How treating it as an activity fails
Once the connection is an activity in the schedule, it acquires the properties of one. Planners give it a duration. Managers ask how it can be compressed. When the program is under pressure, it becomes a candidate for acceleration alongside everything else.
None of that has any effect on the utility. What actually happens is that the pressure is transferred to activities the project does control — design, procurement, construction — which are compressed to protect a date that was never movable. The program absorbs the queue delay by degrading everything else.
Compressing what you control to protect a date set by someone who does not know you exist is the defining error of the sector.
Sequencing from the connection date
The correction is to invert the logic. Fix the realistic energization date first, with its uncertainty stated, then sequence backwards.
This produces uncomfortable conclusions early, which is the point. It may show that construction should start later than planned, because finishing a building that cannot be energized converts capital into a stranded asset earning nothing while it waits. It may show that the long-lead order must be placed before the design maturity that would normally justify it — a real risk, but one taken deliberately rather than discovered.
It also identifies which parts of the program are genuinely independent of the connection and can proceed regardless: civils, site enabling, and some structural work. Those become the flexible portion. Everything downstream of energization is fixed to a date the project does not own.
Where float belongs
Float placed against a constraint you cannot influence is worth more than float distributed across activities you can.
That argues for a deliberate buffer immediately ahead of the connection-dependent work, owned by the project rather than by any contractor, with an explicit rule about who may consume it and on what evidence. It is visible, defensible to a board, and it does the job float is supposed to do.
The alternative — thin float across hundreds of construction activities — provides no protection against the one event most likely to move the end date.
The diligence question
For anyone funding or approving a project of this kind, the useful question is not when the connection is expected.
It is: what is the queue position, when was the application made, what stage is the study at, what network upgrades has it identified, who pays for them, and what has moved in the queue since the application. Six answers, all documented, all verifiable.
Where those answers exist, the date is a forecast with a basis. Where they do not, the date is a placeholder — and the program built on it is a placeholder too.
