A Stage Gate Is Not a Date: Why Design Readiness Needs Evidence

Projects need dates.

Concept Design needs an end date. Schematic Design needs a milestone. Developed Design needs a point at which cost planning, approvals, tender preparation or procurement can move forward. Consultant programmes cannot operate without these boundaries.

But a date is not the same thing as readiness.

A project can arrive at the end of a design stage with drawings issued, presentations approved and consultant deliverables uploaded, while still carrying unresolved decisions that the next stage is about to inherit.

That is the difference between programme completion and design maturity.

A stage gate should test the second.

Why stage dates become dangerous

The programme itself is not the problem. The problem begins when the project starts using the date as evidence that the design is ready.

A concept package may look coherent while the services zones have not been protected. A room or tenancy module may be approved while structure and MEP implications remain untested. A fire strategy may exist but may not yet be reflected consistently across disciplines. An authority pathway may be assumed rather than confirmed. An operator comment may have been acknowledged but not incorporated. A cost plan may be based on information that is still moving.

None of these conditions automatically means the project should stop.

They do mean the project should know what it is carrying forward.

The project has moved. The risk has moved with it.

What an evidence-based stage gate is actually testing

A useful stage gate is not a ceremonial approval meeting. Nor is it an attempt to freeze every detail too early.

It is a decision about whether the information produced at one stage is sufficiently mature for the next stage to rely upon it.

That requires a different set of questions from "Have the drawings been issued?" or "Has the client signed off the presentation?"

Has the purpose of the stage actually been achieved?

Are the major decisions visible?

Have the critical multidisciplinary interfaces been tested to the level required at this point?

Are approval assumptions clear?

Has cost advice been based on information that genuinely represents the current design?

Are unresolved matters classified and owned?

Can the next team understand what it may rely upon and what remains conditional?

These questions do not demand perfection. They demand honesty about maturity.

Different stages need different evidence

The evidence required at Concept Design is not the same as the evidence required before tender or construction.

At concept stage, the project may need confidence that the basic asset logic works: access, massing, room or tenancy modules, vertical circulation, broad structural logic, service zones, fire principles, operator or client requirements and likely approval constraints.

At schematic design, the technical systems should be becoming credible. Plant space, major risers, MEP zones, structural interfaces, room data, BIM deliverables, cost assumptions and approval risks should be visible at an appropriate level.

At developed design, the project should be testing whether the consultants, authority requirements, operator/client decisions and cost decisions are genuinely coordinated.

Before tender or construction, the threshold becomes much higher. Drawings, specifications, schedules, room data, long-lead decisions, authority conditions, value-engineering changes and procurement assumptions need to tell a consistent story.

The gate therefore changes with the stage.

The principle remains the same: what is the next stage entitled to rely upon?

Not every uncertainty has to disappear

No complex project reaches a stage gate with every future question answered.

Some information is intentionally developed later. Some specialist design cannot be completed before procurement. Some authority matters remain subject to review. Some client decisions may be carried for a limited period because other work can proceed safely around them.

The problem is not residual uncertainty.

The problem is invisible residual uncertainty.

A mature project should be able to distinguish between three conditions.

First, matters that must be resolved before progression because the next stage cannot safely work around them.

Second, matters that may proceed conditionally because the residual risk is understood, an owner is identified and the consequence is acceptable.

Third, matters that are legitimately not yet active but must be picked up at a defined future point.

That distinction allows a project to move without pretending that every issue is closed.

Proceed, proceed with accepted risk, or do not proceed

This suggests a practical way of thinking about stage-gate outcomes.

A project can PROCEED when the stage purpose has been achieved and the remaining open matters do not undermine the reliability of the next stage.

It can PROCEED WITH ACCEPTED RISK when specific unresolved matters are visible, owned and judged acceptable for a defined period.

Or it can DO NOT PROCEED when the design is being asked to move forward while carrying issues that make the next stage unreliable.

The middle category matters.

Projects often need to progress before every uncertainty has disappeared. Governance should not become a reason to stop intelligent progress. But conditional progression should be explicit.

"We know this is unresolved, we know what it affects, we know who owns it, and we know when it must be closed" is very different from "we will sort that out later."

Risk acceptance is also a design decision

Sometimes a project knowingly proceeds with an unresolved matter. That can be entirely reasonable.

