INSIGHTS
The Next Data Centre
Bottleneck May Not Be Power.
It May Be Execution.
How data centre projects convert construction activity into commissioned capacity
ONYX INDUSTRIAL PERFORMANCE SOLUTIONS
Data centre construction has many of the same ingredients as other major construction projects. Engineering needs to release information. Long-lead equipment needs to arrive. Contractors need access. Thousands of people and activities need to be coordinated. Work needs to be installed safely, to specification and to schedule.
What makes data centres different is what ultimately counts as progress.
A project can look highly advanced physically while critical systems are still unable to energise, test or release capacity. Installed quantities can be increasing while the path to system turnover becomes less certain. Individual functions can appear to be performing well while the project as a whole moves more slowly than expected.
That creates a different productivity problem.
The objective is to convert thousands of construction activities into integrated, tested and commissioned capacity.
Execution, in this context, is much broader than what happens at the workface. It starts with how the whole project is orchestrated, continues through the way executable work is prepared, and finishes when the frontline turns that work into output that is genuinely ready for turnover.
Data Centre Construction Behaves Differently
Physical progress is a less reliable measure of delivery than it appears.
Commissioning shapes the construction sequence. System interfaces are unusually dense. Critical equipment can govern large parts of the programme. Fast-track delivery raises the standard of design readiness required before work reaches the frontline.
These characteristics change the management problem.
A completed package has limited value if it does not advance system turnover. An equipment delivery matters only when the site is ready to use it. A design package that is technically issued but not constructible simply transfers the problem downstream.
The challenge is not simply generating construction activity. It is converting that activity into commissioning-ready systems and released capacity.
The focus must remain on the integration of these elements into a functional whole.
Construction Productivity as a Three-Layer Operating System
A useful way to think about large data centre projects is through three connected layers.
Orchestrate the project. Prepare the work. Execute at the frontline.
Decision speed connects all three.
At project level, leadership needs to coordinate the path to system release.
In the middle of the organisation, engineering, procurement, planning, logistics and construction management need to create enough clean, executable work to support the labour already mobilised.
At the frontline, supervisors and crews convert that prepared work into installed, tested, documented and handover-ready output.
Each layer solves a different management problem. Productivity deteriorates when any one of them breaks down.
There is another variable running through the entire system: decision speed.
Large projects generate constraints continuously. A design question may need input from engineering. A procurement issue may require a vendor decision. An access problem may involve several contractors. A commissioning requirement may change the construction sequence.
The important measure is not how many issues are recorded or how quickly someone replies to an email.
It is how long the constraint remains in the production system before someone owns it, resolves it and returns the answer to the workface.
Decision speed determines how long constraints remain in the production system.
The operating rhythm is straightforward:
Identify constraints early.
Clarify ownership.
Resolve quickly.
Return answers before crew time is lost.
At small scale, a slow decision may affect one crew. At large scale, the same delay repeated across dozens of workfronts becomes a production problem.
Decision speed is therefore part of productivity, not simply part of project governance.
LAYER 1
Orchestrate the Project
A project can perform well function by function and still move slowly overall.
Engineering may be hitting its milestones. Procurement may be placing orders on time. Individual contractors may be achieving their productivity targets. Logistics may be operating effectively.
None of that guarantees that the overall project is progressing in the sequence required for system turnover, energisation and commissioning.
The real challenge is integration.
Engineering needs to release constructible information in the sequence construction requires. Procurement needs to align long-lead equipment and vendor commitments to the construction and commissioning sequence. Construction needs to coordinate civil, structural, MEP and controls work around system turnover rather than isolated package completion.
Specialist contractors and OEMs need to integrate into that same path. Energisation and commissioning then need complete systems, not disconnected pieces of completed work.
As projects scale, coordination complexity grows faster than physical scale.
Every additional workfront, contractor and interface creates more dependencies. More work happens in parallel, more decisions cross organisational boundaries and more opportunities emerge for one function to constrain another.
At some point, management capacity itself becomes a constraint.
Project leadership therefore needs enough capacity to integrate functions, resolve cross-functional constraints and maintain a coherent sequence through construction, energisation and commissioning.
The orchestration challenge
The management question is broader than whether each function is performing.
The more useful question is:
Is the whole project moving toward the next system turnover?
Physical progress only matters when it advances that path.
The objective is not simply to optimise engineering, procurement, construction or commissioning independently. It is to keep the whole delivery system moving in the sequence required to release capacity.
LAYER 2
Prepare the Work
Much of tomorrow’s frontline productivity is created before the shift begins.
The project needs to continually convert design, materials, access, approvals and interfaces into work that can genuinely be executed.
This is where the distinction between scheduled work and executable work matters.
A package can appear on the programme and still contain a design gap. Material may have been procured but not be available when needed. Predecessor work may remain incomplete. Access may be blocked. Permits or inspections may still be outstanding. Cross-trade interfaces may not be resolved.
And the package may be perfectly executable in isolation while still being wrong for the next turnover milestone.
Scheduled work is not necessarily executable work.
This is why executable work should be managed as inventory.
Projects usually manage labour capacity carefully. They know how many people are onsite, what trades they belong to and how the workforce is expected to grow.
Executable work deserves the same discipline.
The project needs enough ready work to support the labour deployed. It needs to be genuinely executable, not ‘almost ready’. It needs to be available in the right locations for the crews and specialist trades onsite. And it needs to support turnover and commissioning priorities.
Executable work inventory should be managed as deliberately as labour capacity.
This also explains why adding labour does not automatically increase output.
If labour capacity grows faster than executable work inventory, crews begin waiting, shifting between areas and working around constraints. Supervisors spend more time finding alternative work. Congestion increases. Incomplete work accumulates and rework becomes more likely.
The site can become busier while the project becomes less productive.
Remove constraints upstream
Design gaps, missing materials, incomplete predecessor work, access conflicts, permit gaps, trade interfaces and sequencing problems should be removed before the work reaches the frontline.
Problems removed upstream cost less than problems discovered at the workface.
The goal is not to release more work. It is to maintain enough clean work, in the right sequence, to keep the project flowing.
LAYER 3
Execute at the Frontline
Prepared work only creates value when it becomes installed, verified, documented and ready for turnover.
That process starts at the beginning of the shift.
The supervisor needs to understand the work package and latest revision, the system or area being released, the relevant hold points and testing requirements, the critical interfaces and what must be completed by the end of the shift.
The shift therefore needs a completion target, not simply a list of activities.
A productive shift starts with a clear completion target tied to turnover.
Installed does not mean complete.
A work package moves through several states:
Installed.
Inspected.
Tested.
Defects closed.
Records complete.
Ready for handover.
A crew may install a significant quantity of work during a shift and still leave very little turnover-ready output behind.
This distinction matters because small completion gaps can accumulate into a substantial hidden backlog.
An outstanding test record may look minor. A handful of punch-list items may look minor. An incomplete equipment tag or missing as-built may look minor.
But if those gaps prevent formal turnover, they can hold back an entire system.
Installed quantity is only one step. Progress should be managed through inspection, testing, records and acceptance.
Close the work while the crew is still there
The cheapest time to resolve a defect, missing record or testing gap is while the crew is still in the area.
Once the workfront has moved on, small completion gaps become harder and more expensive to recover.
Disciplined close-out therefore matters.
Punch-list items need to be closed. Inspection and test records need to be complete. Redlines and as-builts need updating. Tags and equipment records need to be finished. Access and interfaces need to be clear. Formal turnover acceptance needs to occur.
The work is finished when the next stage can use it.
That next stage may be another trade, a systems completion team or commissioning.
The supervisor therefore becomes the final conversion point between prepared work and commissioning-ready output.
Small completion gaps can hold back an entire system turnover.
Decision Speed Is Part of Productivity
Large projects generate constraints continuously.
Engineering questions emerge. Materials move. Access changes. Contractor interfaces collide. Inspection findings require decisions. Commissioning priorities can change the construction sequence.
The issue itself is often less important than how long it remains unresolved.
Decision speed determines how long constraints remain in the production system.
A constraint identified at the workface may need input from engineering, procurement, a vendor, another contractor or the client before work can continue.
The productivity loss is created by the elapsed time between the issue appearing and the answer reaching the crew.
The operating rhythm is straightforward
1.
Identify the constraint early
2.
Clarify ownership
3.
Resolve it quickly
4.
Return the answer before crew time is lost
At small scale, a slow decision may affect one crew.
At large scale, the same delay repeated across dozens of workfronts becomes a production problem.
A 30-minute delay may appear immaterial when viewed as an isolated event. Repeated across crews, contractors and shifts, it becomes a meaningful loss of productive capacity.
Decision speed is therefore part of the production system, not simply part of project governance.
The faster constraints move through the organisation, the more effectively the three layers remain connected:
Orchestrate the project.
Prepare the work.
Execute at the frontline.
From Construction Activity to Commissioned Capacity
The core productivity challenge in data centre delivery is the conversion chain.
Project leadership orchestrates the path to system release.
The middle of the organisation creates enough executable work to support the labour deployed.
The frontline converts that work into installed, inspected, tested, documented and accepted output.
Commissioning converts completed systems into operational capacity.
The quality of that chain determines how quickly construction investment becomes usable infrastructure.
Three questions worth asking
As data centre projects become larger, schedules compress and more activity happens in parallel, these questions become increasingly important.
High activity does not necessarily mean high productivity. High physical completion does not necessarily mean that capacity is close to release.
The projects that perform best will be those that keep all three layers connected:
Orchestrate the project.
Prepare the work.
Execute at the frontline.
They will not simply produce more construction activity. They will convert construction activity into commissioned capacity faster.
01
Are we managing the whole project around system turnover, or mainly managing individual functions?
02
Do we have enough genuinely executable work to support the workforce already mobilised?
03
Are we measuring installed quantities, or commissioning-ready completion?