Transformation Delivery for Financial Services
A Practitioner's Course
Session Six
Framework and Methodology
Why methodology debates distract from the real question, and how to choose a delivery approach that fits the shape of the work rather than an organisation's declared identity
|
Disclaimer This course is provided for general information and education only. It is not legal advice. Legislation, rules and regulatory guidance change, sometimes quickly. Readers should confirm the current position and obtain jurisdiction-specific professional advice where needed. The views and experience expressed are Russel Fielding's own and do not represent any employer or client organisation. |
Session Six: Framework and Methodology
Delivery leads can become surprisingly evangelistic about frameworks. Some are committed to agile, others to waterfall, and the conversation is too often conducted as a matter of identity rather than judgement. That mindset misses one of the most basic lessons in project delivery: every project is different, and the delivery model should fit the problem, not the other way round.
Why the debate misses the point
From a delivery-in-a-regulated-organisation perspective, it does not much matter whether a team labels its approach agile, waterfall, hybrid, or anything else. What matters is whether the project delivers the full scope needed to meet the obligation by the required date. Regulators do not award partial credit for good sprint ceremonies, and they do not relax a deadline because a programme was still iterating. In many compliance-driven programmes, half a solution is not a solution at all.
Agile brings real strengths: speed of feedback, visibility of progress, and the ability to adapt as requirements evolve. Waterfall brings real strengths too: structured planning, traceability, governance, and clear control points. In practice, compliance programmes often need both: enough structure to manage audit evidence, design sign-off, testing, and implementation readiness, and enough flexibility to respond when requirements are clarified or dependencies shift.
Three shapes of work
Most projects in a regulated organisation fall into one of three shapes. These are descriptions of the work, not branded methodologies, and each genuinely suits a different delivery approach.
Regulatory change with no significant technology component
New conduct rules, an AML programme uplift, or a change to a disclosure obligation. The scope is largely set by the regulation, the implementation timetable is externally constrained, and there is usually limited uncertainty about the minimum compliant outcome required. The uncertainty is mainly in how to operationalise it across systems, controls, people, and evidence. This shape often suits a predominantly waterfall approach, not from a lack of ambition but as a response to the constraints: you cannot iterate your way past a fixed regulatory deadline.
Technology change with no regulatory driver
A new internal platform, a customer-facing app, or a migration to a new core system. There is genuine uncertainty about what the right answer looks like, requirements will evolve as the build progresses, and the team learns from real use. This shape suits a predominantly agile approach, because iterative delivery is a practical response to genuine uncertainty, not a matter of fashion.
Regulatory change delivered through technology
A new reporting infrastructure to meet a regulator's data expectations, a new screening system for financial crime controls, or a capability to support new customer rights. The regulatory obligation and implementation timetable are externally constrained; the technology required is novel, complex, or both. This shape is genuinely hybrid: the regulatory commitments sit inside a waterfall envelope of fixed scope, constrained timing, and defined deliverables, while the technology inside that envelope is built iteratively. The hybrid needs to be designed deliberately. If it is allowed to emerge by default, it tends to combine the worst of both approaches rather than the best.
The conversation at the start of a project
None of this means an organisation should not have an overall delivery framework. It should: the framework provides governance structure, the artefacts that make change auditable, and the language that lets a board understand what is being delivered. A regulated organisation without a coherent framework is harder to govern, not freer to deliver.
What the framework should also provide is room to choose a route through it. That choice should be made at the start of each project against the actual shape of the work. The questions are simple and not framework-specific: which constraints cannot move, where does the genuine uncertainty sit, and what route through the organisation's framework fits this work. That conversation needs to happen with the people who will deliver the work, the people who will assure it, and the people accountable for it, before the route is set rather than after.
What good looks like for compliance-led work
Where a project is delivered against a regulatory obligation, strong delivery usually means a pragmatic approach. Lock down the non-negotiables early: the regulatory interpretation, the minimum compliant outcome, the evidence needed for sign-off, and the decision points that cannot be missed. Then use iterative delivery where it genuinely helps: refining requirements, testing options, exposing risks sooner, and improving handovers across teams. The result is flexibility in execution combined with discipline about outcomes, which is generally more useful than forcing an entire programme into one ideological model.
Why this is hard in practice
If the point is straightforward, the cycle of framework reinvention keeps repeating for identifiable reasons. Frameworks become part of organisational identity. A firm that has spent significant time and budget declaring itself agile does not easily accept that a particular project should run predominantly waterfall, and the reverse is equally true. The senior leaders who commissioned the last transformation are often still in the building, and reviewing whether the framework fits means reviewing whether their decision still holds. That is an easier conversation to avoid than to have. The question "are we agile yet?" is also easier to ask than "does our approach fit this work?" The first has a simple answer. The second requires judgement, and judgement requires someone willing to be held to it. Experienced project managers who can see the mismatch most clearly are too often asked to make the work fit the model instead of the reverse.
|
Key takeaways from Session Six
|
Coming up in Session Seven
Session Seven covers reporting and transparency: why status reports are structurally incapable of carrying the signals that predict programme drift, and what sponsors and programme managers can do to close the gap. Continue to Session Seven.
Further reading and resources
Every project is different. The framework should know that. This Ārai Tika resource sets out the three-shapes framework used in this session and gives a fuller worked treatment.
Regulatory Change Delivery in Financial Services. This Ārai Tika guide addresses planning and execution discipline for fixed-scope, fixed-date regulatory programmes.
Ārai Tika