Drawing on more than 25 years in investment operations and program delivery, Bryan Kelly explains why sustainable Treasury transformation requires more than successful system implementation.
By Bryan Kelly
Bryan Kelly is a Senior Program Advisor at Prodktr with more than 25 years of experience in investment operations, Target Operating Model design and complex implementation delivery across Europe, Australia and the United States. Before joining Prodktr, he was Group COO at Alvar Financial and held senior middle-office and implementation leadership roles at SS&C GlobeOp and Northern Trust. His experience spans operating-model transformation, platform integration, front-office-to-accounting integration, program governance, vendor management and the transition of new services into business as usual. He currently supports the governance and delivery of a strategic transformation program for a multilateral development bank.
1. Go-live is not the outcome
A Treasury platform can go live on schedule and still fall short of what the institution needs. Interfaces may remain fragile. Controls may sit outside the system. Operating teams may still depend on project specialists, and material decisions and exceptions may have no settled owner. The technology has been delivered. The service has not.
I have seen that distinction repeatedly. The strongest programs do not treat go-live as the finish line; they define the future service early and use implementation to make it real. This matters particularly in Treasury, because the platform sits across trading, risk, operations, finance and accounting. Delivery must be judged by whether the institution can run that chain safely and accountably.
“Go-live is a milestone, not the outcome. The real test is whether the institution can operate the service confidently after the project team steps away”
2. Let the Target Operating Model guide delivery
Implementation should begin with a practical view of the Target Operating Model, not an organisation chart. It should set out who owns each activity, where decisions sit, which controls are required, what information each team needs and how exceptions will be managed.
Without that reference point, configuration workshops become a series of local decisions. Each may look reasonable alone, but together they can rebuild the fragmentation the program was meant to remove. Teams protect familiar processes, providers default to standard product behaviour, and gaps drift into spreadsheets.
A defined operating model also gives the program a basis for challenge. Any proposed design can be tested against the service the institution intends to run: does it simplify the process, preserve the required control and support clear ownership? The same test applies to requirements. Some reproduce legacy practice or drive avoidable customisation; others protect a genuine business, control or institutional need. Much of assurance is the discipline of telling the two apart.
A platform is only one part of the operating capability
A platform is only one part of the operating capability
3. Keep the institution in control
A software provider or systems integrator brings product knowledge, delivery methodology and specialist capacity. What it cannot bring is ownership of the institution’s operating outcome. Priorities, requirements, design decisions, risk acceptance and operational readiness stay with the client, which needs enough operational and technical depth to test what is being told.
“A technology provider can deliver a platform, but it cannot own the institution’s operating outcome.”
Governance is the mechanism for holding that position, and it works only when it is organised around decisions rather than a calendar of meetings and status packs. Every material design issue needs an owner, a decision date, real options and a statement of the operational consequence. Status needs a shared evidence base: plan achievement alongside the quality of completed work, open decisions, test evidence and integration readiness. A program can be green against dates and still carry real delivery risk underneath.
Integration deserves the same treatment. Treasury delivery is end-to-end, so interfaces, data flows, accounting outcomes, reconciliations and exception handling belong to the operating model rather than to a detached technical workstream. The real question is what the institution does when data arrives late, a posting fails or a valuation differs. Testing should follow real transactions through the whole chain.
4. Build operational readiness before go-live
Readiness cannot begin in the final weeks before go-live. By then procedures and support arrangements are effectively fixed, and unresolved issues become workarounds that quietly become permanent. Readiness must develop alongside design and configuration: future process owners taking part in decisions, procedures reflecting the configured solution, training built on realistic scenarios, and support teams that understand exceptions as well as routine processing.
That also changes the character of handover. If the BAU teams meet the service for the first time at cutover, the program has transferred a system and retained the knowledge. A sustainable transition leaves the institution with knowledge, capacity, authority and support arrangements it can rely on, with open defects and workarounds visible, owned and linked to a realistic remediation plan.
Technology delivery and operational readiness progressing to a sustainable service
Technology delivery and operational readiness progressing to a sustainable service
Time, cost and scope remain necessary measures, but they describe the project rather than the service. A sustainable delivery leaves clearer ownership, stronger controls, simpler workflows, workable support and a platform that can adapt without another major program. Much of that only becomes visible once the pressure of go-live has passed.
“Client satisfaction is a barometer of success.”
That is a practical measure rather than a soft one. Satisfaction reflects whether the people who inherit the service can operate it with confidence and improve it. Successful delivery is not the transfer of a system from a vendor to a client. It is the creation of an operating capability the institution understands, owns and can sustain.
5. How Prodktr supports sustainable delivery
Prodktr supports multilateral development banks and financial institutions through operating model advisory, project assurance and business assurance for complex Treasury and financial-platform transformations.
We work client-side across Target Operating Model design, requirements and solution challenge, vendor oversight, testing and integration assurance, and operational readiness, helping institutions stay in control of delivery and build sustainable capabilities beyond implementation.
Contact us for more information.