What Belongs in an RCDD Drawing Package?
A practical package anatomy for coordinated ICT drawings, schedules, design criteria, testing, and closeout.
An RCDD drawing package is not defined by a seal, a sheet count, or a familiar title block. It is defined by whether another party can understand the design basis, coordinate the work, price it, install it, test it, and turn it over without inventing the missing decisions. The exact deliverables change with scope, but the package should make the same core questions answerable every time.
Package anatomy starts with the design basis
The first sheets should establish what the package covers and what governs it. Name the project phase, source backgrounds, owner criteria, applicable specifications, reference standards, system boundaries, alternates, assumptions, and items that still require field verification. If a PE or another licensed discipline owns part of the work, show that interface instead of allowing an RCDD sign-off to imply responsibility it does not carry.
- Cover and index: responsible parties, issue purpose, revision history, sheet list, and drawing conventions.
- Design criteria: approved inputs, codes and standards, performance requirements, scope boundaries, and open assumptions.
- Responsibility notes: design, coordination, field verification, delegated design, installation, testing, and closeout ownership.
BICSI describes the TDMM 15th edition as covering telecommunications spaces, backbone and horizontal distribution, administration, field testing, data centers, and project execution. For data-center work, ANSI/BICSI 002-2024 is the current BICSI data-center design standard. The project specification and adopted code still govern where they are more specific.
Show spaces and pathways before cable counts
A cable schedule cannot rescue an uncoordinated pathway. The package should locate entrance facilities, equipment rooms, telecom rooms, rack or cabinet footprints, working clearances, sleeves, trays, conduits, risers, and major transitions. It should also identify the electrical, structural, architectural, firestopping, and grounding interfaces that another discipline must resolve. On existing buildings, note which conditions were verified and which remain contractor verification items.
Draw topology and physical routing as two different views
The riser or one-line explains how the system is connected. Plans and enlarged room views explain where it is built. Both are necessary. A useful package keeps cable identifiers, media types, strand or pair counts, termination points, room names, equipment tags, and schedule entries consistent across those views. If the topology changes, the revision should be traceable everywhere it appears.
Make schedules answer procurement questions
Schedules should reduce ambiguity rather than repeat plan symbols. The project may need outlet, cable, backbone, rack, equipment, pathway, splice, or labeling schedules depending on scope. Each one should provide enough information to connect a symbol to a location, a performance requirement, a termination, and a test or acceptance record.
- Use stable identifiers that match the plans, risers, elevations, details, and closeout records.
- State performance and compatibility requirements without silently substituting a preferred product for the approved basis of design.
- Separate design quantities from contractor-verified quantities where existing conditions or routing can change the count.
- Tie testing and labeling requirements to the same identifiers used in the construction documents.
Data-center fiber needs a platform decision
For a data center, the fiber infrastructure is a coordinated platform rather than a strand count on a riser. The package should define the topology, distribution areas, route diversity where required, media and connector assumptions, cassette or panel strategy, polarity method, rack-unit allocation, pathway interfaces, labeling, test criteria, and growth boundary. Those decisions must coordinate with the owner network standard, equipment layout, power and cooling plan, and the project-specific application requirements; an RCDD drawing package should not guess them from a generic detail.
Closeout begins in design
A package is incomplete if acceptance appears only in a closeout specification nobody connected to the drawings. Show the submittal path, testing deliverables, labeling and administration requirements, redline process, as-built expectations, and the records the owner receives. Construction administration should preserve the same identifiers and revision trail so an RFI answer or approved substitution does not create a second undocumented design.
A fast completeness check
- Can the estimator identify every included system, major quantity, allowance, and exclusion?
- Can the coordinator find the space, pathway, power, grounding, firestopping, and structural interfaces?
- Can the installer trace each cable or device from plan to schedule to termination?
- Can the reviewer identify the governing criteria, open assumptions, and credential boundaries?
- Can the commissioning or closeout team connect test results and labels back to the issued design?
That is the practical test. The right RCDD drawing package is not the largest one. It is the smallest coordinated set that makes scope, responsibility, installation, verification, and turnover explicit for the actual project.
Principal of ICT Design Partners, a focused, remote-first ICT design, QA, and white-label practice for contractors and design firms.
About the firm