A 4-Stage Client-Side Delivery Model developed across 25+ years of complex project delivery

"Every major project begins with a bold vision. But between boardroom ambition and built reality lies a governance gap that destroys more projects than any technical failure ever could."

— Sean Auld, on client-side design governance

In twenty-seven years of practice across healthcare, infrastructure, and giga-projects, I have witnessed the same pattern repeatedly: extraordinary design vision, meticulously developed by world-class architects, failing to survive the journey from concept to completion. Not because the design was flawed, nor because the contractor was incompetent, but because no one was systematically governing the translation between strategic intent and built outcome.

This is the governance gap - the space between what a client commissions and what they ultimately receive. It is the stage where value engineering quietly erodes design quality, where consultant coordination breakdowns create interface failures, and where contractor substitutions compromise the very features that made the project worth building. It is, in my experience, the single greatest risk to design quality on major projects, and it is almost always under-resourced.

The distinction matters. Consultant design management - the architect managing their own design team - is a fundamentally different discipline from client-side design governance. The former asks: "Is this the best design we can produce?" The latter asks: "Does this design serve the client's strategic objectives, can it be built within programme and budget, and will the quality survive the delivery process?" One is advocacy for design excellence. The other is stewardship of strategic intent.

Over 25 years, I have developed a systematic framework for this client-side governance role - a 4-stage model that ensures strategic intent is defined, integrated, protected, and ultimately delivered. It has been applied across NHS hospitals, major urban developments, and giga-scale programmes valued at over £1 billion. This article sets out that framework and explains why it matters.

Section 01

The Governance Gap

The architecture profession has, quite rightly, developed sophisticated design management systems. Architects coordinate their own consultants, manage design development through RIBA work stages, and review quality through internal processes. Contractors, similarly, have robust site management, quality assurance, and programme control systems. But between these two well-managed domains lies an accountability void.

Who ensures that the client's strategic intent — the reason the project exists — survives the entire delivery process?

Architects design. Contractors build. But the client's interests at the critical interface between design and construction are frequently unguarded. The consequences are predictable and recurring:

• Value engineering that destroys vision: Cost reduction exercises that strip out the design elements which gave the project its identity, leaving a cheaper building that no longer serves its strategic purpose.

• Consultant coordination breakdowns: Multi-disciplinary teams working in silos, producing technically compliant but spatially incoherent designs because no one is governing the interfaces between disciplines.

• Contractor substitutions: Materials, systems, and finishes swapped during construction for cheaper alternatives, each individually justifiable but cumulatively devastating to design quality.

• Scope creep without governance: Design changes introduced without systematic assessment of their impact on strategic intent, programme, or budget.

The client-side governance role exists to close this gap: systematic review at every decision point, formal validation before commitment, and quality control that protects strategic elements while enabling pragmatic delivery. It requires someone who understands design deeply enough to challenge architects, construction well enough to negotiate with contractors, and commercial reality clearly enough to advise clients on where to invest and where to optimise.

Section 02

The 4-Stage Framework

The Design Governance Framework is structured around four sequential stages, each with four defined pillars. Together, these sixteen governance activities create a systematic process that captures strategic intent at the outset and protects it through design, construction, and handover. The framework is deliberately stage-gated: progression requires formal validation that the preceding stage's objectives have been met.

1. Strategic Definition

You can write here as much as you want, this text will always look nice, whether you write longer paragraphs or just a few words. Click here and try it out.

The most consequential governance decisions are made before a single line is drawn. Strategic Definition establishes the criteria against which every subsequent design decision will be evaluated. Without this stage, projects drift — architects design what they find interesting, not what the client needs; cost consultants benchmark against the wrong comparators; and success is measured subjectively rather than against defined outcomes.

2. Design Integration

Ensuring disciplines work together — coordinating consultants and validating quality against strategic intent.

Design Integration is where governance becomes most technically demanding. The client-side design governor must understand architecture, engineering, cost planning, and programme management well enough to identify when disciplines are producing conflicting outputs, when design quality is slipping, and when cost or programme risks are being concealed within technical complexity.

"God is in the details,"

— Ludwig Mies van der Rohe

Mies van der Rohe famously observed. But on major projects, the devil is in the interfaces. The spaces between disciplines — where the architect's intent meets the engineer's constraints and the cost consultant's benchmarks — are where design quality is most vulnerable.

3. Delivery Assurance

