When Go-Live Is Binary, Why Are We Pretending to Sprint?

When Go-Live Is Binary, Why Are We Pretending to Sprint?

Why Treasury Management System implementations don't fit the methodology you picked

Walk into any Treasury Management System implementation today and you will hear the language of agile. Sprints. Stand-ups. Sprint reviews. Backlogs. Story points. Velocity.

You will also, if you look closely, see a fundamentally waterfall programme operating quietly underneath. Go-live dates. Cutover plans. Parallel runs. Bank onboarding sequences. Test entry criteria. Period-end constraints.

The two coexist uneasily. The ceremonies happen on top. The actual work runs on its own logic underneath. And the gap between them is where programmes lose time, money, and credibility.

This is not an argument against agile. It is an argument that the methodology was never the problem, and was also never the answer.

Let's Give Methodologies Their Credit

Most of the major project methodologies work, in the context they were designed for. Agile and Scrum came from small, co-located software teams building products for users they could see and feedback loops they could run quickly. Lean came from Toyota, physical manufacturing, deep engineering culture, decades of cultural foundation. Six Sigma came from high-volume manufacturing where defects are countable and variance is the enemy. Waterfall came from contexts where requirements were genuinely stable and the cost of change was high. PRINCE2 came from UK government IT contracting. SAFe came from the question of how to apply agile principles at programme scale.

Each of them works reasonably well when applied to roughly the problem it was invented to solve.

The failure is usually not the methodology. It is the export. When the method does not fit the work, the ceremony survives and the substance quietly disappears.

Why Agile Doesn't Fit, Despite Being the Fashionable Answer

You cannot release "thirty percent of cash positioning" to production. You cannot ship a payment file and iterate later. You cannot let users discover at month-end that the SWIFT message format is half-built.

A TMS go-live is binary. Cash visibility is either there or it is not. Payment files either reconcile or they don't. Period-end accounting either runs cleanly or finance has a problem.

The external timelines do not bend to your sprint cadence either. SWIFT BIC issuance takes what it takes. Bank onboarding queues run on eight to twelve week external clocks that do not compress because you have adopted a two-week iteration. Bank test environments cycle on their own schedules. A bank's internal project queue is not yours to manage.

There is also no real product owner in the sense agile imagined. Treasury is the customer, but the product is configured within a vendor's pre-built framework. You are not designing from a blank page. You are bending policy to vendor capability and vendor capability to policy, and a great deal of the value is in that bending.

Apply enterprise agile to a TMS implementation and you tend to end up with sprint ceremonies running parallel to a fundamentally waterfall delivery, with the cost of both and the benefit of neither.

Why Pure Waterfall Doesn't Fit Either

If agile is the fashionable wrong answer, pure waterfall is the comfortable wrong answer.

The high-level scope is known. Cash. Deals. Accounting. Payments. Connectivity. Reporting. You can map it. You can sequence it. You can put it on a Gantt chart and have it signed off.

But the discovery during configuration is enormous, and that is what waterfall has nowhere to put.

Vendor quirks emerge mid-configuration. Edge cases in bank file formats only appear once you start sending real test files. Treasury policy gaps reveal themselves only when you try to configure them, because the policy was written for a world without this system, and the system is built for a world where policy is consistent. Reporting requirements are often not fully understood by the business until they see the first draft and discover what is missing.

A pure waterfall programme treats this as scope creep. A well-designed delivery treats it as the work.

Six Sigma, SAFe, Lean

The other branded methodologies fit even less.

Six Sigma is steady-state process optimisation. It works on repeatable processes producing measurable defects. A one-time system implementation is not its problem space. Tools from Six Sigma can be useful inside a TMS programme — process mapping, root cause analysis on testing defects — but adopting it as the programme methodology imports overhead with no proportionate benefit.

SAFe is overhead in search of a problem at this scale. A TMS implementation is fundamentally one programme with adjacent integrations. The scaling apparatus of SAFe — Agile Release Trains, Program Increments, Communities of Practice is designed for organisations running dozens of agile teams in parallel. Apply it to a single TMS programme and you spend more time in scaling ceremonies than configuring the system.

Lean has useful instincts. Reduce waste. Respect the people doing the work. Go and see for yourself. But there is no Lean implementation framework that fits this kind of work. The cultural insights are valuable. The toolkit is not.

A Familiar Pattern

