Why TMS implementations fail, and what to do before they do

Why do TMS implementations fail?

Most TMS implementations fail on ownership rather than technology. The vendor owns the software, treasury owns the process, IT owns the integration, and no single person owns the outcome. When a decision crosses two of those boundaries (accounting treatment, bank connectivity, the cut-over approach) it waits. Failures also cluster where requirements were written from a vendor’s feature list rather than from the treasury function’s actual processes, because the gap only becomes visible once real data arrives. The system is then blamed for a decision nobody made.

The pattern is consistent enough to be a diagnostic. If you can name the person who decides when treasury and IT disagree, and that person is not the vendor’s project manager, the programme is in better shape than most. If the answer is a steering committee that meets monthly, the programme has a decision latency problem that will surface as a schedule problem.

The second cluster is subtler. A requirements document assembled from a shortlist of vendor demonstrations describes the systems that were demonstrated. It does not describe what the treasury function does on a Tuesday when a subsidiary reports late. Implementations built on that kind of document tend to pass every scripted test and fail the first real month-end.

Who should own a TMS implementation?

Treasury should own a TMS implementation, with a named individual accountable for decisions rather than a committee. IT owns integration, security and infrastructure; the vendor owns configuration and product knowledge. The accountable owner needs enough authority to close a decision the same week it is raised, and enough treasury knowledge to know which decisions matter. Splitting ownership between treasury and IT is the most common arrangement and the most reliable source of delay, because the decisions that determine the configuration sit precisely on the boundary between them.

This is where independent advice earns its place. An independent implementation consultant is not a substitute for the owner. The owner has to be inside the organisation. What the consultant supplies is the ability to tell the owner which of the vendor’s statements are product facts and which are negotiating positions, and to recognise a decision that will be expensive to revisit before it is taken casually.

What should be agreed before the vendor starts?

Four things should be closed before the vendor’s clock starts: the accounting treatment for every instrument in scope, the source of record for each data domain, the bank connectivity approach including formats and testing windows, and the definition of done for go-live. All four are organisational decisions. None of them requires the software to exist. Leaving any of them open means the implementation begins by discovering them, at implementation rates, with the timeline already published to the board.

How do you tell early that an implementation is going wrong?

The earliest reliable signal is a decision log that is growing rather than shrinking. A healthy implementation closes more questions each fortnight than it opens; a failing one accumulates them under headings like “to be confirmed in UAT”. The second signal is testing written by the vendor and executed by the vendor. The third is a treasury team that has stopped attending workshops, which usually means the workshops stopped being about their process. None of these require a formal review to spot, and all three appear well before a milestone slips.

By the time a milestone visibly slips, the cost of correction has usually already been incurred. That is the argument for a review at design freeze rather than at the first missed date: it is the last point at which changing the plan is cheaper than absorbing it.

This sits inside our wider treasury technology practice, which covers the lifecycle from selection through to optimisation. If a programme is already in flight, who should own a TMS implementation goes further into the governance question, and what an implementation review actually examines describes what a structured look at a live programme covers. The work described here is led by Belinda Davis.