Why Modular TMS Rollouts Deliver More Than Big-Bang Deployments

Executive Summary

Across treasury technology projects, the dominant implementation model is the big-bang go-live. Every module configured, every integration tested, every workflow signed off, all delivered in a single milestone six, twelve, or eighteen months after the contract is signed. Until that day arrives, the team continues running the processes the new system was bought to replace.

This model is so familiar it is rarely questioned. It deserves to be. A six-month implementation where nothing is delivered until month six is a worse purchase than a six-month implementation where the cash positioning module is live in week four, the bank reconciliation in week eight, the forecasting in week twelve. The total elapsed time may be the same. The value captured is not.

This paper makes the case for phased, modular TMS implementation: a delivery methodology in which each module is sequenced, scoped, and accountable to its own outcome metric, and in which value begins accruing well before the formal go-live date. The argument is not that big-bang is always wrong. It is that big-bang has been the default for reasons that have little to do with what serves the client, and that the alternative is more rigorous, less risky, and faster to value.

The Big-Bang Default and Why It Persists

The big-bang implementation model survives in treasury technology because it serves the structures around the project, not the people inside it. Vendors prefer it because revenue recognition and resource planning are easier to manage against a single milestone than a series of smaller ones. Procurement prefers it because the contract has a clean delivery date. Project sponsors prefer it because the executive sponsor wants one go-live to celebrate, not five.

None of these are bad reasons. They are simply not reasons that have anything to do with capturing value from the system. The structures that surround a TMS project pull toward big-bang because big-bang is administratively simple. The structures that determine whether the project succeeds – the team that has to use the system, the data that has to flow through it, the decisions that have to rely on its outputs – pull in the opposite direction.

A big-bang implementation also creates a single, large, late opportunity for things to go wrong. Issues that would be visible and fixable in the early weeks of a phased rollout instead surface in the final weeks of testing, when the timeline is fixed, the budget is committed, and the only way through is workarounds and deferrals. The pre-signature scope problem becomes a post-signature crisis under the big-bang model precisely because every dependency lands at the same time.

There is no structural argument for big-bang that survives close examination. It persists because nothing has tested it.

What Day-One Value Actually Means

A phased implementation does not mean a slower implementation, it means a sequenced one. The total elapsed time can be the same but the shape of the value curve is different.

Under a big-bang model, the value curve is flat for the duration of the project and rises sharply, in theory, at go-live. In practice, it rises gradually after go-live as adoption catches up, integrations stabilise, and configuration is corrected. The area under that curve is what the client actually pays for, and it is consistently smaller than the area under the curve of a phased rollout, even when the formal end dates are identical.

Under a phased model, the cash positioning module goes live in a given week. From that point onward, the team has a single source of truth for daily cash, and the spreadsheets that previously did this work are retired immediately rather than in twelve months. The bank reconciliation module goes live a few weeks after. From that point, automated reconciliation is delivering value daily. In the following weeks the forecasting module goes live. By the formal end of the implementation, the team has been operating with the system for months, has caught configuration errors while they were small, and has built the trust that big-bang implementations spend their first post-go-live year trying to manufacture.

Which Modules First, and Why

Not every module is suitable for early delivery. The discipline of phased implementation lies in sequencing modules in the order that captures value fastest while building the foundations the later modules depend on.

The first deliverable is static data. Entities, bank accounts, counterparties, currencies, calendar conventions, instrument definitions. It is rarely treated as a module, but every subsequent module depends on it. Static data configured incompletely or inaccurately does not just slow later work down, it produces incorrect outputs. Getting it right before any other configuration begins is the single most important decision in a phased rollout.

Bank connectivity follows. Without reliable bank feeds, every downstream module is theoretical. The integration work for the principal banking relationships should be completed and tested before cash management is configured. Doing this properly under a phased model is significantly easier than under a big-bang one, because the only thing depending on the bank data at this point is the bank data itself, not three other modules waiting on the same milestone.

