Fourteen Months, Six Weeks, and Two Teams Already Building

No. The plan misreads the ADM as a waterfall.

Key reasoning:

• The ADM is inherently iterative, at several levels: the whole Architecture Capability cycle, the Architecture Development cycle, the transition planning cycle, and iteration within phases. Choosing breadth-first (shallow across all domains) versus depth-first (deep on the part that is needed now) is a deliberate tailoring decision, not a default.
• The plan locks in a single pass, which is exactly what produced the abandoned 400-page document last time. The previous failure was not a documentation failure; it was a scope-and-timing failure.
• Quarterly funding boundaries create real decision points. A fourteen-month cycle will be interrupted at least three times by funding decisions and changes. Phase H (Architecture Change Management) must be expected to operate during the cycle, not after it.

Alternative Breadth-first at enterprise level, depth-first per delivery increment:

1. A short enterprise-level cycle producing the Architecture Vision, principles confirmation, a high-level target, and the partitioning of the programme into segments/releases.
2. Then per-increment cycles (Phases A–D scoped to that increment, then E–G), each producing enough architecture for the next release.
3. Transition Architectures at each quarterly funding boundary, describing the state the agency will be in at that point. These are the artefacts the sponsor will actually use to make funding decisions.

Agile delivery does not sit outside the ADM; it sits inside the later phases, and the risk is that the payments build is currently ungoverned.

• Position in the method. The teams are executing Phase F (Migration Planning) and Phase G (Implementation Governance) for a slice of the programme. Their work should be informed by Phase E solution building block decisions and constrained by the target architecture.
• What governs them. An Architecture Contract setting out what the solution must conform to (interfaces, data definitions, standards, non-functional requirements) and what the team may decide locally. Without it, the squad is making architecture decisions by default.
• Requirements Management sits at the centre of the ADM. Squad backlogs are requirements. There must be a route for backlog items that change architecture to become change requests, and for architecture decisions that affect squads to arrive in backlogs as enablers.
• Compliance touchpoints must match their cadence - per increment or at sprint boundaries, not a single Phase G gate eight months away.
• Concrete risk to call out now: a payments module built before the target is defined may hard-code data or integration choices that conflict with it. A short gap analysis of what the squads have already built, done this month, is cheaper than remediating it after Phase D.

Deliver Phase A properly and be explicit about what is deferred. Six weeks is enough for Phase A and a thin slice of B, and pretending otherwise is how the previous cycle failed.

Produce:

• Architecture Vision - scope, drivers, goals, measurable outcomes, the high-level target, and the increment partitioning.
• Statement of Architecture Work - agreed scope, constraints, plan for subsequent cycles, and an explicit statement of which domains and phases are deferred and why. This document is what protects the team when someone later asks for the missing 400 pages.
• Capability Assessment - including the readiness of the agency to absorb the change, not just architecture team capacity.
• Stakeholder map with engagement approach, and confirmed principles.
• Compliance and governance model for the agile teams, so the payments work is brought inside governance immediately.
• First increment's worth of Phase B/C content, at just-enough depth to start Phase E.

The cultural fix is structural: co-locate or embed architects with delivery. Two buildings is an unstated architectural decision that the squads are already making for you.