Leading Practices for ETRM System Conversion, Cutover & Go-Live

Find out why a smooth go-live of a new ETRM system can go a long way in helping an organization avoid precipitous drops in productivity after launch and realize benefits of enhanced transactional consistency afforded by leading software.

Energy or commodity trading and risk management (ETRM or CTRM) system implementations can be highly complex projects. The fact that, in many cases, they serve almost the entire origination-to-settlement transaction life cycle means that stakeholders from across the organization will be contributing to the project—trading, risk, scheduling, accounting, etc. The challenge grows as the number of regions and/or commodities increase.

Moreover, ETRM initiatives very often involve extensive integration with other applications in the company’s IT system landscape such as enterprise resource planning (ERP) and data warehouse solutions. Just getting to go-live is enough of a challenge, but the actual process of deploying the solution and starting it up—conversion and cutover—may be the most daunting phase of the project. Though there are other steps that can be taken to ensure overall success, a detailed, clear, well-reasoned and rehearsed plan is the key to a smooth launch.

Start Early & Integrate with the Rest of the Project 

One of the most common mistakes with major IT systems implementation projects is to leave conversion and cutover planning to the later phases. This often results in missed opportunities to identify, build, and test tools or utilities to assist with cutover, as well as fewer chances to practice. The ideal time to start preparing for conversion and cutover is during the initial planning phase of the project. This effort can culminate in a summary approach document that addresses the major facets and high-level timeline for related work.

Project teams often treat data conversion as a relatively simple step involving the movement of objects from one system to another. Data mapping and entry should be high on the priority list and are important in standing up any new application. New system implementations offer a rare opportunity to cleanse and harmonize data sets that have slowly degraded in quality over years of use and misuse in the legacy system environment. This can erode the value proposition of the new system and encumber future reporting and analytics initiatives with poor data quality limiting business insight.

Furthermore, conversion and cutover shouldn’t be treated as an isolated, parallel activity to the rest of the project workstreams. It’ll share resources, artifacts, deliverables, and many tasks with the rest of the project to mutual benefit. For example, conversion will likely require the development of one or more conversion programs or database scripts. These items should follow the same software development life cycle (be it Agile or waterfall) as any other technical development object to elicit/analyze requirements, design, build, and test.

Beginning conversion and cutover planning early can also pay significant dividends to the rest of the project through the creation of more realistic development, testing, and training system environments for the broader team to utilize while also gaining valuable experience rehearsing the steps that’ll be required for go-live. Given the wide range of stakeholders that’ll likely be engaged throughout the conversion and cutover process, it should also be tied into the overall communication plan for the project.

Define Roles & Responsibilities 

Well-defined accountabilities for all aspects of the conversion and cutover workstream will significantly reduce the likelihood of non-performance, missed handoffs, or issues with completeness/accuracy of the data migration. Depending on the scope and scale of the project it might be worth identifying a dedicated conversion and cutover lead reporting directly to the project manager. On smaller initiatives, the project manager may be able to fulfill this role. The table below provides examples of some of the most common contributing roles:

Organize the Cutover Activities Into Phases & Activity Groups

It’s not uncommon for the conversion and cutover process for a highly integrated E/CTRM system to involve hundreds of interdependent tasks that’ll be performed by dozens of different team members over the course of weeks or even months before, during, and after go-live. Breaking these tasks down into major phases and further into more manageable groups of related activities can clarify accountability and streamline management and monitoring. The process can be logically divided into three primary phases:

 

1. Pre-Cutover — Activities occurring prior to “the point of no return” such as database back-ups, code, configuration deployment (e.g., transports), and system health checks, etc.
2. Cutover — The core effort to populate the new system with necessary information for Day 1, including the loading of master and reference data, writing on opening inventory balances, converting transactions, etc.
3. Post-Cutover — Final tasks readying the new E/CTRM environment and integrated systems for use like resuming background jobs, starting up interfaces, provisioning user access, etc.

Within each of these conversion and cutover phases tasks can be reasonably organized into technically or functionally related groups. Below is one possibility for such a structure:

While the process isn’t perfectly linear, and there could be many other effective ways to divide the activities, this type of model will enable project management to assign accountability and track progress (see Roles & Responsibilities section above) more clearly.

