Ask anyone who has worked in energy or commodity trading technology and they will have a story about an ETRM or CTRM programme that ran months late and well over budget. The causes are rarely mysterious. In our experience across more than a hundred projects, most overruns trace back to a small number of decisions made, or avoided, early in the programme.
1. Agree a scope baseline, and protect it
Programmes that start with vague scope accumulate requirements as they go. Define in-scope commodities, processes, interfaces and reports explicitly, and agree a change process that evaluates every addition for cost, time and value. A clear baseline is the single best defence against scope creep.
2. Decide that standard functionality comes first
Every customisation adds build, test and upgrade cost for the life of the system. Make "out of the box unless there is a compelling business case" an explicit principle, with a governance forum that approves exceptions. Changing a process is usually cheaper than changing software.
3. Start data migration on day one
Data migration is routinely underestimated. Historical positions, long-term contracts, reference data and counterparty records all need cleaning, mapping and reconciliation. Begin profiling and cleansing data at the start, and plan several trial migrations before cut-over.
4. Design integration up front
Interfaces to market data, scheduling, finance, settlement, exchanges and forecasting models are where many programmes stumble. Build an interface inventory early, define ownership for each side of every interface, and test integrations end to end long before go-live.
5. Test with real business scenarios
Testing individual functions is not enough. Define realistic end-to-end business scenarios, from deal capture through scheduling, risk, invoicing and accounting, and use them to drive system testing and user acceptance testing. Scenarios written during requirements and reused in testing catch problems when they are cheapest to fix.
6. Commit real business people
Programmes fail when the business treats them as an IT project. Traders, schedulers, risk managers and accountants must have dedicated time to define requirements, make decisions and test. Back-filling key roles is far cheaper than delay.
7. Plan cut-over around the business calendar
Go-live dates that collide with month-end, peak trading periods or harvest seasons create avoidable risk. Plan cut-over with the business, consider parallel running for critical processes, and make sure support is in place for the weeks after go-live.
Underpinning all seven: governance
Clear governance ties these decisions together: a steering committee with real authority, regular and honest status reporting, and someone independent enough to challenge both the vendor and internal teams when it matters.
Already off track?
Many of these decisions can be revisited mid-programme. A structured health check identifies where scope, data, integration or testing are slipping and what it would take to recover. Orivyn supports both new and in-flight programmes through requirements and design and implementation and integration support.
Related: What keeps CIOs awake at night: the real risks of ETRM and CTRM implementations and upgrades.
