Negative float, is the Whac-a-Mole of the construction scheduler’s baseline development plan. As schedulers, we are constantly saddled with the onerous task of compressing baseline schedules to meet aggressive and often unrealistic deadlines. These projects are pre-packed with negative-float. As we develop these schedules, we notice the negative-float ticker ratchet up in various critical path activities that we must either optimize or mitigate as we build the baseline. One frequently omitted critical path sequence is systems integration.

I like to differentiate the term negative-float from slip: negative-float in the developmental stage portends slip for the project as the build-out bogs down. In other words: negative-float is measured with the forward pass, and slip realized with the backward pass. Thus, negative-float only becomes slip in real time.

It’s relatively simple for a ground-up building contractor to shape-up for mobilization, and hit the ground running with his earth equipment, and concrete and steel work. At this stage of a project, there is little in the way of conflicting program or elements to interfere with other operations, and the structure should go up (relatively) without obstruction. Such project trajectories follow the typical bell-curve. As a building goes up, the job team takes measures to recover any slip as it is realized. For traditional ground-ups, and such, the encumbrances to the schedule progress are pretty typical. For example:

• Slow production
• Design changes
• Material and fabrication delays
• Weather related delays
• Labor-disputes
• Financing or cash-flow issues

However; my experience with large infrastructure projects, such as mass transportation, plant-work, and bridges and tunnels, is that the longest-path always includes low-voltage systems integration. Given rapid advances in technology to meet demands, this trend will continue well into the future. Such projects follow an S shaped curve, as opposed to a bell-curve, i.e., they jam up in the commissioning and integration phase, at the tail-end of the project.

Systems integration refers to the phase of a project where several disparate communication systems must be coordinated. The integrators are typically contracted directly by the owner. For example in the Brooklyn Battery Tunnel, New York, there are the following low-voltage systems to consider:

• Traffic Signage Control Systems
• Tunnel Vent Control Systems
• Drainage Pump Control Systems
• Tunnel Lighting Control Systems
• CCTV Control Systems
• Lane Usage Signal Systems
• SCADA Systems
• Fire Alarm Systems

The Second Avenue Subway has similar systems to integrate. The following chart shows the complex relationships between the system’s various components.

All of these systems are dispatched by a PLC, or project logic controller, located in several remote vent and pump buildings. As they are commissioned for service, they are programmed for local control and monitoring by the respective vendors. Once local control is established, these programmers work with the systems integrator who will tie in the local systems into the fiber-optic backbone that goes between stations, and  to each of the various command centers around the City. The complexity of the Brooklyn Battery Tunnel project is exacerbated by the fact that

1. The project requires re-feeding of the entire fiber-optic control and monitoring system networks (see above) with new wire and equipment, all of which existing was scheduled for replacement before it was damaged in Hurricane Sandy.
2. The project requires temporary systems be restored until they can be replaced.
3. Constraints of tunnel traffic and tube closures limit access
4. The schedule for systems integration is not fully developed

The necessity and role of a systems integrator escapes the notice of the lay-person, and even many builders and schedulers. Systems integrators are needed whenever there is a need to coordinate various MEP control components with different communication protocols between programmable logic controllers, or PLCs. For example, Siemen’s (Profibus) and Johnson (BACnet) system components would require integration, as each manufacturer uses different protocols. In lay terms, the systems are bridged so that they may “talk to each other.” The more systems involved, the more complicated the effort will be. Following, is a table of common building automation protocols:

The trajectory for Public infrastructure projects with complicated systems integration needs, and a minimum of five-year build windows tends to follow a typical sequence

-activities almost all of which most schedulers would be hard put to establish durations and project-logic  without specific input from the integration team. As the project slips, the scheduling team makes its recovery efforts by compressing the project logic wherever it can. A year or two into the project, when there is nothing under the contractor’s control left to compress, the scheduling team will begin to pick-at the back-end of the schedule: testing and commissioning, programming, and systems integration, most of which is contracted directly by the owner.

What better place for a contractor to recover float than by reducing durations and lags in the owner’s responsibilities? actually, anywhere other than systems integration. The reason is that systems integration is often given short-shrift by scheduling teams is because a) they don’t have a comprehensive understanding of the process, or b) they have no stake in it. What I mean by short-shrift is that few schedulers can ever properly sequence and coordinate integrator work without the integrator’s input,. Few schedulers are afforded the luxury of this valuable input. If they did, they would know better than clipping the back-end of their schedules. Thus, it is common practice that a lot of broad stroke guess-work must take place, despite the lack of verification and buy-in with the systems integrator.

The downside of failure to properly incorporate systems integration sequences is evident in recently completed Public infrastructure projects, and will likely arise for years to come. At present, the LIRR East Side Access project, in New York City serves as a good example of a project that will be challenged in the integration phase: it will be a considerable undertaking to integrate Metro North, Subway, Long Island Railroad, Amtrak signals (Harold Structure, Queens), and a smattering of other communications networks into the system backbone: a veritable Tower of Babel. There are only a handful of the best systems integrators who can coordinate such complex networks, and they seem to be spread pretty thin. These circumstances present a great risk to the completion milestone of that project.

A dark-horse – you might say, is the constant evolving Internet of things (IoT) technology that produces cutting-edge equipment and systems every day, necessitating a learning curve that translates to a lag in implementation, or what I like to call “tech-lag.” For example, by the time a project is ready for control systems, the specified equipment and systems – conceived years heretofore, may be obsolescent. Many signal systems still use old copper wire for transmission – wire that is subject to fracture, and that is considerably slower than fiber-optic. This is a quandary for design engineers, and is a difficult problem to negotiate. The establishment of standard protocols and fiber-optic networks backbones facilitates such rapid advances in information technology for signal transmission, but it also makes the world of systems integration bigger, and more complex.

As a due diligent scheduler, I insist on full disclosure for all program elements in my schedule, especially those which I am uncertain of. This includes the elusive integrator’s schedule. An integrator can advise – not so much as to a schedule proper, but as to the project logic and durations required for his design deliverables. I have occasionally worked with an integrator’s schedule plan, which describes the various testing and programming sequences necessary to bring multiple networks on-line, and integrate them, but this is the exception.

One such document was some seventy-five typed pages, had no GANTT chants, yet it allowed me to properly sequence the integration work in a general sense, and forecast that a proposed mitigation schedule was not allowing nearly enough time for the integration. Yet without the integrator’s verification of a schedule, I cannot guarantee their effort and representation in the schedule. Since their work is always in the longest-path, I consider not being enlightened somewhat of a handicap. However; like any other trade, a scheduler must be knowledgeable in the basic process of systems integration, such that he can create the proper place in his timeline for the work.