Beyond the Demo

How to Prepare the Ground for TMS Success

Christof Nelischer and Dean Ibbs share more than a decade of working on TMS selection, implementation, and optimisation projects from different perspectives: treasurer and vendor respectively. Since their first collaboration 10 years ago, they have continued to compare notes on the recurring challenges companies face when evaluating, selecting, and executing treasury technology

While the first article in this series explored why TMS selection is fundamentally an organisational, rather than technological, challenge, the second examines what happens once the selection process ends and implementation begins.

Poor TMS projects rarely fail because the software is incapable. More often, the foundations are laid during selection. Objectives are unclear, requirements become bloated, stakeholders pull in different directions, and implementation effort is underestimated. By the time a vendor has been chosen, the organisation may already have created conditions that make success difficult.

Selecting a TMS is largely about making decisions. Implementation is about turning those decisions into an operating reality. The emphasis shifts from evaluating software to defining processes, preparing data, integrating systems, managing organisational change, and delivering business outcomes. It is here that many organisations discover the difference between software capability and implementation complexity.

During vendor selection, organisations naturally compare features, demonstrations, and commercial proposals. During implementation, success is measured very differently. The quality of decisions, the discipline of project governance, the availability of accurate data, and the willingness of the organisation to adapt its processes become far more important than any individual software feature.

Reflecting on his multiple TMS implementations from the client side, Nelischer notes:

“By the time you’re selecting a second or third TMS, you realise that the software itself is only one part of the decision. The quality of the implementation partner and the organisation’s willingness to adapt its processes often have a bigger impact on the eventual outcome.”

The reality is that the activities that determine project outcomes are rarely the ones showcased during vendor demonstrations.

What the demonstrations don't show

During demonstrations, vendors showcase impressive capabilities. Workflows appear seamless, data is readily available, and complex treasury processes seem straightforward.

What is often missed is this: success is rarely determined by the software itself. It is determined by the implementation.

Demonstrations showcase software in an ideal state. What determines success is not whether the functionality exists, but how effectively it can be configured, integrated, and adopted within the organisation's environment.

This is why selecting the right implementation partner is often just as important as selecting the software itself. When comparing two broadly capable platforms, the quality of the implementation team, methodology, and treasury expertise can have a greater influence on the eventual outcome than the differences between the products themselves.

Viewing TMS implementations as business transformations rather than software deployments is central to Actualize's approach. As Ibbs explains: “At Actualize, we frame every TMS implementation through a transformation lens. While the software provides the foundation, our focus remains on the outcomes the organisation is trying to achieve. As priorities shift, challenges emerge, and new information comes to light, we continually reassess how best to deliver those outcomes. Successful implementations are rarely about executing a statement of work exactly as written. They are about helping organisations adapt as projects evolve without losing sight of what they set out to achieve.”

Every successful implementation begins by defining the future treasury operating model before configuring the software to support it. User roles, transaction types, workflows, controls, and master data structures all need to be carefully designed.

To those outside the project, it can feel like a lot of discussion and not much progress. In reality, this is the stage when getting it right matters most. Once a system has been configured and adopted, rebuilding core design decisions can be difficult, expensive, and disruptive.

Once the design phase is complete, attention turns to master data. Like an ERP, a TMS is only as effective as the information that sits behind it. Accuracy, completeness, and governance are critical.

Much like an ERP implementation, poor data quality has a habit of revealing itself at exactly the wrong moment.

The scale of the task is often underestimated. Bank accounts, legal entities, counterparties, users, signatories, and transaction data all need to be reviewed, validated, and maintained. Even after go-live, the work does not stop. Master data requires ongoing maintenance, periodic reviews, and clear ownership.

A TMS can indeed consolidate global liquidity daily, providing real-time visibility across the organisation's cash position. It is an obvious benefit to highlight during demonstrations and one that is intuitive to non-treasury stakeholders. Achieving it is another matter.

Every bank, jurisdiction, account, and legal entity needs to be brought into the solution. What appears on a demonstration screen as a single global cash position is often the result of months of connectivity work, testing, documentation, and co-ordination across multiple parties.

