How to Rescue a Failing TMS Implementation

Most treasury management system implementations that come to us for rescue arrive at a similar point. The programme is three to six months in. The original go-live date has passed or is about to be missed. UAT is revealing problems that should have been caught in configuration. The bank connectivity timeline has extended again. The internal team is exhausted, the vendor is defensive, and the senior stakeholder who originally championed the programme is asking increasingly direct questions. This is a recognisable situation. It is also a recoverable one — if the right resource is brought in quickly enough.

Signs the Programme is in Serious Trouble

Not every delay is a crisis. Programmes slip for controllable reasons — a key person is unavailable, a bank takes longer than expected, a configuration decision needs revisiting. The warning signs that a programme has moved from delay into genuine distress are different.

UAT defect volumes are high and not reducing. Defects from one test cycle are reappearing in the next. The implementation team is spending more time in issue triage than in resolution. Bank connectivity testing is repeatedly rescheduled. Key integration points — between the TMS and the ERP, or between the TMS and the payment infrastructure — are still not stable. The project plan has been revised more than twice and the revised dates are no longer credible. Senior sponsors are being told the programme is on track when it is not.

Any one of these individually might be manageable. Several together, or a pattern that has been running for more than four weeks, indicates the programme needs external intervention.

Common Root Causes

The surface presentation of a troubled TMS implementation — UAT failures, integration problems, missed milestones — is rarely the actual root cause. The root causes are usually one or more of the following.

Under-experienced implementation resource. The consultants on the programme don't have deep enough knowledge of the system to configure it correctly first time or to diagnose configuration-related defects efficiently during testing. This is the most common cause of implementation failure and the hardest to acknowledge mid-programme.

Scope that was never properly defined. The configuration workbook is incomplete or ambiguous. Decisions that should have been made in the requirements phase are still being made in UAT. Each decision generates rework.

Bank connectivity that was underplanned. The number of bank relationships in scope, the variety of connectivity methods required, and the lead time for bank onboarding were not accurately assessed at the start. The bank connectivity plan is now the critical path and it is not moving fast enough.

Governance that is not functioning. Issues are being raised but not resolved because no one has the authority or the accountability to make the relevant decisions. The steering committee is receiving sanitised status reports. The programme manager does not have the authority to escalate effectively.

What a Rescue Engagement Looks Like

The first step in a rescue engagement is diagnosis — understanding what has actually gone wrong before committing to a remediation plan. This typically takes one to two weeks and involves reviewing the current configuration state, the UAT defect log, the bank connectivity status, the integration test results, and the outstanding decisions log. The output is an honest assessment: what is fixable, what is not, what the realistic go-live date looks like, and what resource is required.

From there, the rescue programme has two phases. Stabilisation — resolving the highest-priority defects, completing the bank connectivity work, and closing the outstanding integration issues that are blocking UAT sign-off. And cutover — managing the transition to go-live with a level of rigour and senior oversight that was likely absent in the original plan.

The length of a rescue engagement depends on how far the programme has drifted and what the root causes are. For programmes where the core configuration is sound but execution has been poor, four to eight weeks is often sufficient to stabilise and complete. For programmes where the configuration itself needs significant rework, the timeline is longer and the honest conversation with the business about revised expectations is unavoidable.

When to Call It

Not every troubled TMS implementation should be rescued. In some cases — where the configuration is fundamentally wrong, where the vendor relationship has broken down, or where the business requirements have changed materially since the programme started — the most commercially rational decision is to stop, regroup, and restart with better planning and better resource.

This is a difficult conversation to have, but it is a cheaper one than continuing a programme that cannot succeed in its current form. External resource that has no stake in the existing programme can give an objective assessment of whether rescue or restart is the right path.

Talk to RG Treasury

RG Treasury provides project rescue resource for TMS programmes in difficulty. Our consultants are available at short notice and have the implementation depth to diagnose root causes quickly and drive resolution. Contact Sales@rgtreasury.com to discuss your situation.