11.3 Systems Integration, Scheduling, Cost Estimation & Value Engineering
Key Takeaways
- Integration is shared identity, events, and workflows among ACS, VSS, IDS, HR, fire, elevator, and parking—not shared wall space.
- Rough-in of raceway and cable must finish before wall close-in; trim, programming, integration test, and training follow with finish-to-start logic.
- Gantt bars communicate calendar overlap; PERT-style networks, milestones, float, and predecessor types communicate why a bar cannot move.
- Cost estimates should match design freeze: unit-count ranges at programming, schedule-based takeoffs at construction documents.
- Responsible value engineering preserves detection and assessment performance; deleting sensors or retention to hit a number is residual-risk transfer, not value.
A camera next to a card reader is not an integrated system. Systems integration is the designed exchange of identity, events, and control among ACS, VSS, IDS, and the non-security systems that actually run the building. Domain 2 pairs that idea with the project-management skills that get the work installed: scheduling logic, cost estimation, and value engineering (VE) that does not secretly delete detection.
What integration actually is
True integration is a documented set of interfaces, each with a responsible contractor, a protocol or contact, a fail-safe or fail-secure behavior, and a test.
- ACS and VSS. An invalid card, door held open, or forced door pops the associated camera on the operator’s map and bookmarks the video. Pan-tilt-zoom presets, if used, supplement fixed coverage; they do not replace a camera that can actually see the portal when the operator is busy.
- ACS and IDS. Arming states follow occupancy and time schedules. A valid entry can shunt a delay zone. A forced door is both an ACS alarm and an IDS event with one operator workflow, not two siloed queues.
- ACS and HR/identity. Hire, transfer, and termination in the HR system drive credential entitlement. The security system should not be a second, stale employee database that still opens the data center two weeks after someone is fired.
- ACS and fire alarm. Magnetic locks and electromagnetic delayed-egress devices release on fire alarm as required by the adopted life-safety code. This is a supervised interface designed with the fire protection engineer, not a jumper the access-control vendor “usually adds.”
- ACS and elevator. Public-floor recall versus card-controlled floors, firefighter service remaining under the elevator code, and video at the cab or lobby as specified. A reader slapped on a hall call button without the elevator contractor is not an elevator interface.
- ACS and parking. Credential or license-plate recognition at the barrier, occupancy counts, and exception handling for tailgating, nested lots, and after-hours nested credentials.
| Interface | What “integrated” looks like | What “same wall” looks like |
|---|---|---|
| ACS + VSS | Alarm opens the camera, bookmarks video, shared maps | Two panels sharing plywood and a power strip |
| ACS + IDS | One arming state, one forced-door workflow | Separate keypads that happen to sit in the same closet |
| ACS + HR | Entitlements follow hire and termination events | Security re-keys spreadsheets once a quarter |
| ACS + fire | Supervised maglock release tested with the fire contractor | A unlabeled relay “for later” |
| ACS + elevator | Floor security under elevator code, jointly tested | Reader on the jamb, no traveling-cable plan |
| ACS + parking | Credential or LPR logic, nested access, exception handling | A pedestal next to a camera with no event tie |
Colocation—“we put them on the same wall”—is rack hygiene. It can even be good practice for service loops and lockout/tagout. It does not create a shared identity store, a common event taxonomy, or a tested failover. If the video platform and the access platform cannot exchange an event without a human looking at two screens, write “not integrated” in the basis of design and staff the operations center accordingly.
Integration also has a cyber and availability cost. Each API, each vendor, each shared virtual LAN is an attack surface and a change-control problem. Specify authentication, network segmentation, and time synchronization so a video bookmark matches the door event to the second. Decide who patches firmware. Dry contacts, supervised loops, Open Supervised Device Protocol at the reader, and vendor APIs are all valid methods; the exam cares whether the method was designed and tested, not whether the boxes share plywood.
Project-management concepts the designer still owns
Even when a construction manager runs the job, the security designer owns scope definition, interface responsibility, and acceptance criteria. Classic constraints still apply: scope, schedule, cost, quality, risk, and stakeholder communication. Security projects add special risks: long-lead controllers, manufacturer firmware that is not yet compatible, union jurisdiction over cable, and an opening date that does not care that the HR feed is late.
A work breakdown structure that stops at “install security” will be bid as a lump of mystery. Break work into raceway, cabling, devices, head-end, programming, integration testing, training, and closeout. Assign each interface (fire, elevator, parking, HR) to a named contractor in the specifications so the gap does not become someone else’s problem. A simple responsibility matrix—who provides, who installs, who programs, who tests—prevents the “I thought Division 26 brought the drop” meeting that happens the week of opening.
Scheduling: Gantt, PERT, milestones, float, predecessors
Gantt charts plot activities as bars on a calendar. They are excellent for communicating overlap (rough-in while drywall is still open) and terrible if they hide logic (why trim cannot start).
PERT (Program Evaluation and Review Technique) models a network of dependent activities, historically with optimistic, most-likely, and pessimistic durations. You will not run a full PERT simulation in a multiple-choice item, but you should recognize that uncertain long-lead equipment—a crash-rated barrier, custom millwork for a screening lobby—belongs on a network, not on a wish. The critical path is the chain with zero (or least) total float; slip it and the finish date moves.
Milestones are zero-duration events: notice to proceed, walls closed, permanent power, beneficial occupancy, certificate of occupancy, and security beneficial use (the night operators actually take alarms).
Float (slack) is the time an activity can slip without moving the project finish (total float) or without moving the next activity (free float). Consuming all the float on programming to wait for a late HR file means training happens the morning of opening—an operations failure dressed as a schedule success. Float is not permission to skip tests.
Predecessor logic is how activities actually connect:
- Finish-to-start (FS): B cannot start until A finishes. Cable test before device trim is a common FS.
- Start-to-start (SS): B can start after A starts. Camera aiming can start when a portion of mounting is done.
- Finish-to-finish (FF): B cannot finish until A finishes. Programming cannot be declared complete until the HR feed is live.
- Start-to-finish (SF): rare; know that it exists so you are not tricked.
Fast-tracking overlaps design and construction (risky for security rough-in if walls close before device plans exist). Crashing adds resources to shorten duration. Neither is a synonym for deleting IDS zones.
A small security project network
Imagine an interior fit-out: 40 card readers, 60 cameras, IDS on the shell, integration to the existing video platform, and a two-hour operator class.
| ID | Activity | Duration | Predecessor | Notes |
|---|---|---|---|---|
| A | Rough-in: backboxes, conduit, cable | 15 days | Walls framed (external) | Must finish before drywall close-in |
| B | Head-end racks, power, network | 8 days | SS with A after IT room available | Permanent power is a milestone |
| C | Trim: devices, door hardware coordination | 10 days | A complete; hardware on site | Door hang is a predecessor from Division 08 |
| D | Programming: maps, rules, HR feed | 7 days | B and C far enough for controllers to poll | HR file is an external predecessor |
| E | Integration test: ACS, VSS, IDS, fire | 3 days | D | Includes maglock release test with fire contractor |
| F | Training and turnover | 2 days | E | Extra materials and as-builts due |
If drywall closes before A is done, cameras become demolition. If F is scheduled on opening day, operators have never seen a false alarm. The critical path on a job like this often runs rough-in → trim → programming → integration test → training. Head-end work can overlap rough-in (start-to-start) once the room and power exist. Training has little free float unless testing finishes early—do not advertise that float to the owner as “we can skip testing.”
Cost estimation
Estimate at the level of design freeze you actually have. A programming-phase number is a range based on door and camera counts times unit costs, plus head-end, software, and a healthy contingency. Schematic estimates add room-by-room takeoffs. Design-development and construction-document estimates use schedules and specified stock-keeping units. Calling a construction-document-level number at programming is theater.
Line items to remember: devices, licensing (often the surprise), servers and storage, network electronics if security-provided, lock power, raceway (or a Division 26 allowance), lifts for high cameras, after-hours labor, commissioning, spare parts, warranty years, and owner training. Soft costs—design fees, project management, independent testing—belong in the owner’s budget even if they are not in the construction bid. Lifecycle cost includes refresh of cameras, servers, credentials, and licenses; a cheap first cost that forces a forklift upgrade in year three is not a bargain.
Value engineering that does not delete detection
Value engineering is a structured look at function versus cost. Legitimate VE substitutes a product that still meets the specified detection and assessment performance, reuses spare strands in existing fiber, relocates a head-end to avoid a new IDF, or phases a low-risk interior zone while keeping shell detection intact. Illegitimate VE is a budget haircut that removes cameras below the coverage worksheet, replaces dual-technology IDS with an unqualified PIR, cuts retention from 90 days to 7, or installs “temporary” delayed-egress hardware that never comes back.
Bring the coverage and power calculations to the VE meeting. If the owner accepts less detection, write the residual risk into the record and get a signature—do not hide the loss inside a brighter marketing camera. If a contractor proposes a substitute, run it through the same Part 2 criteria you used against “or equal.” VE is not a synonym for cheaper, and cheaper is not a synonym for integrated.
Read every arrow as a tested interface, then overlay the schedule: those arrows cannot be proven until rough-in and trim exist, programming has maps and rules, and the fire, elevator, parking, and HR counterparts are at the job. A Gantt bar labeled “integration” that starts the same week as conduit is fiction. Cost the interfaces as work (API licenses, supervised relays, joint tests, after-hours fire tests). When VE later proposes to “save the integration line,” ask which arrow is being cut—because dropping the HR feed or the fire-release test is not a value improvement. It is a different, weaker system.
Which statement correctly distinguishes systems integration from hardware colocation?
For an interior electronic security installation, which sequence correctly applies finish-to-start predecessor logic?
Which value-engineering action preserves the intent of a physical security design?