National Grid’s SAP Go-Live: Billing Problems After Hurricane Sandy
National Grid's 2012 SAP go-live collided with Hurricane Sandy and severe readiness problems, producing major payroll, supply-chain, finance, and later billing-related disruption across U.S. operations.
The title’s ‘billing problems’ are only part of a broader SAP failure
National Grid’s November 2012 U.S. Foundation Program consolidated multiple legacy finance, HR, supply-chain, and fleet systems onto SAP. The best-documented immediate post-go-live failures involved payroll, procurement, financial close, and related back-office processes. Customer billing problems also appeared in the wider period of system conversion, but the 2012 crisis should not be reduced to billing alone. [1] This distinction matters because utility systems have multiple customer and employee-facing processes. A single headline can otherwise merge separate conversions and create a cleaner causal story than the regulatory record supports.
The hidden assumption
National Grid was consolidating finance, human resources, supply chain, and fleet systems across U.S. operations onto one SAP platform. The engineering implication is that event-aware go-live governance, realistic workforce and payroll scenarios, clean master data, rollback authority, and independent operational-readiness review cannot remain an aspiration or a postmortem recommendation; it has to be turned into measurable release criteria, ownership, and tested operating procedures.
The go-live followed Sandy by only days
Superstorm Sandy struck at the end of October 2012 while National Grid was completing conversion. The company went live on November 5 while thousands of employees were working unusual locations, long shifts, emergency assignments, and large amounts of overtime. The New York audit later criticized the implementation as flawed and documented extensive stabilization cost. [2] The company had legitimate reasons to avoid further delay, but disaster response radically changed the input distribution seen by payroll and procurement. Event-aware governance would treat that as a change in production conditions requiring a fresh readiness decision.
Where the rollout became fragile
The company had already moved the launch date and faced a difficult decision when Sandy created extraordinary workload just before go-live. The engineering implication is that event-aware go-live governance, realistic workforce and payroll scenarios, clean master data, rollback authority, and independent operational-readiness review cannot remain an aspiration or a postmortem recommendation; it has to be turned into measurable release criteria, ownership, and tested operating procedures.
The first payroll exposed problems immediately
The audit said the first payroll after go-live revealed errors far above expected levels. Workers reported missing or incorrect regular and overtime pay, and the company had to add substantial resources to investigate and correct records. The extreme labor patterns created by Sandy amplified defects that normal payroll testing had not fully represented. [3] Payroll is especially unforgiving because an error can affect mortgages, taxes, child support, union rules, and overtime all at once. Employee trust can collapse faster than software teams can clear the backlog.
Why the failure spread
Payroll errors, procurement disruption, finance-close problems, and other operational issues spread because many back-office functions were consolidated onto the same platform. The engineering implication is that event-aware go-live governance, realistic workforce and payroll scenarios, clean master data, rollback authority, and independent operational-readiness review cannot remain an aspiration or a postmortem recommendation; it has to be turned into measurable release criteria, ownership, and tested operating procedures.
Supply-chain and finance problems followed payroll
Within weeks, the company was also dealing with purchasing, vendor-payment, and financial-close problems. Union complaints described material orders routed incorrectly for approval and delivery instructions that had to be communicated through workarounds. Shared enterprise integration turned one troubled go-live into a broad operational burden. [4] Procurement disruption during storm recovery creates a safety dimension: field crews need poles, transformers, cable, vehicles, and contracted services. Back-office software therefore participates indirectly in physical grid restoration.
What recovery really required
Stabilization required hundreds of additional contractors, workarounds, union and regulatory intervention, and years of remediation rather than one patch. The engineering implication is that event-aware go-live governance, realistic workforce and payroll scenarios, clean master data, rollback authority, and independent operational-readiness review cannot remain an aspiration or a postmortem recommendation; it has to be turned into measurable release criteria, ownership, and tested operating procedures.
The cost of stabilization eventually dwarfed the original estimate
New York regulators said the original expected system cost was about $384 million and that total cost across National Grid’s U.S. companies could reach roughly $945 million after remediation and stabilization. The company generally accepted the audit recommendations while disputing parts of the analysis; shareholders rather than ratepayers were expected to absorb excess costs. [5] The cost escalation also illustrates why stabilization should be budgeted as a risk before go-live. Large programs frequently treat implementation cost as the project and post-go-live recovery as an exception, even though recovery can dominate total cost.
The biggest go-live mistake was treating calendar commitment as stronger than operational context
A major utility migration should have explicit criteria for extraordinary events. When a hurricane changes employee location, overtime, supply demand, contractor volume, and emergency purchasing simultaneously, the workload is no longer the workload used in ordinary rehearsal. Leadership needs authority to pause even an expensive cutover. A stop/no-stop rule should be set before leadership is under deadline pressure. Otherwise managers who have spent years preparing for launch can rationalize conditions they would have rejected earlier.
ERP test data must include emergency operations
Utilities need scenarios for storm labor, mutual assistance, union-rule combinations, emergency procurement, damaged facilities, estimated customer usage, late invoices, and unusual project codes. Testing average payroll or standard purchase orders cannot prove a system ready for the period when the utility is under maximum public pressure. Disaster-shaped test scenarios also reveal whether master data and approval hierarchies can cope with employees temporarily reassigned across regions and work centers, which ordinary steady-state tests may never exercise.
Why National Grid’s SAP rollout belongs in software-failure history
National Grid belongs in software history because it shows how a technically planned ERP go-live can become much more dangerous when external conditions invalidate readiness assumptions. Sandy did not create every defect, but it greatly amplified the operational consequences. The enduring lesson is that go-live decisions must respond to the real world, not to the sunk cost of missing another project date. The lesson applies beyond utilities: any enterprise platform serving emergency operations needs a go-live model that can react to external shocks, because the worst time to discover hidden process assumptions is during a real disaster.
Works Cited
- 01New York State — National Grid SAP Audit Press Release apps.cio.ny.gov
- 02
- 03National Grid — Annual Report and Accounts 2012/13 nationalgrid.com
- 04Times Union — National Grid Inquiry Sought timesunion.com
- 05NY Public Service Commission — National Grid SAP Stabilization Status documents.dps.ny.gov
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.