I have watched a version of this play out more than once.

A transformation function adopts a methodology, usually agile, sometimes SAFe, because it is what good organisations are seen to do. The treasury programme is brought into that operating model because consistency matters. Sprints get scheduled. Stand-ups get added to the diary. A backlog gets created in the chosen tool. Status reporting gets aligned to the agile vocabulary.

And underneath, the actual work continues to operate on bank timelines, vendor release cycles, period-end constraints, and a hard go-live date. The team starts running two delivery models in parallel. The one they say they are running, and the one they are actually running. Status reporting reflects the first. Risk reflects the second.

When something slips, the methodology gets blamed, or the team. Rarely the choice to apply that methodology to this kind of work.

What Actually Works

The honest answer is that no branded methodology, applied as designed, fits a TMS implementation cleanly. The work needs a hybrid, and that hybrid has a recognizable shape.

A stage-gated backbone, because the work is. Initiate. Design. Configure. Integrate. Test. Parallel. Cutover. With real gates at the points where binary decisions matter, design sign-off, configuration freeze, UAT entry, bank connectivity ready, parallel run start, cutover go/no-go. Real gates, not ceremonial ones. Gates that should genuinely stop the programme if conditions are not met.

Iterative configuration cycles inside each stage, because that is where the discovery happens. Configure a deal type. Test it. Fix it. Retest. Configure a payment file. Validate it end-to-end with the bank. Fix it. Revalidate. The cycle is real and the cadence is helpful. Two-week iterations are fine. Just call them what they are.

Vendor-led methodology as the starting point. Every major TMS vendor has an implementation methodology built around their product. Start there. Adapt it to your governance reality. Do not reinvent it. The vendor has seen more implementations than you have, and their methodology encodes the lessons of the ones that went wrong.

Parallel running over big bang. Run the new system alongside the old for at least one or two month-ends before cutover. Reconcile daily. The cost of parallel running is much smaller than the cost of a failed cutover, and almost everyone underestimates that until they have lived through one.

A light governance overlay. Closer to PRINCE2 in structure than to anything else, but stripped down. Clear stage gates. RACI from day one across treasury, finance, IT, security, vendor, and banks. A working decision log that is actually used. Decision rights matter more here than ceremony.

That shape works. It does not have a brand name. Practitioners just call it sensible delivery.

The Five Things That Matter More Than Methodology

The harder truth is that the methodology choice matters less than five other things, and any experienced TMS implementer will tell you the same.

A treasury subject matter expert with real configuration experience on the platform being implemented. Not someone who has read the manual. Someone who has been through the cycle before and knows where the system bends and where it breaks.

A vendor implementation partner that has worked with your specific bank stack before. The generic implementation team will be fine for cash and deals. They will not know what to do when a particular bank's test environment behaves inconsistently. Specificity matters.

Decision authority sitting with someone who understands the operational implications. Not a sponsor who signs off whatever is in front of them. Someone who can read a design choice and feel its downstream consequence in finance, treasury operations, regulatory reporting or internal audit.

Ruthless v1 versus v2 scope discipline. Everyone tries to do too much in v1. Every time. The disciplined programme decides early what is essential for go-live and what can wait three months. The undisciplined programme decides during testing, which is the most expensive moment to scope-cut.

Bank onboarding started as early as humanly possible. Earlier than feels reasonable. Earlier than the plan suggests. The banks set the calendar, not you, and the cost of starting too late is always higher than the cost of starting too early.

Get those five right and almost any sensible delivery shape will work. Get those five wrong and no methodology will save it.

The Bottom Line

The methodology question is rarely the real question. The methodology gets chosen for cultural reasons, to look modern, to look controlled, to align with whatever the broader transformation function has standardized on. The work is then forced into that shape, and the gap between the shape and the substance becomes the cost of the programme.

The organizations that deliver TMS implementations well are not the ones with the most fashionable methodology. They are the ones that hire the right people, give them real decision authority, start bank onboarding early, ruthlessly defend v1 scope, and trust the vendor methodology as a starting point.

The framework on the slide rarely matches the work on the ground. Treasury is one of the few functions honest enough to admit this, because at cutover, the cash either moves or it doesn't, and the methodology has no opinion on that.

So maybe the question worth asking before the next TMS programme starts is not which methodology to adopt.

Maybe it is this:

Of the people who will deliver this programme, how many have actually delivered one before?