The Game Theory of Grid Upgrades

 

by David Riester

It’s a bit strange that we never talk about this.  Power developers are constantly playing a brutally difficult (yet fascinating) “game” while navigating interconnection queues and shared network upgrades (“NUs”).  The decisions made within these games represent many of the largest (by dollar amount), most impactful, and most challenging that Segue makes while managing risk and building value in our project portfolios.  As i) IX queues have grown in length and complexity, ii) America’s electrical grid now living at the saturation point virtually everywhere, and iii) higher project withdrawal rate associated with the exogenous headwinds… the size, prevalence, complexity, and importance of these “To Stay In Queue Or Withdraw” games is increasing and accelerating.  This is not new, but it’s getting worse, and prevalent.  That reality is surely not lost on anyone with assets in the MISO, SPP, or CAISO queues, where particularly juicy versions of this game have been playing out in recent months.  

Here's the basic set of circumstances: 

  • Developer has a power plant in an interconnection queue;
  • All developers in that interconnection queue cluster simultaneously get a “study” (e.g. DPP1, DPP2, SIS, etc.) back. It provides information such as:  
    1. The various NUs that will be required assuming all existing applicants in interconnection queue remain so;
    2. Developers share/responsibility for each individual NU (creating a “local cluster”, if you will, of interdependent projects);
    3. Other local cluster developers’ share/responsibility for each individual NU;
    4. Basic information about those other projects sharing an NU with Developer’s;
    5. The capacity “threshold” triggering the need for each NU;
  • Information traditionally not made available includes: 
    1. Owners of other projects in the local cluster;
    2. Facilities (e.g. substation) costs for those other projects;
    3. Precise location of other projects;
    4. Whether other projects have a permit, or clean site control, or offtake, etc.
  • There’s a window of time during which all project owners (developers) can digest the information and decide whether to remain in the queue 
  • At the end of the window, all projects in the queue cluster must simultaneously decide to either i) Withdraw their project, or ii) Stay in the queue
  • If a developer withdraws a project, they will usually receive a refund of a significant portion (sometimes all) of the financial security deposits posted to the ISO to date, but the project likely “dies” as it loses its place in the interconnection line. Other costs incurred on the project to date – site control, permitting expenses, environmental work, engineering, etc. – would usually be written off as losses.  
  • If a developer wishes to remain in the queue, they must post additional financial security (on top of the postings to date), and usually a significant percentage of all posted financial security deposits become non-refundable. That is to say, if a developer later decides to withdraw, the financial loss for doing so is significantly greater than if the project is withdrawn at the decision point in question.
  • Depending on the decisions made by all project owners in the queue cluster, the NUs allocated to Developer’s project may (almost certainly will) change dramatically. And remember, all stakeholders submit this decision simultaneously.
  • The “stay or go” choices a given Developer prefers from other developers in each local cluster differs depending on the specific circumstances, as well as the other decisions made in the same local cluster; it is a multivariate equation.  This is because of the natural tipping points that exist at the line below which an NU is no longer triggered. In many instances, a developer may prefer another project stay in the queue to further share the costs of an NU. Conversely, a developer may hope that same project withdraws, believing that the withdrawal might pull the local cluster to the other side of the tipping point, thereby “flipping” the trigger on the NU to “off”.   
  • Usually there are dozens of combinations of decisions (“scenarios”) to consider. For example, if there are 8 projects in a given NU local cluster, there are 256 possible scenarios (2 to the 8th power).
  • Out of this soup of circumstances boils a multi-player “Hawk-Dove Game”1. You might know the two player version of this game by its more common name: “Chicken”. That game is tricky enough in its simpler form, but a multi-player Hawk-Dove game is an absolute mess with no hope for a Nash Equilibrium. That’s partly due to the unnavigable scenario universe to consider, but also the reality that communication offers little utility. Let me show you… 

Assume you have no relationship with another member of a local cluster, and someone calls you and asks what you are going to do. Ethics, altruism and relationship capital aside, is there any benefit to providing an honest answer? (Take a minute to mull that over) 

Ok, you might say “well, if I know I’m going to withdraw, it doesn’t do me any harm to honestly convey that information”.  Fair enough. 

But wait a second…can the party that asked you the question trust your response? Is there a scenario where sending a false signal might benefit you?  There sure is!  What if you’re actually planning to stay in and are rooting for as many others to stay in to share NU costs with you – this provides an incentive to, well, lie or mislead. 