Typically, 70-80% of banks connect relatively quickly. The remaining 20-30% often take far longer, if they connect at all. The devil is in the detail: file formats, connectivity protocols, local banking practices and the administrative burden associated with each connection.

Vendors are not necessarily wrong when they cite aggressive timelines or reference successful projects with other clients. However, they are often describing their part of the process rather than the entire journey. Much of the design work, data preparation, validation, and organisational change has already been completed by the time the vendor's contribution begins to generate visible results.

The implementation reality

Every TMS implementation reaches a point where enthusiasm from the selection process collides with the reality of execution. Timelines slip, unforeseen complexity emerges, and stakeholders can begin to question whether the promised benefits will ever materialise.

As delays accumulate and the implementation falls behind schedule:

• Senior management becomes frustrated.
• Controllers begin to question the value.
• The Treasury implementation team feels the pressure.

The irony is that many of the challenges encountered during implementation are not implementation issues at all. They are the delayed consequences of decisions made during selection, whether unrealistic expectations, unclear requirements, or an underestimation of the effort required to achieve the desired outcome.

It is in the nature of a TMS implementation that it either works completely or it does not. Liquidity reporting provides a useful example. A global cash position may have been one of the most compelling demonstrations during vendor selection, but a liquidity report that is 95% complete is often of little practical use.

If a small number of banks remain unconnected, account structures are still being validated, or local entities have not completed testing, the promised visibility remains frustratingly out of reach. Treasury is still left managing exceptions manually and the benefits become fully visible only when the final pieces fall into place.

Stakeholders naturally ask why the organisation is not yet benefitting from the capabilities that impressed them during the selection process.

As pressure builds, functionality that appeared essential during vendor demonstrations often becomes ‘phase two’, ‘future enhancement’, or ‘post-go-live optimisation’. Sometimes this is sensible prioritisation. Sometimes it is simply the consequence of running out of time. Workarounds emerge, scope contracts, and the project gradually shifts from delivering the original vision to delivering what can realistically be achieved before go-live.

Nelischer has observed that the most successful organisations respond to this reality differently.

“The successful implementations were rarely the ones that followed the original plan perfectly. They were the ones where the organisation stayed focused on what it was trying to achieve and adapted as the project evolved.”

As timelines slip and pressure increases, senior managers naturally begin asking a reasonable question: can we accelerate the project by adding more people?

The reality is that TMS implementations are highly dependent on sequencing. Major implementation activities follow a natural sequence. The operating model needs to be agreed before configuration can begin. Configuration needs to be completed before testing can start. Testing needs to be completed before users can be trained. Additional resources can certainly help in some areas, but there are limits to how much a project can be accelerated.

Most TMS implementations ultimately deliver significant value. Yet many organisations never fully utilise all of the functionality they purchased. Features that seemed critical during selection are deferred indefinitely. Opportunities for automation remain unexplored. Benefits are realised, but often not to the extent originally envisioned.

Many organisations approach TMS implementations using the same governance frameworks and project methodologies they apply to large enterprise technology programmes. While these approaches can provide valuable structure, TMS projects often require a greater degree of flexibility.

Treasury processes evolve as organisations gain a deeper understanding of their requirements, data, controls, and operating model. Discoveries made during testing frequently influence design decisions, making rigid adherence to an original plan difficult.

This is why expectations matter as much as technology. Organisations that understand the effort required, remain committed to their objectives, and adapt to changing circumstances are far more likely to realise the full value of their investment.

Remain committed, adapt as reality intervenes

Successful implementation is the point at which the true value of a TMS becomes visible.

Implementation is where that value is either realised or compromised. Technology alone does not transform treasury. Success depends on the quality of the implementation, the strength of the implementation partner, the organisation's willingness to adapt its processes, and the discipline to remain focused on the intended business outcomes as the project evolves.

The most successful TMS implementations are not necessarily those with the shortest timelines or the largest budgets. They are the ones where the organisation remains committed to its strategic objectives and adapts pragmatically as reality inevitably intervenes.

A TMS may be discretionary on paper. In practice, it has become essential infrastructure for organisations seeking to manage liquidity, risk, and financial operations effectively.

Only through successful implementation does software become a TMS.