The question is whether somebody with the appropriate authority has understood what is being accepted.

What is the unresolved condition?

What are the plausible consequences?

What future work depends on it?

What would trigger escalation?

When does the risk become unacceptable if it remains unresolved?

Who has authority to accept it?

If those questions are not visible, the project is not really accepting risk. It is simply allowing uncertainty to travel.

What proves readiness?

Readiness should leave evidence.

The form of the evidence varies with the project and stage. It may include coordinated drawings, a model review, a signed-off decision, an updated cost plan, an authority response, a completed design-risk review, an operator comment closure record, a room-data milestone, an agreed procurement strategy or a documented residual-risk register.

The point is not to create a thick stage-gate report for every project.

The point is that the decision to progress should be based on more than a date and a feeling.

The evidence should answer the questions the next stage will depend upon.

The missing link: downstream dependency

One of the strongest ways to test readiness is to look forward.

What does each unresolved issue block next?

If a plant-room decision remains open, can the structure progress? Can the services routes be fixed? Can acoustic treatment be designed? Can procurement move?

If an operator decision is outstanding, does it block room data, MEP, FF&E, mock-ups or cost planning?

If an authority matter is unresolved, does it threaten consent, building form, access, fire strategy or staging?

If a value-engineering decision is not incorporated, can the tender package be relied upon?

This downstream view changes the stage-gate conversation.

Instead of asking only whether the current team has finished its deliverables, the project asks whether the next team has trustworthy inputs.

Closure must also be real

Another common stage-gate weakness is the use of status labels without evidence.

An issue may be marked closed because it was discussed, because a consultant responded, or because the client acknowledged the recommendation.

But if the issue affects design information, the project should be able to show where the consequence has actually been resolved.

A revised drawing. An updated model. An amended specification. A recorded approval. A cost-plan adjustment. A procurement confirmation. A certificate.

Closure evidence is important because stage gates are transfer points. The next stage should not have to rediscover supposedly closed issues.

Who should participate in a stage gate?

A stage gate should not become the design manager's private judgement. The value comes from assembling the perspectives that the next stage will depend upon. Depending on the project, that may include the client, architect, engineering leads, project manager, cost consultant, BIM or information lead, operator, contractor adviser and relevant statutory specialists.

The group does not need to review every drawing. It needs to test the small number of conditions that define readiness at that point. The cost consultant may confirm whether the current information supports the cost plan. The approval lead may identify conditions that still affect design. The BIM lead may confirm whether the model exchanges are aligned enough for the intended use. The operator may identify unresolved standards that would otherwise become late changes.

This multidisciplinary view is important because design maturity is rarely owned by one discipline. A package can be complete within architecture while still being immature as a project input.

What should a stage-gate record contain?

The record can be concise. It should show the gate decision, the evidence reviewed, any mandatory closures, any residual risks being carried forward, the owner of each carried item, the downstream dependency and the date or trigger by which the matter must be resolved.

That record becomes part of project memory. When a question reappears later, the team can see whether the risk was unknown, accidentally missed, or consciously accepted. That distinction matters commercially and professionally.

Stage gates are not bureaucracy

The phrase "stage gate" can sound corporate. Used badly, it can become bureaucracy: another meeting, another checklist, another approval box.

That is not the objective.

Good governance reduces confusion. It should concentrate attention on the few things that matter most at the transition point.

A useful gate makes open risk visible, clarifies responsibility, records what is being accepted and protects the next stage from unreliable information.

It should make projects faster by reducing avoidable rework, not slower by adding ceremonial process.

Stage gates improve learning as well as control

There is another benefit. When the same stage-gate questions are used across several projects, patterns become visible. A developer may discover that authority assumptions are repeatedly being carried too late. A design practice may see that plant and riser space is routinely under-tested at concept stage. A contractor may find that specification alignment is a recurring tender problem.

Those patterns can improve future briefs, consultant scopes, fee allowances and project programmes. The gate is therefore not only a control point for the current project. It can become a learning mechanism for the organisation.

The senior question

At every stage transition, one question deserves to be asked plainly:

Can the next stage safely rely on what we are handing over?

If the answer is yes, proceed.

If the answer is yes with conditions, record the conditions and the risk owner.

If the answer is no, a programme date should not be allowed to disguise the problem.