Cash management follows, sequenced internally rather than delivered as a single block. Cash visibility comes first, the team can see consolidated bank balances and movements from the system, with confidence in the underlying feed. Reconciliation comes next, removing the manual work that consumes the most analyst time and recovering the cost of the implementation fastest. Positioning and forecasting follow together, building on reconciled balances to produce the analytical layer the function uses for daily decisions.

Reporting is not a separate module. It is part of each delivery. The reconciliation module ships with its reconciliation reports; the positioning module with its position reports; the forecasting module with its forecasts. Treating reporting as a standalone phase, configured at the end across all modules at once, is one of the structural reasons reporting is so often the weakest part of a finished TMS.

The remaining modules sequence after cash management, in an order determined by where the team’s pain is greatest. A treasury function with a significant debt portfolio prioritises getting this tracked in the system. A function with complex group structures prioritises intercompany positioning. The principle is the same: sequence by where the system’s value is most demonstrable.

The Outcome Metric Per Module

The discipline that makes phased implementation work, and without which it collapses into a slower big-bang, is the outcome metric per module.

Each module has a defined success criterion agreed before the module begins. The cash positioning module is not live because the software is running. It is live when the daily cash position is produced from the system without spreadsheet supplementation, accepted by the treasury manager, and reconciled to the bank within an agreed tolerance. The bank reconciliation module is live when an agreed percentage of transactions reconcile automatically. The forecasting module is live when the forecast is produced, distributed, and used to inform decisions without parallel models being maintained outside the system.

These metrics are agreed in writing, with both vendor and client signature, before the module is configured. They sit alongside the contractual delivery dates. They are the basis on which the module is signed off.

This converts a delivery methodology into a governance methodology. Each module is not just shipped but is accountable. Each module is not just live but is providing value. The vendor and the client share a definition of live that goes beyond software functioning correctly to include the operational outcome that justified the purchase.

The discipline is demanding. It requires both parties to define success in advance, with measurable criteria, before there is any pressure to declare success. It is also the only thing that prevents a phased implementation from becoming a series of false go-lives, each one a slightly smaller version of the big-bang failure pattern.

Governance for a Phased Programme

A phased implementation requires governance that the big-bang model does not. Four elements are essential.

A module-by-module success criterion. Each module has its outcome metric agreed before configuration begins, with baseline measurement of the existing process and target measurement for the new one.

A module sign-off process. At the end of each module, a structured review confirms whether the outcome metric has been met. If it has, the module is signed off and the next module begins. If it has not, the issues are identified, addressed, and re-tested. The next module does not begin until the previous one is genuinely complete.

A named internal owner with continuity across modules. The same individual owns the system across all modules of the rollout. This is the person who carries the institutional understanding of why each configuration choice was made, what each module is supposed to deliver, and how the modules connect. A phased rollout without continuity of ownership is a series of disconnected projects.

A formal end-of-programme review. After the final module is delivered, a structured review evaluates the programme against the outcome metrics agreed at the start of each module. This is the moment at which the implementation is formally complete – not when the software stopped being configured, but when the operational outcomes were demonstrably delivered.

Capture Value, Don’t Defer It

The big-bang implementation model has been the default in treasury technology for reasons that have nothing to do with what serves treasury teams. It serves project administration. It serves vendor revenue recognition. It serves executive timelines. It does not serve the analyst who has to wait twelve months to retire the spreadsheet, the treasury manager who cannot trust the new system because nothing has been tested in production until the very end, or the organisation that has paid for transformation and received it on a schedule that defers value to the latest possible moment.

A phased, modular implementation captures value earlier, exposes problems sooner, builds trust gradually, and produces an outcome that the team can defend. It is more rigorous, not less. More demanding to govern, not easier. But in the end, more likely to deliver what the system was bought to deliver.

The case for phased implementation is not that big-bang is impossible. It is that big-bang has been the default for too long, for the wrong reasons, and treasury teams have paid the cost of that default in deferred value, late-surfacing problems, and post-go-live drift. The technology is ready but the methodology has lagged. Treasury programmes that adopt phased implementation, with outcome metrics per module, will find their TMS delivers from the first quarter rather than the second year.