Phase G, Implementation Governance

In plain terms, Phase G is the phase that governs delivery. It runs while implementation projects are underway and makes sure that what gets built conforms to the architecture that was agreed. The correct technical name is Implementation Governance, and in the TOGAF Architecture Development Method it is the seventh phase, sitting after the planning phases and before Phase H, which manages change once the solution is live.

The distinction that matters is between deciding and delivering. Phases A through F decide: they set the vision, describe the target across the business, data, application, and technology domains, find the gaps, and plan the sequence of change. Phase G does not decide the architecture. It defends a decision that has already been made, against the ordinary pressures of a build, where schedule, cost, and local convenience all push delivery teams towards small deviations that add up.

The strategic reading is that Phase G is where architecture earns or loses its credibility. An enterprise that plans carefully and then governs nothing has spent money describing a target it will not reach. Leaders judge the architecture function by whether the deployed reality matches the agreed intent, and that match is exactly what Phase G protects.

The cycle below places Phase G among the nine phases, so the intent it defends can be read back to the phases that produced it.

Phase G does not start from a blank page. It inherits the outputs of the earlier phases and uses three of them as its working baseline. Each answers a different question about the build.

The Architecture Contract. This is the agreement between the architecture function and the delivery organisation. It names the deliverables, the quality expectations, and the fitness-for-purpose criteria that the built solution has to meet. It answers the question: what did we agree the delivery team would produce, and to what standard? The contract, its role, and its waiver mechanism are taught in full in the compliance and contracts module, so this module treats it as the primary thing Phase G enforces rather than re-teaching how it is written.

The Implementation and Migration Plan. This is the sequenced plan of work packages and transition states that turns the target architecture into a series of deliverable steps. It answers the question: in what order does the build happen, and which transition state is each project meant to reach? It builds on the migration plan and the architecture roadmap produced in the earlier planning phases. Phase G uses it to know which project it is governing at any moment and what that project is supposed to achieve.

The Architecture Definition Document. This is the description of the target architecture itself, across all four domains. It answers the question: what does correct look like? When a delivery decision is in doubt, this is the document the governance activity reads to judge whether the decision keeps the build inside the agreed target or takes it outside.

Read together, the three inputs form a baseline: the contract sets the standard, the plan sets the sequence, and the definition sets the target. Phase G checks each unit of delivered work against all three.

Governance in Phase G is not a single sign-off at the end. It is a set of activities that run continuously alongside implementation, so divergence is caught while it is cheap to correct rather than discovered after deployment. Four activities matter most.

Confirm scope and priorities with development. Before a work package starts, the governance activity confirms with the delivery team what the package is meant to deliver, which transition state it targets, and which parts of the contract apply. This turns the plan from a document into a shared understanding.

Check conformance against the target. As the build proceeds, delivered work is checked against the Architecture Definition Document and the contract. This is a compliance review in practice: does the actual implementation match the agreed target, or has it drifted?

Manage deviations through the contract, not around it.Real builds produce genuine reasons to deviate. Phase G does not forbid deviation; it routes it. A proposed deviation goes through the contract's waiver mechanism so it is decided deliberately, with an owner and a review date, and recorded in the governance log. The waiver and dispensation mechanism itself is taught in the compliance and contracts module; the board that adjudicates the harder cases is the subject of the Architecture Board module.

Produce the artefacts that let others check the decision later. Every conformance check and every deviation decision is recorded, so an auditor, a regulator, or a future architect can trace what was agreed, what was built, and why any difference exists.

The connecting idea is that Phase G governs by consuming its inputs continuously. The contract, the plan, and the definition are not read once at kick-off. They are the reference the governance activity returns to every time a delivery decision needs a judgement.

The output that Phase G produces is a Compliance Assessment. It is the recorded judgement of how far a delivered solution conforms to the target architecture and the contract. It states plainly where the build conforms and where it deviates, and for each deviation whether a waiver has been granted or a correction is required.

The assessment is the pivot of a loop, not the end of a line. As a solution or a transition step reaches the point of deployment, the governance activity assesses it against the baseline and reaches one of two outcomes. If the step conforms, it is signed off and allowed to deploy. If it deviates in a way that has not been agreed, it is sent back for correction, or the deviation is taken through the waiver mechanism for a deliberate decision. The corrected step is then reassessed. The step only deploys once the assessment says it conforms or that any remaining deviation has been formally accepted.

This is the deployed-solution sign-off loop. It matters because it converts governance from an opinion into a gate. Without it, a deviation is a note in a report that someone may or may not act on. With it, a deviation blocks deployment until it is either corrected or explicitly accepted by someone with the authority to accept it. The figure above draws this loop: the three inputs feed a governed-delivery band, an assessment arrow runs to the Compliance Assessment, and a return arrow labelled sign off or send back closes the loop.

One further link closes the method. When a solution is signed off and deployed, Phase G hands over to Phase H, which manages the architecture through change in operation. The Compliance Assessment travels with it, so the record of what was built and how it conforms becomes the starting baseline for managing the live solution.

London Grid Distribution is a distribution network operator for Greater London, serving 2.3 million customers across 36,000 km of cable and 77 primary substations with 4,000 staff, all under Ofgem regulation and the RIIO-ED2 price control. Its largest current programme replaces the customer and connections systems that sit at the centre of its obligations. The board approved the target architecture and an Architecture Contract for the build. Phase G is how London keeps that build honest.

The baseline the build is governed against

The Architecture Contract names the deliverables and the fitness-for-purpose tests each release must pass, including the resilience and data-publication requirements London carries as a regulated operator. The Implementation and Migration Plan sequences the replacement into transition states so the network keeps running while systems are swapped. The Architecture Definition Document describes the target the built systems must reach. Phase G reads all three whenever a delivery decision is in doubt.

Governance in action

When the delivery team proposes to replace an approved integration platform with a cheaper alternative to hold the schedule, Phase G does not simply refuse. It checks the change against the target and the contract, finds that it weakens a resilience commitment tied to a regulatory obligation, and routes it through the contract's waiver mechanism. The deviation is either corrected or formally accepted with an owner, a compensating control, and a review date, and the decision is recorded so it can be traced later. This is the same class of divergence that went unnoticed in the opening story, caught here because someone was consuming the contract during the build.

The sign-off loop and the regulatory record

Each transition step reaches a Compliance Assessment before it goes live. The assessment states where the release conforms and where it deviates, and only a conforming or formally waived step is signed off to deploy; anything else is sent back. Because London is regulated, those assessments are not just internal hygiene. They feed the evidence London relies on to show Ofgem that its delivery met its commitments, so the sign-off loop doubles as a regulatory audit trail. When a step deploys, its Compliance Assessment passes to Phase H as the baseline for managing the live system.