When Your Costing Assumes Perfect Information (And Why the Second Event Always Proves You Wrong)

You've built a cost model. It's beautiful. Every line item ties out, every escalation factor has a footnote, and your Monte Carlo simulation runs faster than your boss's patience. Then the second event hits—a Category 2 storm where you planned for Category 1, or a cyberattack that takes out a substation you assumed was air-gapped. Suddenly your perfect costing looks like a child's drawing. This article is for the people who've been there: utility planners, risk analysts, and CFOs who sign off on resilience budgets. We'll talk about why perfect information is a myth, and how to cost for the world we actually live in.

Who Needs This Warning Most

Utility planners under regulatory pressure

You have a filing deadline, a docket number, and a spreadsheet that needs to balance by Friday. The regulator wants a ten-year cost projection for grid resilience upgrades, and your team has been pulling data from the last three storm seasons. That sounds fine until the second event—the one that lands outside your historical envelope—shows up and your entire costing model folds. I have seen planning departments treat the past five years as if they were a crystal ball, not a sample. The pressure to deliver a number that 'makes sense' to the commission pushes analysts to assume the next ice storm will behave exactly like the last one. Wrong order. The regulator doesn't need certainty; they need a range that admits what you don't know. The catch is that admitting ignorance feels like admitting failure—especially when the opposition intervenes. But a single number that misses by 40% is worse than a corridor that spans 15–60% and says 'we'll know more after year one.'

What usually breaks first is the assumption that future weather patterns will mirror the recent past. That's not a statistical error—it's a category mistake. Quick reality check: your historical data only contains events that happened, not the ones that could have happened. The utility planner who presents a point estimate for storm-hardening costs is effectively guaranteeing a forecast that no meteorologist would touch. I watched a Midwest co-op rebuild their entire costing framework after a derecho hit a corridor they had marked as 'low risk' based on thirty years of records. The CFO later admitted they had never asked the engineering team to model a compound event—ice on top of wind, then flooding. They assumed perfect independence. The second event always proves you wrong because there is always a second variable you left out.

Risk analysts with too much confidence in historical data

You ran a Monte Carlo simulation with 10,000 iterations. The 90th percentile looks comfortable. Your boss likes the chart. Here is the problem: your input distributions came from a dataset that ends in 2023, and the grid you're costing has a 40-year asset life. The analyst who trusts the mean too much is the same one who will defend a ±5% confidence band as 'conservative.' It's not conservative—it's precise fantasy. The trade-off here is between statistical rigor and operational truth: you can have a tight model that fails on the first outlier, or a wide model that keeps the lights on. Most teams skip the step where they stress-test their assumptions against a synthetic event—something that has never happened but is physically possible. That hurts. But the second event doesn't care about your p-values.

I have seen risk teams spend months calibrating failure rates for transformers, only to ignore the correlation between substations on the same feed. When the second event came—a wildfire that took out two lines simultaneously—their cost projection was off by a factor of three. The perfect-information assumption was hiding in the correlation matrix they never built. So what do you do? You force yourself to hold one variable at a time and ask: 'If this number is wrong by 30%, does the decision change?' If the answer is yes, you don't have a cost estimate—you have a bet.

'We had thirty years of data. We assumed that was enough. The second storm didn't read our report.'

— Senior risk analyst, investor-owned utility, post-event review

CFOs who think past performance guarantees future costs

The hardest sell is to the person who signs the check. CFOs are trained to forecast based on trend lines, and trend lines look safe when they're straight. The problem is that grid resilience costs are not linear—they jump. One transformer failure can cascade into a week-long outage that costs ten times the capital avoided. The CFO who says 'we have managed similar programs within budget for five years' is ignoring that those programs never faced a compound event. That's the trap: past performance does guarantee future costs, but only for the exact same conditions. And conditions change. A 2021 ice storm in Texas, a 2023 wildfire in Hawaii—each event rewrites the cost curve. The CFO mindset that resists funding 'what-if scenarios' is the same one that will approve emergency spending at 3x the original estimate after the second event hits.

The fix is not to argue—it's to reframe. Show them two numbers: the cost of preparing for the second event, and the cost of not preparing. Don't use percentages; use real dollars from a comparable jurisdiction. I have seen this work when one CFO finally said, 'Okay, run a scenario where everything that can fail does fail.' The number was ugly, but it was honest. And honesty, in costing, is the only thing that survives contact with the second event.