A stage gate is not a date.

It is a decision about the maturity of the information being transferred - and the quality of every downstream decision that will rely upon it.

Medicine Trains Responsibility Early. Why Does Architecture Often Delay It?

Medicine is different from architecture in obvious and important ways.

Its domain is direct clinical care. Its stakes are immediate in a different register. Its systems of supervision, regulation, and public accountability are shaped by that reality.

So the comparison should be made carefully.

And yet medicine still offers architecture a useful mirror.

One of its strengths is that responsibility is made visible early.

Medical training does not behave as if ethics, standards, public safety, and supervised responsibility are side issues to be picked up later when the student becomes more serious. They are woven into the identity of the profession from an early stage. The student learns, in increasingly formal ways, that competence is not simply a matter of knowledge or technical skill. It is also a matter of judgement, duty, standards, and the consequences of error.

Architecture also works inside public consequence.

Not in the same form, and not with the same immediacy as medicine, but still materially and socially. Buildings affect safety, access, fire performance, circulation, durability, environmental quality, structural coordination, and long-term public use. Design decisions can affect cost, risk, compliance, maintenance burden, and human wellbeing. Poor judgement may not appear as a dramatic event in the same way, but it can still shape harm, exclusion, failure, or liability over time.

And yet architecture often introduces the language of consequence more slowly.

The student may spend years developing spatial intelligence, representational skill, and conceptual confidence while the deeper vocabulary of duty, negligence, exposure, record, scope, and professional accountability remains less central than it should be. Responsibility appears, but sometimes as a subject category rather than as a professional atmosphere.

That is the difference worth paying attention to.

The issue is not whether architecture should imitate medicine’s structures.

It is whether architecture has been too comfortable postponing the emotional and intellectual seriousness of professional consequence.

A culture reveals itself in what it introduces early.

If a profession makes responsibility visible from the beginning, students do not interpret it as an interruption. They understand it as part of what the work is. If a profession introduces responsibility later, the student may unconsciously absorb the idea that consequence is external to the real discipline, or that it only becomes relevant after design has already happened.

That has implications.

It affects how students understand authority. It affects how they relate to standards. It shapes whether they see documentation as serious or merely laborious. It influences whether statutory systems are treated as public responsibilities or as obstacles. It also affects whether they view professional judgement as something expansive and integrated, or as something split between ideal design thinking and unfortunate practical constraint.

Architecture has too often tolerated that split.

This is visible in the way some parts of professional culture still talk. Creativity is described with admiration. Responsibility is described with fatigue. The conceptual is elevated. The regulatory is endured. The imaginative is celebrated. The defensive, contractual, or code-literate is tolerated but rarely admired.

That hierarchy is not harmless.

It encourages a late confrontation with reality.

The graduate who first meets responsibility fully in practice can feel not only unprepared, but disoriented. They may know how to think architecturally in the studio sense, but not yet how to think architecturally under consequence. The change in atmosphere can feel abrupt because the profession has not fully prepared them for its ethical and legal weather.

A more mature educational culture would make that weather visible earlier.

Not by frightening students. Not by reducing architecture to risk management. Not by replacing design ambition with institutional caution.

But by telling the truth more clearly.

The truth is that architecture is practised in public. It affects real people. It operates under law and code. It coordinates with other expert systems. It depends on documents that have consequences. It requires judgement that must remain calm even when conditions become unstable.

That is not a later-stage add-on.

It is part of the profession’s moral and practical structure.

Medicine understands that responsibility cannot be left too late because lateness changes the culture of competence. It makes responsibility feel like a burden that arrives after the meaningful work has already happened.

Architecture risks doing something similar when it delays the integration of duty, consequence, standards, and public responsibility into the heart of formation.

The strongest architects are not only those who can conceive well.

They are also those who can carry consequence without drama.

They understand that good judgement is not an afterthought to creativity. It is one of the conditions that makes creativity trustworthy in the real world.

That insight needs to arrive earlier than it often does.

Because responsibility should not feel like a postgraduate surprise in a profession whose work enters the public realm, affects safety and welfare, and is shaped by law, code, and accountability from the moment it begins to become real.

The earlier architectural education says that plainly, the less the profession has to rely on delayed correction later.

And the less likely it is that young architects will mistake consequence for something foreign to the discipline they chose.