Skip to content
Alex Hurst

▸ Leadership approach

How complex delivery organisations are led

An evidence-led articulation of how complex delivery organisations are led — control before complexity, useful reporting, structured recovery, commercial realism and repeatable operating models.

CapabilitiesProjects

01

Establish control before adding complexity

In practice

Clarify ownership, decision rights, plans and escalation paths before expanding concurrent programmes. Visibility and accountability come first; more workstreams follow once the system can absorb them.

Why it matters

In scaling infrastructure businesses, adding programmes without an operating model multiplies hidden risk. Control is the prerequisite for pace, not its opposite.

Evidence

At Nscale, the delivery organisation, four-pillar operating model, governance and planning disciplines were established from zero during an early scale-up — before the portfolio could be run as a controlled multi-region book of work. HyperDeploy — which I created and led into adoption — is the separate delivery methodology used on programmes; it is not part of the pillar structure.

PMO establishmentDelivery operating modelsPMO operating model

02

Build the operating model around the delivery challenge

In practice

Design organisational structures, cadences and standards around the real constraints of the work — multi-site builds, supplier lead times, customer acceptance and cross-region dependencies — rather than importing generic process.

Why it matters

Infrastructure delivery fails when the model ignores power, cooling, hardware lifecycle, field capacity or acceptance criteria. The operating model must fit the physics and commercial reality of the commitment.

Evidence

The four-pillar operating model — Squad Delivery, Central Planning, PMO, and Capability & Development — structured the delivery organisation for concurrent GPU builds. Separately, HyperDeploy — which I created and led into adoption — is the delivery methodology for enterprise GPU deployments.

Delivery operating modelsLifecycle controlsPMO operating modelHyperDeploy methodology

03

Make delivery reporting useful for executive decisions

In practice

Reporting should surface plan, variance, risk and forecast in a form leaders can act on — not activity noise. Decision-quality information beats volume of status.

Why it matters

Executives intervene too late when reporting is late, inconsistent or anecdotal. Comparable portfolio views enable earlier trade-offs on time, cost, scope and risk.

Evidence

Approximately 90% delivery-date forecast accuracy within a ±1-week tolerance across six deployments over nine months reflects the value of disciplined forecasting and variance visibility.

Executive reportingForecasting and predictabilityGPU cluster delivery

04

Treat recovery as a structured management discipline

In practice

When commitments are threatened, establish the facts, rebuild the critical path, assign owners, escalate decisions that need executive authority, and track residual risk through to acceptance.

Why it matters

Ad-hoc firefighting hides the real constraint and burns trust. Structured recovery restores confidence with a plan others can inspect and support.

Evidence

Hardware supply recovery restored customer acceptance ahead of the target date. Technical remediation unblocked acceptance on a deployment involving thousands of GPUs by the required deadline.

Programme recoveryCritical-path managementHardware supply recoveryTechnical remediation

05

Connect commercial decisions with delivery reality

In practice

Capex approvals, supplier strategy and investment cases should reflect schedule risk, readiness and acceptance — not sit apart from the delivery plan.

Why it matters

Commercial choices that ignore lead times, capacity or acceptance criteria create commitments the organisation cannot keep. Delivery leadership must bring those constraints into the decision.

Evidence

Delegated Capex approval authority up to £500,000 supported controlled investment decisions inside a multi-billion-pound planned portfolio context. An acquisition business case was developed for specialist high-density GPU cabling capability.

Capex and financial governanceInvestment business casesPMO operating modelGPU cluster delivery

06

Make successful delivery repeatable

In practice

Standardise what works — deployment sequences, reporting, acceptance and handover — so each programme improves the system instead of starting from a blank page.

Why it matters

Without repeatability, every deployment reinvents method and relearns the same failures. Predictability and scale depend on a shared model.

Evidence

Within the wider operating context — including the delivery organisation and HyperDeploy as the delivery methodology — boots-on-the-ground to customer handover reduced from 14 weeks to 8 weeks for appropriately sized deployments. That improvement is not attributed solely to HyperDeploy.

Repeatable deployment modelsLifecycle controlsGPU cluster delivery

07

Balance governance with the pace of execution

In practice

Use enough control to protect commitments and escalate decisions — without slowing field and engineering teams with process that does not change outcomes.

Why it matters

Excess bureaucracy loses the schedule; too little control loses the portfolio. The balance is judged by forecast quality, escalation clarity and handover readiness — not by document count.

Evidence

HyperDeploy’s modular lifecycle and stage-gate approach — which I created and led into adoption — provided enough delivery discipline for consistency, while an enterprise work-management platform served as the programme system of record for planning, RAID and reporting — without replacing on-site execution ownership. The four-pillar operating model remained the separate organisational structure.

Lifecycle controlsGovernance frameworksDelivery operating modelsHyperDeploy methodologyPMO operating model

08

Maintain clear accountability from commitment through to handover

In practice

Ownership must remain visible from contracted commitment through deployment, acceptance and operational handover — across internal teams, suppliers and customers.

Why it matters

Handover is where many programmes lose the thread. Clear completion criteria and unbroken accountability protect customer trust and operational readiness.

Evidence

More than 20,000 GPUs were delivered end-to-end across two large clusters, with a further major deployment led in parallel, including operational readiness and handover into production service.

Customer acceptanceOperational handoverGPU cluster deliveryTechnical remediation

▸ Continue

Related pages