What You Should Settle First

Understanding your current risk exposure

Most teams skip this: they start costing before they know what they actually own. I have seen a grid operator spend three weeks building a perfectly formatted cost model—only to discover their oldest substation had undocumented relay settings that doubled the failure probability for every scenario. That hurts. You can't price resilience if you don't know which assets are already hanging by a thread. Pull your outage logs. Map the last five weather events against your equipment age. The catch is most organizations keep this data in three different spreadsheets nobody talks about. A quick inventory audit—yes, the boring kind with serial numbers and inspection dates—will save you from costing a fantasy.

Getting real about data quality

Your cost model inherits every lie your data tells. Dirty data means clean outputs that are still wrong. We fixed this by running a simple sanity check: take the worst ten percent of your historical failure records and see if the timestamps actually align with weather logs. They usually don't. One client had a full year of maintenance records where the 'completion date' was always December 31st—someone was just closing tickets to hit a quota. That's the kind of rot that makes your per-event costing look sensible until the second storm hits and the real failure rate doubles. The tricky bit is that data quality improvements cost money too, and nobody budgets for that. So settle this before you open a spreadsheet: accept that your data is probably wrong, then decide how much wrongness you can tolerate. A useful rule—if your confidence interval for asset age is wider than five years, stop and clean first.

„A model fed by bad data doesn't fail gracefully. It fails with precision.“

— utility risk analyst, after a costing exercise that missed a critical switchgear failure

Setting stakeholder expectations upfront

Here is where the buy-in trap lives. Engineers want exact numbers. Budget holders want a single answer. Neither will get it—your costing model produces ranges, not point estimates, and the second event always widens those ranges. You need to tell them that before you start. Not during the review meeting. Before. I have watched costing exercises die because a finance director saw a $4.2 million figure on Monday and a $6.8 million range on Tuesday and assumed the model was broken. Wrong order. The model was honest; the expectation was not. Get your stakeholders to sign off on a principle: this costing admits ignorance, and the output is a probability band, not a bill. One rhetorical question helps: would you rather have a precise number that's guaranteed wrong after the second event, or a fuzzy range that still holds? If they pick the first, walk away. The prerequisites are not technical—they're political. Sort that first, and the rest becomes manageable.

Core Workflow: Costing That Admits Ignorance

Step 1: Catalog what you don’t know

Most teams start by listing assets—transformers, feeders, backup generators. That feels productive, but it’s a trap. You’re listing what you *do* know. Instead, pull out a fresh whiteboard and write the unknowns: how long will parts actually take to arrive when the usual trucking route is flooded? Which crew shifts will be stranded at home because the same storm hit their neighborhood? I have watched a grid costing model fail inside three hours because nobody asked “What if our own staff can’t reach the substation?” The first pass should be a confession sheet, not a confidence builder. Wrong order. You catalog ignorance before you catalog hardware. That hurts, but it keeps the later math honest.

Step 2: Build scenario bands, not point estimates

A single number—say, $340,000 for storm recovery—looks decisive. It's also guaranteed wrong. The second event will arrive with different damage patterns, different lead times, different regulatory hoops. So stop pretending. Build three bands: a low-end that assumes near-perfect conditions (rare), a central band that reflects your best guess with the cataloged unknowns factored in, and a high band that assumes everything you don’t know turns hostile. The tricky part is forcing yourself to make the high band uncomfortable—not polite. If the gap between low and high is less than 40 percent, you haven’t admitted enough ignorance. Quick reality check: I once saw a team defend a band spread of 18 percent. Their second event cost 3x the central estimate. The spread should feel alarming; that’s the point.

Step 3: Stress-test with plausible second events

Here is where the workflow earns its keep. Take your central-band estimate and ask one question: what happens when a second event hits *before* the first recovery finishes? A substation fire during flood repairs. A cyber disruption that locks procurement systems while crews are still out. Don't pick a freak asteroid—pick something that has a real precedent in your region or one region over. Then trace the cost consequences manually. The catch is that most costing tools hide this cascade; they assume each event is independent and the system resets between shocks. It doesn't. We fixed this by literally printing the recovery timeline and overlaying a second event with a transparent marker. When the lines overlapped, costs doubled. Not theoretically—concretely. That exercise alone cut our overconfidence bias by enough to change how we presented budgets to the board.

