Last month I presented at the ETRM Summit “virtual” conference hosted by Alpha Insight and CCRO.  The conference featured many energy risk experts and covered topics related to the new market environment and critical changes we face as we return to “the new abnormal.” Topics included energy markets outlook, risk modeling, modeling tail events, regulatory risk, credit challenges, technology risks and more.

My presentation was titled A Front/Middle Office Perspective on CTRM Implementations. Most CTRM presentations focus on project management from the perspective of the vendor, IT or consultant perspective. The purpose of my presentation (and this blog) is to provide a front and middle office perspective on CTRM projects by focusing less on the technical or project management aspects of these implementations and more on providing significant benefits to the business and commercial team. CTRM systems are traditionally viewed as technology projects, but like most technology projects they are not successful if they are not aligned back to business objectives. Incorporating an integrated approach including commercial strategy, people, process, and technology is critical to the success of any CTRM implementation.

In this blog, I will summarize the ETRM Summit presentation and cover topics like the changing landscape of CTRM systems and the impact to the business, why an integrated approach is needed and what a path to success looks like (and landmines to watch for). Let’s dive in.

The changing CTRM landscape impacts commercial decision making  

I think it's useful to have some historical context for this discussion, so we'll go back a couple of decades and see how the role of the CTRM solution has changed.

2000-2015 CTRM architecture

The ultimate objective in the early 2000s was straight-through processing and reducing the amount of “touches” or duplicate entry that was occurring during the transaction life cycle. I was involved with projects that were trying to eliminate trades being reentered and modified 7 to 10 times apiece.  That was a common objective during this period. CTRM systems were the center of the trading universe and became broadly integrated across the entire life cycle of transactions. 

However, there was little integration between decision support and these official ETRM transaction systems (illustrated by the dashed line in the diagram below).  The tools that were being used to make commercial decisions were separate and not well integrated with the CTRM solution or other data. These two different solution environments sometimes had different valuation models and other inconsistencies.

2020 CTRM architecture

Flash forward 20 years to 2020, when the best practice architecture has evolved. Now, data management is being emphasized as a central component of the solution architecture. CTRM systems are no longer the center of the world.  These data stores are increasingly used to organize unstructured and structured data. An example of this would be production forecasts or nominations that are provided in many different forms during unstructured data collection, and then are further processed into a standardized data structure, which can be published to all the downstream systems. Integration is also greatly improved between all these components, including trading analytics and the other tools that are used to make commercial decisions. CTRM systems and decision support tools make use of the same end of day data, as well as near real-time data.

The need for an integrated approach

Having covered historical trends in CTRM architecture, we can now discuss commercial goals.  In order to fully take advantage of the best practice architecture described above, you need an integrated approach that not only focuses on the technology but also the commercial strategy, people, and process that this technology supports.

• Strategy and people

  It’s important to have clear objectives that in turn lead to a definition of roles and responsibilities, instead of giving all employees three jobs to do. Depending on the specific needs of your organization you might need to make changes to or establish new culture and governance. For example, if you're entering a new trading business or market, you may need to increase risk tolerance and/or improve risk control.

• Process

  The processes must be deliberately designed and not simply adapted or continued. For example, you don't want to automate processes before they're optimized. One of our directors likes to say, “don't automate broken stuff.”

• CTRM ecosystem

  The data management and data architecture are very important, and we think that you need to get ahead of this. It should be a primary objective of projects to be very proactive and strategic about data architecture to support associated reporting and analytics. Otherwise, you'll spend a lot more money down the road fixing your data structure.

• Cloud

  Cloud enablement has really changed this industry in important ways not seen for several decades. The last change this significant was when Windows replaced Unix as the predominant trading platform back in the 1990s (yes, there was something before Windows).

The Value Curve

The Value Curve is a tool we created at Veritas to help clients visualize the project journey and what the path to success looks like. It also informs us of common mistakes that can occur. We’ve shared the Value Curve in previous blogs, but I will break it down for you again.

The point to the upper right (aka the North Star) is what you are aspiring to on your project. That's the additional value that you want the project to add. The middle of the project dips down very low. You’re not adding business value at this time. You're actually investing, which decreases business value, during a large portion of the project. You're incurring pain. We think it's very important that you be realistic about this part of the project. Everyone recognizes that projects have speed bumps, but more realistically there is a prolonged period of investment and difficult demands on the organization.

