The delivery challenge
The transformation combined platform change, finance requirements, data preparation, testing, user readiness and production cutover. Each stream had its own subject-matter experts, deliverables and timing constraints, but the programme could only move when the dependencies lined up.
The main risk was not a lack of activity. It was that activity was happening in parallel without one sufficiently clear view of what had to be true before the next stage could start. Business teams also had normal operational responsibilities, creating recurring capacity constraints around testing, sign-off and period-close activity.
What had to change
The programme needed to shift from workstream-by-workstream status reporting to integrated delivery control. That meant making dependencies visible, separating technical completion from business readiness, and giving each rollout wave explicit entry and exit criteria.
The approach
1. Rebuild the plan around dependencies
Instead of treating configuration, data, finance validation, testing and training as separate schedules, they were connected into one dependency map. Each milestone showed what it depended on and what downstream activity it unlocked.
2. Introduce wave-based readiness
Countries and business units were grouped into manageable rollout waves. Readiness was assessed against evidence rather than a general red-amber-green status. A wave could only progress when required inputs, testing, business sign-off and production preparation were complete.
3. Protect business capacity
Testing and validation were aligned around periods when finance and operational teams could realistically participate. Where a dependency could not move, other work was re-sequenced rather than allowing the entire plan to drift.
4. Separate decisions from discussion
Open questions were converted into explicit decisions with owners and dates. This reduced recurring discussion and made it clear which unresolved items were genuinely affecting the critical path.
5. Keep executive reporting outcome-led
Executive updates focused on deadlines, readiness, material risks, decisions required and what had changed since the previous review. Operational detail stayed in the working-level governance rather than overwhelming senior stakeholders.
What the delivery model achieved
One integrated delivery view
Parallel workstreams were connected through explicit dependencies and common milestones.
Repeatable rollout waves
Readiness criteria created a consistent way to prepare, validate and release scope progressively.
Clearer business ownership
Validation, sign-off and data responsibilities became visible instead of being assumed.
Better executive control
Leadership could see what was actually threatening the target dates and where intervention was needed.
Why this matters
Large treasury transformations rarely fail because one configuration item is difficult. They become unstable when multiple dependencies are managed independently and business readiness is treated as a final-stage activity. The delivery model therefore has to connect technical progress with operational acceptance from the beginning.
What we would carry into a similar engagement
- Build the integrated dependency map before detailed scheduling.
- Use evidence-based readiness criteria for every rollout wave.
- Plan around real business capacity, not theoretical availability.
- Make unresolved decisions visible on the critical path.
- Keep senior governance concise and decision-oriented.