‘The second event doesn't care that you already spent your contingency. It arrives anyway, and it brings friends.’

— field operations lead, after a back-to-back ice storm and transmission fault

Your final output should be a set of three scenario bands, each with a footnote listing the unknowns that could push costs outside that band. No single number. No perfect-information fantasy. Next, you will need tools that help you maintain this discomfort—or tools that quietly erase it. That's where the real traps live.

Tools and Setup That Help (or Mislead)

Spreadsheet traps and how to avoid them

Your costing model lives in a spreadsheet, right? Wrong order. The spreadsheet lives—and it bites back when the second event hits. I have watched teams build beautiful Excel workbooks with conditional formatting, named ranges, and lookup tables that all assumed one thing: the next storm costs exactly what the last one did. That's a trap dressed up as productivity. The formula that worked for a single outage chain will silently double-count shared mobilisation costs when two events overlap—because your grid never fails in neat sequence.

The fix is boring but brutal. Break your cost line items into shared and exclusive buckets before you write a single SUM. Crew rates, fuel surcharges, and equipment rental often sit in both; your spreadsheet will happily add them twice if you let a VLOOKUP point at the wrong table. Use a separate sheet just for correlation assumptions—flag any cell that assumes independence between two regions. Quick reality check—I have seen a 40 % cost overrun trace back to one cell reading the wrong tariff date. That hurts.

One trick that saves days: build a 'clash table' that tests your model against two simultaneous failures. If the total cost doesn't exceed the sum of both individual costs by at least 15 %, you're probably hiding shared resource bottlenecks. Spreadsheets hide those beautifully—they never argue.

Simulation tools that handle uncertainty well

Monte Carlo tools are not magic. They're just honest about what you don't know. Most grid costing teams skip them because they look intimidating, then rebuild the same deterministic spreadsheet three times after each black swan event. The catch is—many simulation packages come pre-loaded with cost distributions that fit industrial equipment replacement curves perfectly, but fail for vegetation management or regulatory fines. You need to swap the default probability shapes for your own historical scatter.

We fixed this by running 500 iterations with a simple open-source tool called 'greta' (Bayesian simulation in R), feeding it three years of actual event costs from our region. The output didn't give us a single number—it gave us a fan of possible outcomes. That fan is the only honest costing document you will ever produce. The tricky part is interpreting the tail: the 95th percentile cost is usually 2.3 times the median, and that gap is where your board will ask questions. Simulation tools that handle uncertainty well don't make the answer prettier—they just stop you from being surprised by the second event.

The tool that never says 'I don't know' is the most dangerous one on your desk.

— overheard at a utility risk workshop, five days before a double-outage exposed a 3x cost overrun

