Data center scheduling: the job isn't done until Level 5 passes

From the outside, a data center looks like a large warehouse: a slab, walls, a roof. That part is ordinary construction, and on most projects it is not what decides the finish date.

A data center is finished when the owner can put it into service. That happens when commissioning passes at Level 5, the point where power, cooling, fire protection, controls and security have been proven to work together. Everything a schedule does on a data center should point at that date.

This guide covers what that means in practice: how commissioning should appear in the schedule, why permanent power sits in front of everything, and the schedule-quality habits that keep a slip visible while there is still time to recover.

The building is the small part

On a commercial building, substantial completion roughly follows the last trade out. On a data center, the last trade out is followed by weeks or months of testing, and the testing has its own critical path.

That path runs through equipment the GC often does not buy. Switchgear, generators, UPS systems and chillers are frequently owner-furnished and ordered long before the construction baseline exists. Lead times explain why. Wood Mackenzie data reported in July 2026 put generator step-up transformers at about 160 weeks and high-voltage breakers at about 125 weeks. By the time the schedule is drawn, some of its most important dates are already fixed by purchase orders.

Five levels of commissioning, five sets of activities

Data center commissioning is usually organized in five levels. Each one is its own set of activities, with its own dependencies.

The commissioning agent, hired by the owner, writes the commissioning plan. On large campuses the agent is often brought in early, sometimes at the start of construction. The owner and the GC review and approve the plan, and then it is locked. From that point the schedule has to carry it, level by level.

Two things follow for the schedule:

• L1 and L2 belong in the schedule even though they happen off site or on delivery. A factory test that slips, or equipment that arrives incomplete, moves everything behind it. Track factory test dates, ship dates and required-on-site dates as activities, not as notes in a procurement log.
• L5 depends on every system at once. It cannot start until power, mechanical, fire protection, controls and security have each passed L4. That makes it the place where every earlier slip adds up.

Commissioning is a loop, so schedule it as one

Commissioning tests fail. That is what they are for. Fire detection is a good example. Data centers use very early smoke detection systems that sense smoke before a person could see it. In testing, the system has a short window to detect a fire and the suppression has a fixed window to act. Miss either and the test fails.

A failed test is rarely a one-day delay. Someone has to find which system failed (the detection, the alarm, the suppression, or the power and controls feeding them), fix it and test again. Because fire protection is tied to electrical and controls, a fix in one system can mean re-testing others.

Most schedules show each commissioning level as a single bar. That bar assumes everything passes the first time. A better schedule carries the loop: test, find the cause, fix, re-test, each with durations and logic ties to the systems involved. When the owner asks "this part failed, how long until we re-test?", the schedule should already have the answer. If the re-test is not in the schedule, nobody can say how long the job has left.

Commissioning practitioners describe the pressure here. One account of commissioning on fast-track data centers describes windows that now shrink "in days, not weeks" as design and construction overlap. The end of the job is where hidden slack runs out, and where there is the least room to absorb a surprise.

Everything waits on permanent power

Every system that has to be commissioned runs on electricity. Until permanent power is energized, integrated testing cannot start. A late utility connection, or late electrical gear, delays every level of commissioning behind it.

The industry data puts power at the top of the list. In Turner & Townsend's 2025 Data Centre Cost Index, 48% of respondents named power availability as the biggest obstacle to finishing on schedule.

In the schedule, that means the energization date should not be a milestone floating on its own. Tie it to every commissioning activity it feeds, and tie the electrical gear behind it (order, factory test, delivery, set, terminate, energize) to the energization date. When the utility date moves, the effect on L5 should be visible the same day.

Know the scope before you trust the schedule

A data center schedule can have thousands of activities. Reviewing it by reading activities one by one is slow, and it misses what is not there. The faster way is to study the drawings and the scope first, then read the schedule against them. Someone who knows what the job should contain sees quickly where the schedule does not match.

The work breakdown structure (WBS) is the first check. The WBS is the scope, broken down. If it is weak, some scope is either missing or mixed in with other work, and the field cannot follow it. A WBS that does not match the drawings is a scope gap, not a formatting issue.