For each major item, the owner should work to decompose the activities by defining the following:

• Assumptions — Identify important assumptions about the conversion or cutover activity that informs what the steps are and how they’ll be performed. For example, an assumption may be that a transaction conversion is intended to be for open items only.
• Preconditions — Determine what must be true before beginning the conversion/cutover steps in this activity group. This will aid in identifying key interdependencies, as well as entrance criteria for each phase/group.
• Conversion Steps — Enumerate the specific cutover steps to be taken. This might take the form of a spreadsheet list, a document with steps and screenshots, etc.
• Postconditions — Define what must be true once the conversion/cutover tasks listed above are complete. This block often includes verifications, validations, reconciliations, and signoffs that are relevant from a control perspective.

The sum of these parts for each activity group, once assembled, will constitute the bulk of the detailed conversion and cutover plan.

Identify Deliverables, Artifacts & Work Papers

Achieving a successful E/CTRM go-live will undoubtedly require the project team to produce a number of specific deliverables to satisfy stakeholders and secure their approval. At a minimum, a detailed plan will be expected.

Other requirements may include items such as trial balances for inventory conversion, verified mark-to-market (MtM) reports for open positions, a validated counterparty list, etc. Identifying these, and other, necessary deliverables and incorporating them into the overall project plan will ensure that the team can efficiently produce them in the flow of delivery and avoid a mad rush at the 11^th hour to secure endorsement for go-live.

Test, Rehearse & Coordinate Execution

As the old adage goes, “practice makes perfect”, and this applies just as readily to conversion and cutover for system implementation projects. A standard waterfall implementation methodology will present several natural opportunities to test and revise the plan, as well as to rehearse execution coordination. Building the E/CTRM environments for integration testing, user acceptance testing (UAT), and for end-user training are excellent times to work in a dry run. For very large and complex projects involving a significant number of integrated systems and more substantial conversion activities, it may be worth considering a dedicated conversion test prior to the main event.

One aspect that sometimes receives inadequate attention is how the day-by-day, hour-by-hour coordination and communication will unfold during execution. During test passes and dry runs, capture actual execution times for key or long-running activities so that the plan can be refined. Use these test cycles to firm up the ways you’ll communicate and coordinate for the production go-live, whether that involves a standing conference line with appointed times for leads to dial in to provide updates, email trees to let contributors know when activities are running ahead/behind schedule, and escalation paths to get prompt decisions if/when things go awry. Even small wins can be an important boost to team morale. Crisp, daily status tracking and reporting can bring this type of recognition and set the team up for success in the coming days.

Consider ETRM-Specific Challenges, Risks & Post Go-Live Cutover Scenarios 

Every ETRM system implementation or upgrade project is different, and each will pose a unique set of risks, as well as post go-live needs to address, depending on the nature of the organization’s legacy systems, processes, and associated data. However, there are certain data elements that pose challenges for these types of projects, such as:

• Open Trades — Determine the trades and in which states in their life cycle need to be converted to produce a meaningful quarter-to-date, year-to-date, or life-to-date profit and loss (P&L).
• Historical Price Data — Risk metrics such as value at risk (VaR) depend on the availability of past price data. Determine which series and how much history is needed to enable these calculations.
• Prior Period Adjustments — Map out how adjustments to prior periods will be handled along with transactions such as late demurrage claims, etc.

In the broader context of conversion and cutover, don’t forget to also consider:

• A contingent “back out” plan if conversion and cutover must be aborted.
• Legacy system decommissioning requirements.
• Historical and cross-reference data.
• Reporting and access needs.

Conclusion

A smooth go-live of a new ETRM system will help the organization avoid a precipitous drop in productivity right after launch and begin to realize the benefits of the enhanced transactional fidelity afforded by class-leading software. Satisfying this objective can best be accomplished with clean conversion and cutover execution by:

• Starting early and integrating the workstream with the rest of the project
• Clearly defining and assigning roles and responsibilities
• Thoughtfully organizing the work into phases, stages, and logical groupings
• Identifying required deliverables, artifacts, and work papers
• Testing and rehearsing the conversion and cutover process itself
• Assessing risks and exceptional circumstances for mitigation