.png)
PROJECT COORDINATION · TIME HORIZONS
The Long Timeline Problem
By David Swank, CEO, i3 Power & Energy
One of the least discussed and most consequential problems in energy infrastructure development is that the parties who need to align on a project are operating on wildly different clocks. Utilities plan on twenty-year horizons because that is what regulated planning requires. Independent developers work on three-to-five-year horizons because that is what project finance assumes. Hyperscaler customers make infrastructure decisions on eighteen-month horizons because that is how quickly their compute demand shifts. Regulators move on cycles that vary by jurisdiction and often by administration. Each of these clocks is rational for the party keeping it. Getting them to synchronize is one of the hardest quiet problems in
the industry.
Almost every project that fails because of coordination issues can trace the failure back to unreconciled timelines. Everyone at the table wanted the project to succeed. Nobody actually agreed on when success was supposed to have happened. That kind of failure is not visible in any one meeting. It builds up slowly, one deferred decision at a time, until the project reaches a point where nobody can act because their clocks have drifted too
far apart.
.png)
Why the Clocks Are Different
The clock a party keeps is not a preference. It is a consequence of the structure they operate inside. Regulated utilities plan against rate case cycles, integrated resource planning cycles, and asset economics that stretch across decades. Their planning horizon is a rational response to the actual timescales on which their decisions play out.
Project developers work against fund lifecycles, offtake contract terms, and construction financing windows. Their horizon is also a rational response to the structures that govern their capital. Hyperscale customers work against technology refresh cycles, workload evolution, and competitive positioning that shift on quarterly cycles. Their horizon reflects the actual pace at which their strategic environment changes. Regulators work against political cycles, statutory review periods, and agency workload realities that produce their own sense of urgency and delay.
None of these clocks is wrong. All of them are correct for the context that generated them. The challenge is not to convince any party that their clock is mistaken. It is to build coordination structures that respect all the clocks simultaneously.
What Happens When the Clocks Are Not Reconciled
When timelines are not surfaced and reconciled explicitly, they produce a specific kind of failure that is easy to attribute to something else. A utility's fifteen-year plan does not match a developer's five-year window, so the interconnection commitment the developer needed does not fit the utility's next planning cycle. A developer's five-year window does not match a customer's two-year urgency, so the developer commits to a delivery date the utility timeline cannot support. A regulator's approval cycle does not match anybody's, so all the parties end up waiting on a schedule none of them can influence.
Each of these failures gets described afterward as a permitting problem, a financing problem, or a capacity problem. Underneath most of them is a timeline problem that no party surfaced explicitly at the beginning.
“Every party wants the same project to succeed. They just do not agree on when success is supposed to have happened.”
What Reconciliation Actually Requires
Reconciliation does not mean forcing every party onto one shared timeline. That approach fails immediately because the underlying structures do not allow it. Reconciliation means acknowledging that each timeline is real, understanding what each timeline actually requires, and building coordination points that respect all of them
at once.
This is more subtle than it sounds. It requires surfacing timeline assumptions early and explicitly, in the language each party uses to describe their own clock. It requires designing projects that have decision points, optionality, and off-ramps that respect the different horizons rather than pretending they can be flattened. It requires ongoing communication that keeps every party updated on where the others are in their respective cycles, so that misalignment can be corrected while it is still small.
.png)
.png)
The Firms That Handle
This Well
Firms that manage timeline differences well share a few characteristics. They understand each party's clock as its own and can explain any one party's timeline to the other parties in terms that resonate. They design coordination protocols that do not require synchronization, because they know synchronization will not happen. They build optionality into project structures at the points where timelines are most likely to diverge, so that divergence does not become an existential problem for the project. They explain the timelines to each party in the language that party actually uses, so that the acknowledgment of the differences produces cooperation rather than defensiveness.
This is the invisible infrastructure of good project coordination. It rarely shows up in project marketing materials. It is one of the highest-leverage capabilities a developer can build.
.png)
Timeline as a Coordination Problem
I can't emphasize enough how much project failure gets attributed to bad execution when it should have been attributed to unreconciled timelines. Projects do not fall apart because one party could not do its job. They fall apart because the parties never agreed on when the job was supposed to be done. Coordination is not just about who is at the table. It is about whose clock the table is running on.
The firms that understand this build projects that survive the tension between horizons rather than being surprised by it. That is one of the quiet advantages of the i3 model, and one of the reasons projects developed this way arrive when they said they would. Bankable projects are not just projects that satisfy their financing terms. They are projects that respect the timelines of every party required to make them happen.