Close every open end

A CPM schedule is a network of activities tied by logic. Its most common hidden flaw is the open end: an activity with no successor, or with only a start-to-start tie and no finish tie.

An open-ended activity can slip again and again without moving a milestone or the longest path. The schedule looks healthy month after month while real work falls behind, and the delay only appears near the end, when it can no longer be recovered. On a data center, the end of the job is a chain of commissioning tests, so that late surprise lands where the schedule has the least room.

The fix is simple to state: every activity needs a predecessor and a successor, and finish ties where the work actually depends on finishing. A three-week look-ahead is only as reliable as the network it is pulled from. With sound logic, the weekly check becomes meaningful: of the activities planned three weeks ago, how many are done, how many are not, and why.

Float belongs to the project

Float is the most valuable thing a schedule has. It is the buffer that absorbs the problems every project has. It is also easy to use up quietly. Sometimes a party hides it, sometimes it is consumed by work that slipped without anyone deciding to spend it, and sometimes the owner never sees it at all.

Treat float as a shared resource of the project, not of whoever reaches it first. Report float consumption with each update, and when float is used, record why. When float disappears and nobody can explain it, the project has lost its buffer without making a decision.

Detail: stop just short of the peak

How detailed should a data center schedule be? Detail helps on a complex job, up to a point. Past that point it becomes cumbersome: updates take longer, the field sees it as micromanagement, and the activities that matter get buried among the ones that don't. A good rule is to stay a little short of the peak. Model the work at the level the team actually manages it, and put the extra detail into the look-ahead, where it is used.

Plan time and cost together

On many projects the schedule is still developed after the estimate, and then maintained separately. On a data center that split is expensive. Linesight notes that the baseline schedule is often set at 10–30% design and "rarely revisited unless a delay occurs", while the cost plan is refreshed at each design stage. Their conclusion is that you cannot control cost without controlling time.

The connection is direct. One procurement date drives escalation, storage, extended general conditions and damages exposure at the same time. When that date moves, both the schedule and the estimate should move with it. We cover the cost side in On a data center, the schedule is part of the estimate.

The constraint the schedule doesn't show: people

A schedule can run activities in parallel only if there are crews to staff them. On data centers, especially in remote markets, crews are often the real limit. Prefabrication helps, but only part of the work can move off site. Remote sites may need worker housing. Compressed deadlines lead to long shifts and fatigue, and some contracts now include minimum rest periods.

Resource-load the peak of the schedule, especially electrical and commissioning, and check it against the crews that can actually be on site in that window. That is why we treat subcontractor coverage on a data center as crews who can staff the peak, not as proposals received.

A checklist before you trust a data center schedule

• Is "done" defined as Level 5? Commissioning should be in the schedule level by level, from factory tests to integrated testing. The cost side is in our guide to pricing L1–L5 commissioning in bids.
• Is there time for failed tests? Re-test loops should be activities with durations and ties, not hope.
• Is the power date tied in? Energization should drive every commissioning activity it feeds, and the electrical gear should drive energization.
• Does the WBS match the drawings? Missing or mixed scope shows up here first.
• Are there open ends? Every activity needs a predecessor and a successor.
• Who is using the float? Report it, and record why.
• Do time and cost move together? When a long-lead date moves, the estimate should move with the schedule.
• Can the peak be staffed? Check the crews behind the parallel work.

Where Piper fits

Most of the checks above start before the schedule exists: knowing the scope from the drawings, knowing which equipment is owner-furnished and when it is due, knowing which commissioning responsibilities each proposal covers. That knowledge usually sits in different documents and different people's heads, and the schedule and the estimate drift apart because nothing connects them.

Piper is the AI operating system for preconstruction. It maintains one understanding of the project across the drawings, specifications, equipment lists, proposals and the estimate. When a delivery date, a commissioning requirement or a design revision changes, Piper traces which scopes, bidders and cost lines depend on it, with the source behind each. Piper does not build the CPM schedule. The scheduler still owns the logic and the team still decides how to price the risk.