Delivery Assurance is where design governance faces its most significant challenge. The transition from design to construction introduces new actors — contractors, subcontractors, suppliers — whose primary incentives are programme and cost, not design quality. Without systematic governance at this stage, the design intent that was so carefully developed in Stages 1 and 2 can be eroded through a thousand small compromises, each individually reasonable, cumulatively devastating.

4. Transition & Legacy

Ensuring operational success — the ultimate validation of design governance.

A building is not a success at practical completion. It is a success when it is operating as intended — when users experience what the client envisioned, when operational costs align with projections, and when the asset delivers the value that justified the investment. Transition & Legacy governance ensures this final, critical translation occurs.

Section 03

Real-World Application

This framework is not theoretical. It has been developed iteratively across 25 years of practice on projects ranging from acute healthcare facilities to giga-scale mixed-use developments, applied in the UK, the Middle East, and across multiple regulatory jurisdictions.

In healthcare, the framework governed the delivery of major hospital facilities where design governance directly impacted clinical outcomes. Patient flow, infection control adjacencies, and clinical workflow efficiency are all design-dependent — and all vulnerable to the governance gap. By establishing clinical transformation objectives as non-negotiable success criteria in Stage 1, and validating them through every subsequent stage gate, the framework ensured that operational requirements survived the pressure of programme acceleration and cost reduction.

At giga-project scale, the challenges intensify exponentially. Multiple design consultants, each with their own internal quality processes, must be coordinated to deliver a coherent whole. Contractor packages — sometimes numbering in the dozens — must be governed to ensure that interface quality matches the design intent. Stakeholder landscapes involving government authorities, international investors, and multiple operator groups require structured engagement at every decision point.

In these environments, the framework's value lies in its systematic nature. Without formal governance, decisions are made ad hoc, coordination is personality-dependent, and quality is inconsistent. With the framework in place, every critical decision has a defined process, every stage transition has a validation gate, and every element of strategic intent has a named guardian.

The framework prevented a major constructability failure on a large-scale hospitality development when Stage 3 reviews identified that a signature architectural element — approved and celebrated in design — could not be built within the available programme window using locally available skills. Early identification allowed redesign without programme impact. Without governance, it would have been discovered on site, at ten times the cost to resolve.

— Applied governance example, Stage 3: Delivery Assurance

The scale challenge is not simply one of size — it is one of coherence. On a project with 15 consultant firms, 8 contractor packages, and 20 distinct stakeholder groups, the number of coordination interfaces runs into the hundreds. The governance framework provides the systematic structure to manage these interfaces without relying on individual heroics or informal relationships.

Section 03

Client-Side vs. Consultant-Side

The distinction between client-side and consultant-side design governance is fundamental, yet frequently misunderstood. Most architects operate as consultants — they are appointed to deliver design services to a client, and their internal quality processes serve that delivery function. This is necessary and valuable, but it is not sufficient.

Client-side governance requires a fundamentally different perspective. It demands the ability to appreciate and evaluate design quality while maintaining independence from the design team. It requires the confidence to challenge world-class architects when their proposals do not serve the client's strategic objectives, and the commercial acumen to negotiate with contractors on quality issues where cost and programme pressures are intense.

This is the "difficult conversations" role. The client-side design governor must tell an award-winning architect that their concept, however beautiful, does not respond to the brief. They must tell a cost consultant that a proposed saving will destroy more value than it creates. They must tell a contractor that a proposed substitution is unacceptable, and defend that position with evidence rather than opinion.

These conversations require a rare combination: deep design expertise (to earn credibility with architects), commercial awareness (to engage with cost and programme teams), and strategic clarity (to represent the client's interests with authority). It is a leadership competency, not merely a technical skill.

Conclusion

Governance as a Leadership Competency

The Design Governance Framework presented here represents 27 years of iterative development — tested across NHS hospitals where design decisions impact clinical outcomes, refined through major urban developments where stakeholder complexity demands systematic coordination, and proven at giga-project scale where the governance gap can represent hundreds of millions in lost value.

Design governance is not project management. It is not contract administration. It is not design management in the consultant sense. It is the systematic stewardship of strategic intent through the entire project lifecycle - from the client's initial vision to the building's operational reality.

In an era of increasingly complex, internationally delivered, multi-stakeholder projects, client-side design governance is not a luxury - it is a necessity. The question is not whether projects need it, but whether they have someone with the design expertise, commercial awareness, and strategic clarity to provide it.

That is the skillset I bring. That is what this framework delivers.