Right, you say, but in that scenario why wouldn’t I just tell them I’m staying in, thereby giving them confidence to do the same knowing my project will be carrying some of the NU costs? 

Not so fast! No one in this scenario knows for sure where another player in the game believes things stand vis-à-vis important NU tipping points, and you might reasonably be focused on different scenarios.  So, isn’t it plausible that you could be exaggerating your intention to stay in the queue in the hope that it would cause another party to drop out (because their only hope of project viability is if an NU drops away altogether), when really they aren’t so sure yet? (This is, essentially, just an embedded two-party game of chicken rife with bluffing).  

In the end, attached to any response is the possibility of an entirely “rational” lie, resulting in what’s called a “chain of suspicion”, such that communication does not result in a Pareto Improvement (higher collective outcome). At least not in theory. 

 

How Developers Actually Handle This   

Well, as I said, as far as I can tell the power sector has never approached this problem with much analytical rigor; there’s not a lot of science to most choices.  Developers often attempt reconnaissance (espionage?) to try and render the game more navigable. The foundational piece of information needed is who owns and/or controls the other projects in the local cluster.  With that information, further investigation might include trying to figure out what other developers are planning to do (the most directly useful information), or other project conditions that might inform other developers’ choices, such as if the project was denied/granted a critical permit, if a critical piece of land has been secured, or if a key revenue contract has been signed. It may also include strategy-level information about the project owner: are they making a big push into this region? Did they just sign a big capacity agreement with someone locally, making it particularly painful to withdraw a capacity resource? Do they own other assets in the area? Do they own other assets in this local cluster, rending their “game” less daunting?  

In the end, the decision to stay or withdraw is usually made against the backdrop of a few scenario analyses focused on what the developer believes are the most likely scenarios. It’s not uncommon for the decision to be made based on a single scenario deemed most likely. This approach implicitly places a huge value on intuition and pattern recognition. One wonders…well what the hell else would I do? 

 

Who Has The Advantage? 

Does this state of play offer any type of developer an advantage over others? Yes. Characteristics that better position a developer include: 

  1. Risk tolerance  
  2. Project sizes
  3. Balance sheet size (and access to capital, credit)
  4. Experience/sophistication
  5. Industry reach

Risk Tolerance. Often, the expected outcome – the probability of each scenario multiplied by that scenario’s NU “outcome” – supports remaining in the queue, but doing so asks a lot of the developer in the form of stomaching the possibility of very bad outcomes (big losses). Larger entities are better positioned to absorb such losses, generally speaking, as are those with a longer time horizon. Companies with sophisticated risk management practices (not the same as risk aversion!) and capital structures designed to support the taking of risk (appropriately levered, appropriately equitized) have an advantage. 

Project sizes. Developers focusing on larger assets will tend to have more control over their “fate” in the NU game, therein being less at the whim of other developers’ choices. 

Balance Sheet Size. Staying in the queue is a capital-intensive decision – companies that have a deep reservoir of cash and/or credit (access to surety bonds, LCs, and/or parent guaranty is valued) have a significant advantage. Additionally, there’s the simple fact that larger balance sheets can more easily absorb a few downside outcomes, allowing the Law of Large Numbers to run its course.  

Experience/relationships/sophistication. Team savvy influences the quality of the scenario analyses and associated probability assessment. Whether they realize they’re doing it or not, developers have no choice but to assign probabilities to different scenarios. Doing so draws upon experience, knowledge of other industry actor’s behavior/choices, and how likely considerations that are “outside of the game” are to impact scenario probability. 

Industry Reach. Relationships and cache affect the quality and amount of information that might be obtained from (or about) other developers/projects in the local cluster. Importantly, not all actors will behave rationally. Some will communicate information that harm their expected outcome because a) they don’t understand the game they are in, b) value a personal relationship higher than their company’s success, or c) value perceived personal reputational gains of “being in the know” over their company’s success. Individuals who know where to find, create, or access (a), (b), or (c), give their project an advantage. 

 

How This Manifests at Segue 

