Project Administration, Risk & Closeout

Risk Management Throughout the Project

Project administration is the RCDD's continuous oversight of scope, cost, schedule, and quality risk from award through closeout — distinct from, but built on, the scope and cost estimates established in Section 11.1. Risk management is not a single event; it is an ongoing practice of identifying conditions that could disrupt the project (long-lead equipment delays, utility coordination failures, unforeseen field conditions, design conflicts discovered during installation) and tracking mitigation before those risks become active problems. A disciplined RCDD maintains visibility into open risks throughout construction rather than discovering them only when they cause a delay or cost impact.

Common ICT project risks include long-lead specialty equipment slipping past its promised delivery window, a utility or AHJ approval taking longer than scheduled, a site survey that missed a condition later discovered during demolition, and design conflicts between disciplines (electrical, mechanical, structural) that only surface once trades are actually working in the same space. Tracking each identified risk with a likelihood, an impact, and an assigned owner — even informally — keeps risk management from being a reactive exercise that only starts once a problem has already affected cost or schedule.

Change Orders

When actual conditions, owner requests, or design corrections require work that differs from the original contract scope, that difference must be formalized as a change order — a documented, priced, and mutually approved modification to the contract. A change order typically includes:

The RCDD's role is to evaluate whether a proposed change is genuinely required (a field condition, code requirement, or owner-directed scope change) versus a contractor attempting to recover cost for work that should have been included in the original bid. Just as important: installing changed work before a change order is approved is a common and expensive project-administration failure — it leaves the RCDD and owner with no contractual basis to dispute cost or responsibility if the change turns out to be unnecessary or improperly executed.

Record (As-Built) Documentation

Record documentation — commonly called as-built documentation — captures the ICT system as it was actually installed, which is rarely identical to the original design documents once field conditions, approved substitutions, and change orders are accounted for. As-built documentation typically updates:

• Pathway and cable routing, reflecting any field-directed rerouting.
• Space and equipment layouts, reflecting any relocated racks, cabinets, or telecommunications spaces.
• Labeling and administration records (per the identification scheme discussed in Chapter 2), so every cable, port, and space is documented exactly as labeled in the field.
• Test results for every installed link — copper and fiber — tied to the as-built labeling.

Accurate as-built documentation is arguably the single most valuable deliverable an owner receives at project closeout: it is what every future technician, facilities manager, or RCDD relies on for moves, adds, changes, and troubleshooting for the operational life of the system. Record documentation built from assumptions rather than verified field conditions is a liability the owner will discover — expensively — the first time it's relied on.

Final QA and Commissioning

Final quality assurance confirms that the completed installation meets the specified design and performance requirements before the owner accepts the work. This includes reviewing field test results (permanent link/channel test data per Chapter 9) against the specified pass/fail criteria, confirming labeling and administration records match the as-built condition, and walking the completed installation against the punch list generated during ongoing inspections (Section 11.3). Commissioning — where applicable, particularly for data centers and intelligent building systems — verifies that installed systems function together as an integrated whole, not just that individual components pass isolated tests. Final QA is the gate between "installed" and "accepted" — an owner should not take beneficial occupancy of a system that has not demonstrably passed its specified acceptance criteria.

Warranty and Project Handover

Project closeout concludes with project handover — the formal transfer of the completed system, and the knowledge needed to operate it, from the design/construction team to the owner. A complete handover package typically includes:

1. Final as-built/record documentation.
2. Complete test result records for every installed link.
3. Warranty documentation — both the installing contractor's workmanship warranty and any manufacturer's system warranty tied to using a certified installer and approved components.
4. Operations and maintenance information, and, where applicable, owner training on the installed system.

The RCDD's involvement in handover protects the owner's warranty eligibility: manufacturer system warranties are frequently contingent on using specified, compatible components installed and tested by a certified installer, and a break in that chain — an unapproved substitution, a missed test, incomplete documentation — can void coverage the owner believes they have. A properly closed-out project leaves the owner with a system that performs as designed, is documented as actually built, and is protected by warranty coverage the owner can actually rely on.