The system programme assumes a building. It assumes racking in by a date, power and data to the floor by a date, a dock that can take a truck by a date. The construction programme assumes none of the system programme exists. It has its own critical path, its own weather, its own supplier who is late with the roof cladding, and when it slips it slips quietly, in a site meeting the integrator was not invited to. Six weeks later the system team turns up to install access points in a shed that has no roof.
Where the two clocks collide.
Racking and the warehouse structure.
The system's picture of the warehouse is built from the racking drawings and verified against the installed racking. If the racking slips, the verification slips, the labelling slips, and so does every test that needed a real bin to scan. If the racking supplier substitutes a bay depth or the layout changes to suit a column that was not on the drawing, the structure has to be rebuilt.
Power, data and hardware.
RF coverage has to be surveyed in the building as built, with the racking in, because steel changes the signal. Access points, mounted terminals, label printers and the network behind them all need the building to be at a certain stage, and that stage is usually later than the system plan assumed.
Handover and first stock.
Practical completion, the certificate of occupancy, the first truck allowed on site: each is a construction milestone that the system cutover depends on absolutely and controls not at all. Stock arriving before the system is ready is a warehouse run on paper. The system ready before stock can arrive is a team on standby at a day rate.
The opening date.
The one thing that does not move. Customers were told, leases were signed, the old site's exit date is fixed. Every slip in either programme compresses what remains, and what remains is always testing, training and readiness, the three things that decide whether the first week works.
Running them as one.
None of this is hard to fix, it just has to be someone's job.
Put both programmes on one page, with the construction milestones the system depends on named explicitly: racking installed by aisle, power to the floor, data to the floor, occupancy, first delivery. Give each of those a system-side consequence next to it, in writing, so when the builder reports a slip everyone can see what it costs on the other clock.
Get the system lead into the site meeting. Not every week, but at every milestone that touches the floor. The slip that hurts is the one nobody told you about.
Sequence the work so the system can progress without the building where it can. Design, configuration, integration testing on a development system, product data measurement at the old site: none of it needs a roof. Reserve the building for what genuinely needs it, and know exactly what that is.
Plan the readiness window against the building, not the calendar. If the readiness gate needs four weeks of the floor with racking in, power on and supervisors trained, then the racking date plus four weeks is the earliest honest go-live, whatever the opening date says. If that is later than the opening date, the conversation needs to happen now, not in the last fortnight.
The construction programme and the system programme will meet at the dock on opening day whether or not anyone planned for it. The only question is whether they arrive together.
How Luminar approaches the two clocks.
On a greenfield engagement we ask for the construction programme in the first week and we put it on the same page as the system plan. We name the milestones the floor depends on, we attend the site meetings that touch them, and we tell the sponsor in writing when the building's date and the system's date have come apart. Then we stay on the floor through the handover, because the weeks between practical completion and first dispatch are where a greenfield go-live is won.