To put this into context, much of Segue’s strategy is calibrated to benefit from as many of these advantages as possible:  

  • We use diversification and preserve upside potential to position us to take smart risks.  
  • Many smaller, younger, or highly concentrated developers create going-concern risk every time they post a big deposit. In partnering with Segue, the same group migrates to an ecosystem wherein it’s more appropriate to take these chunky risks, has financial security posting wherewithal, and an ecosystem that thinks about risk in a sophisticated manner.
  • We navigate these NU Hawk-Dove games on a regular basis, and while we find them just as tricky and unpleasant as anyone else, they don’t paralyze or surprise us. And we have a framework for thinking them through, complete with feedback loops as experience is gained.
  • The network effect of working with Segue shows itself on this playing field; our investigative work usually bears fruit in partially demystifying the “game”, and sometimes our relationships serve to reveal information one wouldn’t expect to be available. We are usually able to reduce the variables/scenarios meaningfully (though never as much as desired). 


The advantages enjoyed by larger stakeholders offers a strong case for further industry consolidation. In fact, in some cases specific NU games have prompted consolidation. At SunEdison in 2010, I worked on multiple platform acquisitions the justification of which included improving existing SunEdison project’s NU cost prospects in CAISO.  Anecdotally, I’m familiar with more recent platform acquisitions in PJM and ERCOT which grew from the seed thought: “it sure would be great if I knew – or even controlled - the fate of that project.”  In theory, acquisitions that reduce the number of stakeholders in a local cluster can only serve to improve the collective outcome. 

 

Is There A Better Way? 

One can’t help but wonder if this game can be avoided or fundamentally changed. The dream of a further nationalized, properly government-funded national electric grid – where the burden of upgrade cost is shifted from individual project developers (who then pass the costs along to rate-payers) to taxpayers – hardly seems worth lingering on.  

Many possible solutions come with the tradeoff of additional i) costs, ii) time, iii) complexity. For example, creating more “rounds” (phases) in the study process – where a party has to pay extra study costs to see “another card” flip over, but ultimately has more/better information in hand before making the big decision - would result in better and more equitable decisions. But then we’d all be complaining about how byzantine and costly the study processes are.  

As alluded to above, acquisitions aimed at clearing up a local cluster picture are under-utilized. Frankly, even “fill-and-kill” acquisitions can serve to improve the collective outcome. Because of the coordination and communication impossibilities, “lose-lose” outcomes surely occur regularly. This looks like zero profitable projects becoming power plants where at least one could have done so.  In a simple example: if you have a project with an expected $10m margin, but a range of scenarios that includes unpalatable downside outcomes (probability and/or magnitude), you might withdraw the project despite an attractive expected outcome (this is nothing more than a simple expression of risk management). If, however, you could purchase a competing project in the local cluster for $2m and thereby render your downside scenarios manageable, it might be rational to purchase the project only to kill it. Your expected outcome may decrease to as low as $8m, but if that comes attached to a palatable downside, it’s money well spent.   

And then there’s the category of trust, ethics, benevolence and relationships. This is where most people’s mind goes when wondering if there’s a “better way” through these Hawk-Dove games.  It goes a little something like this: “If you have real long-term relationships with other developers in your local cluster (or a reputation for being honest generally) you can navigate these games.” This is a lovely sentiment, but ultimately of little utility. Why? Primarily because the universe of other developer stakeholders is very large, and even for the most connected of us, the reality is most local clusters will include a couple parties with whom you have a real relationship, at best. The other issue I have with this sentiment is that it implies improper loyalties! If you’re representing the best interests of your company there are countless scenarios where truthfully conveying your firm’s planned behavior harms your company’s prospects (see above). Choosing, instead, to prioritize a personal relationship is unethical and probably a fireable offense. That is not the same as saying “you should lie to a friend for your company’s benefit” - it is perfectly reasonable for a company to demand nondisclosure.  

I often noodle on the idea of a “Transparency Pledge” of sorts between parties that frequently bump into other. Perhaps it could even be a binding contract to share information, with liquidated damages for breach.  

Is this collusion? No.  

Is it legal? Show me where it’s not.   

Would it work? In a very limited way, sure. I think what it would do is occasionally reveal obvious opportunities for M&A activity. But putting together dozens of these agreements is very impractical, and it still wouldn’t eliminate the challenge.  For there would still be other stakeholders in various local clusters that keep the picture muddy. And, of course, in simulated coordination games “cheap talk” commitments like this usually work briefly…until they very suddenly don’t.  There’s that lingering opportunity to profit from a lie, which only 1 of the 2 parties enjoys – the first to lie.   

Ultimately there are no clear fixes to this NU cost game. But the power sector would benefit from understanding the nature of the game more clearly and being intellectually honest about how it affects our development projects’ fates.  The only thing worse than living with an uncontrolled risk is not knowing it’s there. 

 

Footnotes


1 The two player version of this game