Should I Stay or Should I Go?

In 1982, The Clash released “Should I Stay or Should I Go.” And while generator interconnection was unlikely their muse, the chorus does ring true for project developers navigating the interconnection process.

Similar to the tenuous relationship in the song, the interconnection decision-making process is also non-transparent and wavering. On the one hand, developers want to “stay” in the queue but don’t want the costs to “double” (or more realistically, quadruple). On the other hand, they worry if they leave, “there will be trouble.” Though vastly simplified, this lyrical comparison does reflect that developers face much uncertainty in the interconnection process and struggle with answering “Should I Stay or Should I Go.”

We promise not to spend this entire article drawing comparisons to a catchy 80’s hit. Rather, we will focus on how developers can add scenario analysis to their toolkits to help them bolster their decision-making and provide more certainty on their projects’ interconnection fates.

As if interconnection wasn’t challenging enough, developers must make impactful decisions within short timelines imposed by transmission providers, otherwise known as ISO Decision Points (DPs). During these brief windows, developers digest study results, analyze and develop realistic scenarios, and perform financial analysis. If all of this diligence points to staying in the queue, developers then have to post a security deposit. And these security deposits are not nominal. For example, the average M2 security deposit for MISO DPP-21-South was $9.7 million, and Pearl Street estimates the average M2 deposit for DPP-22-South will be $8.5 million.

So, how does a developer decide whether to stay or go? At Pearl Street, we encourage the practice of running scenario analyses to bookend network upgrade costs—i.e., generate a cost range including a “floor” and a “ceiling.”

To derive cost bookends, developers can run a variety of scenarios that usually fall within one of two categories: project-specific scenarios you can control or queue-related scenarios reflecting potential decisions made by other developers. We’ll dig into these categories in detail in the following sections.

When we say “project-specific,” we really mean scenarios that are under a developer’s control. In other words, these are changes to a developer’s project that are made independent of other projects. This potential set of scenarios is powerful because it gives a developer total autonomy with their project and lets them determine what upgrades they have the risk appetite to pay for. We’ve provided some project-specific scenarios below.

1. Project size reduction to mitigate an overload: In this scenario, a developer would determine the level of reduction needed to reduce a post-contingency loading to less than 100%.
2. Project size reduction to avoid cost allocation criteria: As an example, MISO and SPP outline criteria a project must meet to be cost-allocated, including meeting a minimum MW Impact. To reduce a project’s MW impact, a developer could choose to decrease the size of its project. For more information on MISO and SPP criteria, please refer to their respective study manuals.
3. Changes or reductions in service type: A developer could also reduce or remove its project’s NR/NRIS service type to avoid network resource-specific overloads.

In contrast to project-specific scenarios, queue-related scenarios are run to see how the variability of other projects in a cluster or prior cycle affects the cost allocation of a developer’s specific project.

1. Current cycle withdrawals: Historical project withdrawal rates hover around 80%. Thus, a developer might want to run scenarios to determine what happens to its allocated cost when projects within its current cycle withdraw. Developers can simulate projects being withdrawn due to:
   1. High normalized cost ($/MW) by fuel type, transmission owner, state, county, etc.
   2. Strategic withdrawals based on geographic and/or electric proximity to a project
   3. Permitting info, renewables moratorium, and insight from RFPs.
2. Prior queue withdrawals: Prior queue cycles can also have a direct impact on a developer’s interconnection costs and performing scenario analysis on previous study cycles is necessary as queues grow. One way in which developers can model these prior queue withdrawals is to determine which network upgrades could move from a previous cycle to the current one. Additionally, developers can identify breakpoints where system intact upgrades are no longer needed. Sidenote: this capability is unique to Interconnect™ subscribers. Instead of starting from a DISIS or DPP model and working backward, we start from scratch and build a new model for each scenario.

Developers may want to run analyses for both project-specific and queue-related scenarios. And once they’ve bookended their cost, they still have to present these results and make a decision internally with information spanning departments. Interconnection engineers may like to use power flow results, project finance likely needs to model cost scenarios and to advance permitting/siting, the development team needs to know how likely a project is to move forward.

Inside our developer-facing platform, Interconnect™, is a study scenario dashboard that highlights how estimated network upgrade costs change across any of the scenarios analyzed. Ultimately, this easy-to-digest format presents all relevant cost information in a way that each department can understand and utilize, thereby helping the team decide, “Should I stay or should I go.”

As much as we would like to offer a “magic bullet” for network upgrade costs, the nature of cluster studies prevents us from doing so. Pearl Street believes that analyzing multiple scenarios and viewing costs probabilistically, is the best way for developers to make a decision during a short timeline.

Reach out to us to learn more about how Interconnect™ can help you optimize your decision-making!