Data sources you can trust (and ones you can't)

Your own maintenance logs from 2019? Trust them—barely. Vendor-published 'typical restoration durations' from a national database? Don't touch them unless you have validated against your actual crew travel times in winter mud. The distance between a data sheet and ground truth is exactly the size of your cost error. We learned this the hard way when a reputable supplier's transformer replacement duration assumed dry concrete curing times—in a flood zone.

Historical weather archives from NOAA or your national met office are generally solid for frequency data, but they mask microclimate effects. A feeder sitting in a valley will see twice the ice loading the county average suggests. Pair broad weather data with your own SCADA event timestamps—that cross-reference is worth more than any premium dataset. And never trust cost data from adjacent utilities unless you know their labour rates, overtime policies, and whether they subcontract crews. I have seen a 30 % variance between two utilities that both claimed 'industry-standard' restoration costs. The difference was union rules, not physics.

One signal you can always trust: invoices you actually paid. Build your baseline from those, then scale using inflation and crew availability indices. Don't start from a consultant's benchmark table—it will mislead you exactly when the second event arrives, because benchmarks average away the very outliers that define grid failure economics. That's the pitfall: smooth data feels safe, but resilience costing lives in the lumpy, ugly, uncorrelated details. Start there, or your model will prove you wrong on the next blackout.

Variations for Different Constraints

Small co-op vs. large investor-owned utility

The difference isn't scale—it's data poverty. A small co-op serving three thousand meters might have one weather station and a spreadsheet for asset ages. I have watched a co-op try to cost resilience by assuming a 30-year replacement cycle, only to discover their transformers were already running at 110% load because they had no SCADA. The large IOUs have entire teams producing perfect-looking cost curves. The trick is—both are wrong, just in opposite directions. The co-op underestimates because it lacks failure history; the IOU overestimates because its models assume the data it does have tells the whole story. We fixed this for one mid-size utility by capping the confidence interval at 65% on any single hazard type—if the model claimed 95% certainty, we forced a ±40% cost band. That sounds painful, but it saved them from a $2M transformer investment that would have sat idle for five years. Wrong order. The co-op should spend the first $50k on sensors, not replacement parts.

Wildfire-prone vs. hurricane-prone regions

Fire and wind break your costing in opposite ways—and most teams copy the same template. Hurricane risk follows a power-law: you can model a Category 5 event every 30 years, price the hardening, and call it done. Wildfire is worse because the exposure is continuous, non-linear, and tied to human error—a dry pine needle on a hot Tuesday. The catch is that hurricane costing rewards investment in the big event (elevated substations, buried feeders), while wildfire costing punishes you for ignoring the second event: the post-fire mudslide that takes out the underground replacement line you just built. I have seen a California utility run their costing model assuming a 0.5% annual burn probability per mile, then watch two fires hit the same corridor in eighteen months. Quick reality check—that probability doubled, and their cost assumptions broke across every scenario. The fix is to run a 'consecutive loss' multiplier: if your model assumes one major event per decade, double the replacement cost for the second event in the same zone. It shifts the optimal spend from 'protect everything' to 'create redundancy corridors'. Not pretty. But survivable.

Regulated vs. deregulated markets

Regulated utilities can amortize resilience over rate cases—so their costing assumes a stable 20-year payback. Deregulated players? They need a 4–7 year recovery window, or the investor walks. That changes everything. A regulated utility might bury lines because the cost gets socialized across the rate base; a merchant generator in a deregulated market will instead install microgrid switches that can island three critical customers for the same price. The pitfall is that regulated teams keep 'reliability' metrics locked at the system level, while deregulated teams ignore long-term risk entirely—each group's costing model bakes in an assumption that the other side would call fantasy. Most teams skip this: you need two separate cost-of-capital inputs for the same asset, one for the regulated rate case and one for the merchant cash flow. If the gap exceeds 2×, you're pricing resilience for the wrong buyer. One Texas co-op I worked with solved this by building a 'regulatory risk slider'—move it toward deregulated, and the model automatically shortens the depreciation schedule and adds a 15% liquidity premium. That's not game-changing. It's honest.

'We spent six months building a costing tool that assumed the regulator would approve every dollar. Then a wildfire blew through a zone the model said was low-risk. The regulator asked why we had not costed for the second event.'

— utility risk manager, after a PUC hearing that paused their full rate case filing

The next time your costing spreadsheet glows green, ask yourself: whose constraints did you design for? The small co-op's data limit, the wildfire corridor's consecutive-loss multiplier, or the deregulated market's 4-year clock? Pick the wrong one, and the second event will remind you—loudly, expensively—that your model only captured one version of reality. Adjust the workflow before the regulator or the storm does it for you.

Pitfalls: What to Check When It Fails

The hindsight bias in historical event data

Most teams pull past outage records and assume those numbers are honest. They're not. The records show what was repaired, not what could have happened. I have seen a utility cost model built on five years of storm data—every entry was a post-mortem summary that omitted the near-misses, the cascading failures that barely got contained, and the events where human intervention masked a deeper grid weakness. The result? Their costing predicted a single-event cap, but the second event—a moderate windstorm—blew past their reserve because the historical data had been cleaned of all the ugly dependencies. Quick reality check: if your dataset contains only events that were fully resolved within 24 hours, you're training your model on survivor bias. The fix is painful but necessary: go back to raw incident logs, including the ones marked “no damage” but that required emergency rerouting. That hidden load shift is a cost you're ignoring.

Escalation factors that compound errors

You model a 10% escalation factor for labor and materials. Sounds safe. Then the second event hits, and suddenly your contractor rates double because the first event already depleted the regional workforce. That's not a linear multiplier—it's a feedback loop. The tricky part is that most costing tools let you set one escalation percentage per category, but they don't model sequence. Wrong order. If event A consumes the cheap crews, event B pays premium rates for whoever is left. We fixed this by running two passes: one with the standard escalation, then a second where we manually applied a scarcity multiplier to the second event. The difference was 40%. That hurts. Don't let a single escalation field lull you into thinking risk compounds linearly—it compounds like debt, with interest on interest.

“Every cost model I have ever debugged that failed did so not because the math was wrong, but because the assumptions were too tidy.”

— field engineer, after a grid resilience workshop

Ignoring correlation between risks

Most models treat wind damage, flooding, and supply-chain delays as independent variables. They're not. A hurricane that floods a substation also closes the roads your repair trucks need. That's not two separate line items—it's one compound event that multiplies downtime. I watched a team spend weeks calibrating separate probability curves, then lose confidence in a single day when a moderate ice storm took out both the overhead lines and the backup generator yard. The correlation was right there in the geography, but their spreadsheet had no cell for “simultaneous failure.” Here is the trade-off: adding correlation matrices makes the model heavier and harder to explain to stakeholders. However, skipping them means your confidence intervals are a lie. Start simple—just flag any two risks that share a physical location or a common resource (like the same crane crew). If those two ever trigger together in a scenario, your cost floor needs to jump, not just bump.

The catch is that once you fix one pitfall, another surfaces. Don't chase perfection—chase visibility. If your model breaks on the second event, map the exact assumption that cracked. Was it the clean data? The linear escalation? The silent correlation? Document that, patch one variable, then run the same scenario again. Not yet convinced? Then look at your last three post-mortems. I bet at least two of them mention “unexpected interdependency.” That's your debugging starting point—not a new algorithm, but a better question to ask yourself before the next event proves you wrong.

FAQ and Sanity Checklist

How often should I update my cost model?

Every time a storm passes your substation, honestly. I have seen teams lock a model in January, run it through December, and act surprised when the February ice storm—barely a blip in historical averages—blew their reserve margin apart. The cadence is not calendar-based; it's event-driven. Update after every significant outage, every time a vendor changes transformer lead times, and definitely after you close a financial quarter and see what you actually spent on emergency repairs. That said, don't re-baseline daily. You will chase noise. The sweet spot: one full recalculation per quarter, plus a quick sanity pass within 48 hours of any event that caused a trip or a curtailment. Skeptical? Run your current model against the last three unplanned outages. If the cost prediction drifted by more than 18% on any single event, your update interval is too long.

What if my second event is worse than any historical precedent?

Then your model needs a stress band, not a point estimate. The trick is to admit that the 100-year record is a ceiling you have already cracked. I built a costing sheet once where the second event in a single season exceeded the combined damage of the previous decade. Historical precedent gave me nothing—no distribution, no confidence interval, just a blank stare from the spreadsheet. What saved us was a simple rule: never let expected value be the only number on the page. Add a column labeled 'tail scenario' and plug in 2.5× your worst historical single-event cost. Then ask yourself: can the budget survive that? If the answer is no, you're not resilient—you're lucky so far. The catch is that most planners treat extreme events as improbable outliers rather than inevitable arrivals. Quick reality check—does your model even have a cell for 'unknown unknowns'? If it doesn't, you're pricing for a world that hasn't hit you yet.

‘The second event always costs more than the first because the first already consumed your cheap spares and your crew overtime budget.’

— paraphrased from a transmission reliability engineer I met at a grid workshop, 2023

Who signs off on uncertain numbers?

Nobody who wants to keep their job, if you present them as certain. That's the real pitfall. You need a signatory who understands that a resilience cost estimate is a probability fan, not a single invoice. Push for a risk owner—someone with budget authority who has explicitly agreed that the model's lower bound is optimistic and the upper bound is painful. I recommend a short document: one page that lists the three biggest assumptions (weather frequency, replacement lead time, overtime multiplier) and the range each assumption spans. Have that person initial next to the range, not next to the dollar figure. That way when the second event hits and the cost overshoots by 40%, you're not defending a bad guess—you're revisiting a shared uncertainty. The teams that fail here are the ones who let a finance controller sign off on a single number. Wrong order. The sign-off should be on the method, not the result. Before you close the model, run a sanity checklist: Does the total cost stay plausible if you double the frequency of minor events? If you halve the crew availability? If the answer breaks the budget, you have not finished costing—you have started negotiating. Get that negotiation in writing before the next event proves you wrong.