Why Your ETRM Project Is 18 Months Late

And Why It's Not Your Vendor's Fault

The Pattern I've Seen Too Many Times

Energy companies spend 18–36 months implementing Energy Trading and Risk Management (ETRM) systems. Budgets overrun by 40-80%. Go-live dates slip repeatedly. Post-implementation, the system is used at 30-40% of its designed capacity.

The vendor gets blamed. The implementation partner gets blamed. The project manager gets blamed.

But after leading the ETRM implementation at Zenith SA (Eni Group) and observing dozens of similar projects across the energy sector, I've reached a different conclusion: the root cause is almost never the vendor or the technology.

The Five Real Reasons ETRM Projects Fail

1. You Don't Know What You're Trading (Yet)

ETRM systems are designed around trading strategies, risk models, and position management methodologies. But most energy companies start their ETRM implementation before they've fully defined their trading strategy.

The result: requirements change during implementation. The vendor builds what you asked for in month 2. By month 14, you want something different. The gap between "what we specified" and "what we need" becomes the primary driver of delays.

2. The Data Migration Is Always Underestimated

ETRM systems require clean, structured, validated data: counterparty data, contract data, price curves, position history, risk parameters.

In my experience, organizations consistently underestimate data migration complexity by a factor of 3-5x. What was scoped as a 3-month workstream becomes a 12-month bottleneck.

Why? Because the data quality issues discovered during migration reveal process gaps that have existed for years — and fixing them requires business process changes, not just technical work.

3. Regulatory Requirements Keep Moving

Energy markets are among the most heavily regulated in the world. REMIT, EMIR, MiFID II, country-specific reporting requirements — the regulatory landscape changes faster than most ETRM implementations move.

A requirement that was out-of-scope in month 1 becomes mandatory by go-live. The vendor is asked to implement it. The timeline slips.

4. The Integration Landscape Is More Complex Than Anyone Admitted

ETRM systems don't operate in isolation. They need to integrate with: ERP (billing, settlements), risk systems, market data providers, regulatory reporting platforms, treasury systems, BI/analytics platforms.

Each integration is a project within a project. Each has its own data model, API constraints, and business logic. The integration complexity is typically scoped optimistically and executed pessimistically.

5. The Business Doesn't Own the Project

The most common failure pattern: IT owns the ETRM project. Business users are "stakeholders" who attend steering committee meetings.

ETRM is a business system. Trading decisions, risk limits, position management — these are business functions. When IT owns the project, business requirements are filtered, delayed, and often misinterpreted.

The business then receives a system that technically works but doesn't fit how they actually trade. They work around it. They build shadow systems in Excel. The ETRM investment delivers 30% of its promised value.

What Successful ETRM Implementations Do Differently

They start with a trading strategy review. Before vendor selection, they document current and intended trading activities, risk appetite, reporting requirements, and regulatory obligations. The ETRM selection is driven by business requirements, not IT preferences.

They run data quality as a parallel workstream from day one. Data migration starts on month 1, not month 8. Data quality issues are surfaced early and treated as business problems, not IT problems.

They assign business ownership. A senior trading or risk professional owns the project — not IT. IT is a delivery partner, not the project owner.

They build regulatory flexibility into the architecture. Rather than hardcoding regulatory requirements, they design for change — configurable reporting, modular regulatory components, documented override procedures.

The Honest Assessment

If your ETRM project is delayed, ask these questions:

• Has your trading strategy changed since the project started?
• What percentage of your data migration scope was discovered after project kickoff?
• Who makes final decisions on business requirements — a trader or an IT project manager?
• How many regulatory requirements have been added since contract signing?

The answers will tell you more about why the project is late than any vendor performance review.

ETRM projects are hard. They operate at the intersection of complex business domains, regulatory requirements, and technical integration challenges. Vendors and implementation partners share responsibility for outcomes.

But the organizations that succeed treat ETRM as a business transformation program — not a software installation project.