Every project is different. The framework should know that

Why do delivery leads get so evangelistic about frameworks? Some are full agile, others are full waterfall, and too often they talk as if methodology is a matter of identity rather than judgement.

That mindset misses one of the most basic lessons in project delivery. Every project is different. The delivery model should fit the problem, not the other way around.

From a compliance perspective, the debate can sound strangely detached from reality. I do not care 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 regulatory obligation by the required date.

Regulators do not award partial credit for good sprint ceremonies. 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.

That is why pure methodology thinking can become a distraction in regulated environments. Agile brings real strengths. Speed of feedback, visibility of progress, and the ability to adapt when 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, policy interpretation, testing, and implementation readiness. Enough flexibility to respond when requirements are clarified, dependencies shift, or issues emerge late in the cycle.

The problem with framework evangelism is that it becomes a substitute for thinking. Teams defend the purity of the method instead of asking the harder question: what will actually get this work over the line?

Three shapes of work

Most projects in regulated organisations fall into one of three categories. Each category has a delivery shape that genuinely suits it. The categories are not branded methodologies. They are descriptions of the work.

The first is a regulatory change with no significant technology component. New conduct rules. AML programme uplifts. A change to a reporting threshold. A change to a customer disclosure obligation. The scope is fixed by statute. The regulator fixes the date. The deliverable is largely defined by external rules. There is little genuine uncertainty about what has to be built. The uncertainty concerns how to operationalise it within the organisation.

The work of this shape is predominantly waterfall. That is not a lack of ambition. It is a response to the constraints. You cannot iterate your way past a fixed regulatory deadline. You cannot treat the regulator’s expected deliverables as one item in a negotiable backlog. The scope is fixed. The date is fixed. The deliverable is fixed. The job is to plan and execute accordingly.

The second is a technology change with no regulatory driver. A new internal platform. A customer-facing app. A migration to a new core system. There is genuine uncertainty about what the right answer looks like. The requirements will evolve as the build progresses. The value of the work increases when it is released incrementally. Users learn from early versions. The team learns from real use.

The work of this shape is predominantly agile. Iterative delivery, working software, regular feedback loops, and an evolving backlog are useful here because the team is learning as it goes. That is not fashion. It is a practical response to genuine uncertainty about what good looks like and how it will land.

The third is regulatory change delivered through technology. A new reporting infrastructure to satisfy a regulator’s data expectations. A new screening system for sanctions or financial crime. A privacy capability to support new rights handling. The regulator has fixed the obligation and the date. The technology required to deliver it is novel, complex, or both.

The work of this shape is genuinely hybrid. The regulatory commitments sit in a waterfall envelope: fixed scope, fixed date, defined deliverables. The technology built inside that envelope runs iteratively, because that is how complex technology is usually delivered. The hybrid is not a compromise. It is the right response to this shape of work. But it needs to be designed deliberately, not allowed to emerge by default. Hybrids that drift into place without a clear design usually combine the worst of both approaches.

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 the governance structure, the artefacts that make change auditable, the language that lets a board understand what is being delivered, and the connections to the operating model that make execution possible. A regulated organisation without a coherent delivery framework is harder to govern, not freer to deliver.

What the framework should also provide is room to choose a route through it. The choice is made at the start of each project, against the actual shape of the work. The questions are simple and not framework specific.

What is the nature of this work? What are the constraints that cannot move: the date, the scope, the regulator’s defined deliverables? Where is the genuine uncertainty: in the requirements, in the technology, in the integration, in user adoption? Given those answers, what is the route through our framework that fits this work?

Answering those questions honestly produces a delivery approach that suits the project. Sometimes it will be heavily waterfall with a few iterative elements inside. Sometimes it will be heavily agile with a defined endpoint and a regulatory commitment overlay. Sometimes it will be a genuine hybrid where the two halves need to stay aligned throughout. All of those can sit comfortably within a well-designed framework.

That conversation needs to happen with the people who will deliver the work, the people who will assure it, and the people who will be accountable for it. Their judgement matters most before the route is set, not after it.

What good looks like for compliance-led work

Where a project is being delivered against a regulatory obligation, strong delivery usually means a more pragmatic approach. Lock down the non-negotiables early. Be explicit about the regulatory interpretation, the minimum viable 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. Improving handovers across teams.

In other words, be flexible in execution but disciplined about outcomes. That balance is usually far more useful than trying to force the whole programme into one ideological model.

Why this is hard in practice

If the point is so obvious in practice, why does the cycle of framework reinvention keep repeating?

Part of the answer is that frameworks have become part of organisational identity. A firm that has spent two years and a large budget declaring itself agile does not easily say, of a particular project, that it should be delivered predominantly in a waterfall. The reverse is true as well. The framework stops being a delivery choice and becomes a statement about what kind of organisation the firm believes itself to be. That makes honest project-level choices harder than they should be.

Part of it is that the senior leaders who commissioned the last transformation are still in the building. Reviewing whether the framework fits would mean reviewing whether their decision still holds. That conversation is easier to avoid than to have.

Part of it is that the question “Are we agile yet?” is 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.

And often the people who can see the mismatch most clearly are the experienced project managers who have delivered enough different types of work to know which approach fits which project. Too often, they are asked to make the work fit the model instead. That is what the cycle looks like in practice.

A final thought

Delivery frameworks are tools, not belief systems. Their value lies in whether they help a team deliver the right outcome, with the right controls, by the required date.

In compliance programmes, success is not measured by how faithfully a framework was followed. It is measured by whether the organisation met its obligation in full, on time, and in a way that stands up to scrutiny. If that takes agile practices, waterfall controls, or a sensible blend of both, that is what good delivery looks like.

Every project is different. The framework should know that.