 |
| A design stage is not complete because the calendar says so. It is complete when the evidence says so. |
A design stage is not complete because the
calendar says so. It is complete when the evidence says so.
Project programmes need dates. Teams need deadlines. Owners need
milestones. None of that is in dispute. The problem begins when a date on the
programme is mistaken for proof that the design has reached the maturity
required by the next stage.
Hotels are particularly exposed to this problem because so many
systems mature at different speeds. Architecture may be visually advanced while
plant zones remain unresolved. Interiors may be developed while operator
comments are still open. A tender set may be issued while Room Data Sheets are
unstable. Procurement may start while long-lead technical interfaces are still
moving.
The stage name can therefore say one thing while the information
condition says another.
A stage gate is a decision threshold
The purpose of a stage gate is not to stop the project. It is to
make progression conscious. The gate asks whether the information required by
the next stage is reliable enough to be relied upon — and, if not, whether the
residual risk has been made explicit.
This is different from demanding perfection. No large project
reaches a point where every item is closed. The discipline lies in
distinguishing between issues that can safely carry forward and issues that
will damage the next stage if they remain unresolved.
What maturity looks like
Design maturity is not the same as drawing quantity. A large
drawing set can still be immature if important decisions remain inconsistent or
dependent on assumptions.
A mature stage has three characteristics:
·
the important decisions for that stage are visible;
·
the downstream information reflects those decisions; and
·
the evidence needed to support progression can be found.
Evidence might be a coordinated drawing, a model update, an
operator sign-off, a revised RDS, an authority response, a cost-plan
adjustment, an approved sample, a mock-up closure record or a commissioning
result.
Hotel gates through the lifecycle
Concept gate
Before schematic design accelerates, the project should know
whether its basic asset logic works: room types, arrival, guest and event
flows, service movement, BOH principles, operator requirements and the major
risks that could destabilise the concept.
The question is not whether the concept is attractive. It is
whether the concept is a sufficiently honest basis for technical development.
Schematic gate
This is where major plant, risers, MEP zones, fire strategy,
vertical transport, room modules and service requirements need enough
definition to protect space and cost. If those systems remain vague, developed
design inherits instability rather than design intent.
Developed design / tender gate
Before market issue, drawings, specifications, operator
comments, RDS information, VE decisions, authority conditions and long-lead
assumptions need to align. A tender package should not transfer unresolved
design ambiguity to bidders and call that procurement.
Procurement and construction gates
Substitutions, shop drawings, material approvals and mock-ups
should be tested against the design baseline. Construction pressure makes
verbal decisions tempting, but unrecorded change is exactly how design intent
becomes difficult to trace.
Opening-readiness gate
The opening date is not the gate. Readiness is the gate. Systems
testing, room readiness, BOH readiness, statutory certificates, operator
training, critical defects and handover information need to converge
sufficiently for the hotel to operate safely and reliably.
Risk can cross a gate — but it should not cross invisibly
Some issues will always carry forward. The wrong response is to
pretend otherwise. The stronger response is explicit risk acceptance.
If an issue crosses a gate, the project should know who owns it,
why it is acceptable to carry, what it could affect, when it must close and
what evidence will prove closure. This prevents 'temporary' assumptions from
becoming permanent by neglect.
Why this is commercially important
The cost of unresolved information tends to increase as the
project advances. A room-layout issue is cheap to correct in concept and
disruptive during fit-out. An MEP-zone problem is manageable in schematic
design and costly after procurement. A substitution is easier to govern before
order placement than after installation. Missing asset information is easier to
capture during procurement than reconstruct at handover.
Stage gates therefore protect not only design quality but also
optionality. They keep correction available while correction is still
relatively inexpensive.
A better programme conversation
The practical shift is small but important. Instead of asking
only 'Are we on the date?', ask 'What condition must be true by that date?'
That changes a stage milestone from a reporting event into a
governance decision. It creates a more useful conversation between owner,
operator, PM, design team, contractor and procurement team because the debate
moves from percentage complete to evidence of readiness.
Dates create urgency. Evidence creates
confidence.