Pitfalls to avoid

There are pitfalls which are circled on the right side of the chart. If you're not realistic about the investment and difficulty and challenges, you fall into what we call the abyss. These are projects that are canceled before any business value could be added. You also have projects that overrun their schedules and budgets. A well-run project must balance time, budget, and quality. It’s very important that communication about this balance be clear and transparent, because it's usually misunderstandings that cause project cancellations due to one of those dimensions running out of control. Finally, projects may not be successful, even if they go live and create some value because they haven't come close to their ambition, the North Star that I referred to earlier. We call these suboptimal results.

This is what we have learned through our experiences and watching other projects. Hopefully, the Value Curve is a helpful illustration of a successful project journey, as well as some obstacles to avoid.

Critical success factors

Now that we have looked at some common pitfalls, let’s look at how to ensure a project is successful and what those critical success factors may be. A key (but counterintuitive) point is that the more ambitious your project is, the more successful it's likely to be. We can't achieve everything, but we should have big audacious goals on CTRM projects.

Let’s contrast ideal and higher risk approaches to project objectives, as well as several other critical success factors:

• Project objectives

  It’s ideal for the project to enable some very important business capabilities like entering a new market that’s very opportunistic for the firm or monetizing a large asset. Projects that are driven by technology objectives, for example, upgrading a version which is being decommissioned, are usually not as compelling to the organization and so are riskier projects.

• Business participation

  In an ideal situation, star performers are seconded onto the full-time project team and are promoted to important roles in the organization after the project’s completion. Projects which are viewed as undesirable assignments are riskier.  Somewhere in between (with moderate risk) are projects which have part time participants or use “proxies” as business representatives.

• Planning

  Ideally, you need stakeholder alignment and adequate resources devoted to planning. In contrast, projects are riskier that skip planning or have a single, strong-willed stakeholder that doesn't appreciate the need for alignment. It’s unusual for the organization to adopt the new processes and other changes delivered by such projects, and they tend to revert to the ways they were doing things before.

• Execution

  Embedded change management is more successful than a separate work stream that is dedicated to change management.

• Post Go-Live

  It is important to have a champion group that continues to pursue the objectives of the project. Going live is the beginning, not the end, of value realization.

Set ambitions high from the start

In our experience, CTRM projects without sufficient ambition experience a vicious cycle. CTRM projects fail 50% of the time. Projects are de-risked not only by active business participation, but also by ambitious business objectives. Improved trading capabilities and risk management/control capabilities are needed to ensure you maximize value out of a CTRM system. Some examples include:

Improved trading capabilities

• • Consistent valuation of complex structured deals or options
  • Near-real-time positions and economics
  • Complex optimization (e.g. multiple plants or storage assets)
  • Robust economic analysis (e.g. detailed P&L and attribution)
  • Performance measurement (e.g. advanced book structure, risk-adjusted performance)

Improved risk management / control capabilities

• • Integrated position and risk analytics (e.g. same risk factors in basis position and VaR reports)
  • Robust risk and scenario modeling (e.g. multiple models well integrated with extreme scenarios)
  • Integrated credit analytics (e.g. CVaR or PFE)

Summary

Organizations naturally resist change.  In order to be successful, CTRM projects must have ambitious business goals that are compelling to the organization.  You should expect massive value from these projects.

They should be led by the business and enjoy key stakeholder involvement.  Our integrated approach, which marries commercial strategy with the enabling people, process, and technology, can set you up for success. It’s also important to be realistic about the path to success, since there will be pain along the way, and to understand common pitfalls and critical success factors.

To download A Front/Middle Office Perspective on CTRM Implementations on-demand presentation, click the button below. 

At Veritas Total Solutions, our team of experts is versed in CTRM Systems and Trading & Risk Advisory capabilities. We offer advisory services in commercial strategy, organizational structure and capabilities, and technology solutions. We believe our integrated approach and domain expertise makes us uniquely positioned to help clients through a successful CTRM implementation, contact us or subscribe to our blog to stay connected.