Show Notes
Why project closeout often becomes an operations problem
A new system can pass a demo, get signed off, and still fail the people who have to live with it the next morning. In this episode of Built, Wired & Secured, Alex Morgan talks with Michael Harrington and James Rogers about one of the most common breakdowns in commercial buildings: the handoff from project delivery to day-to-day operations.
The conversation opens with a vivid example: a new access control rollout goes live on Monday, and by Tuesday morning the front desk cannot badge anyone in. Tenants are delayed, the receptionist is overwhelmed, and the vendor insists the system was tested. That gap between a successful project milestone and an unusable operating environment is the core issue this episode addresses.
The team makes a simple but important point: handoff is not a paperwork exercise. If ownership, credentials, recovery steps, and spares are unclear, minor problems escalate into full outages. The project may be technically complete, but the building is not operationally ready.
The first failure point: unclear ownership
Michael explains that the first place to look after a turnover-related incident is ownership. Too many handoffs are treated like a final checkbox: the demo is done, the signoff is collected, and the invoice gets paid. But operations still needs answers to basic questions:
- Who owns the credentials?
- Who has the firmware image?
- Who answers the phone at 2 a.m.?
- Who is the named escalation contact?
Without those answers, teams lose precious time during an incident. What should have been a quick recovery turns into a building-wide disruption. This is especially important in occupied environments where tenant continuity matters more than whether a contractor considers the project closed.
The second failure point: documentation nobody can use
James adds that documentation quality matters just as much as ownership. Not because teams need more files, but because they need useful artifacts. A folder full of PDFs is not the same as operational documentation.
According to the episode, usable handoff documentation should include:
- Labeled wiring diagrams
- A plain-language sequence of operations
- A one-page recovery flow
- A short list of critical spares
The standard is practical: if the documentation reads like an engineer’s lab notebook, crews will not use it under pressure. Under real operating conditions, teams need concise instructions they can trust quickly.
Why vendor demos are not enough
One of the strongest sections of the episode focuses on testing. The guests argue that vendor demos show capability in a controlled environment, but they do not prove operational readiness. Operators need to test the system in the real environment, with real workflows and real failure scenarios.
Instead of accepting a polished walkthrough, operations teams should insist on tests that answer harder questions:
- What breaks if this system goes down?
- Can operators perform routine tasks themselves?
- What happens during failover?
- How long does recovery actually take?
The point is not to create friction for vendors. It is to confirm the building can recover when something goes wrong.
A practical 30-minute operator acceptance test
The episode offers a useful template for a short operator-led test window. In just 30 minutes, teams can validate far more than a standard demo:
- Have the operator log in and perform routine tasks
- Run one failover scenario, such as a controller reboot
- Exercise one recovery step, such as a credential reset
- Time each step
This matters because timed recovery reveals whether the handoff is real or cosmetic. As Michael says, if the vendor cannot support that level of testing in the contract, the buyer has purchased a demo, not operational certainty.
Small spare kits can prevent long outages
Another practical takeaway is the importance of a labeled spare kit. The guests argue that a small bin with two or three critical spares can save far more time than waiting for overnight shipping after a failure.
The recommended starter kit includes:
- A spare controller
- A serial adapter or serial cable
- The matching firmware image
- A printed one-page recovery guide
This is not about overinvesting in inventory. It is about removing predictable delays from incident response. When the right spare is on the shelf and the recovery flow is taped to the panel, mean-time-to-repair drops fast.
How to keep handoff requirements from becoming “scope creep”
The episode also addresses a common objection: won’t vendors push back on acceptance testing and spare delivery? The answer is yes, unless expectations are defined early and objectively.
The guests recommend making tests contractual. That means:
- Defining acceptance criteria upfront
- Including those criteria in the contract
- Making final payment conditional on operator-signed acceptance
That structure does two things. It prevents surprises for the vendor, and it protects the owner or operator from inheriting an unproven system.
Two real-world examples with low-cost fixes
The episode includes two strong examples of inexpensive changes that delivered meaningful results.
In one multi-tenant office, BAS sequences had been updated, but the first winter evening setback failed to restore properly and tenants were left cold. The response was simple: a two-hour operator walkthrough, a one-page failback procedure taped to the BAS panel, and a labeled spare controller on the shelf. Emergency calls dropped by about 80 percent the following season.
In another case, a camera rollout had no documented key hierarchy. After a power event, nobody knew the break-glass account, and recorded footage was inaccessible for days. The team then required an encrypted credential vault handoff and a documented reset path. On the next rollout with the same vendor, they had zero credential incidents.
Both stories reinforce the same lesson: low-cost operational discipline often matters more than expensive technical complexity.
The compact handoff playbook
By the end of the episode, the team distills the discussion into a compact playbook built around three non-negotiables:
- A turnover checklist tied to acceptance criteria, named owners, credential handoff, spare list, and escalation contacts
- Acceptance testing led by operations, including failure simulations and timed recoveries
- A spare and firmware handover with actual firmware images, support account access, and at least one labeled spare critical component
To keep it usable, they recommend a one-page checklist, a five-minute orientation for shift crews, two vendor contacts, three spares on the shelf, and a one-page recovery flow taped to the panel. Then, schedule a 30-day follow-up to catch issues that only surface under real load.
The Monday action item
If you only do one thing this week, the guests suggest asking for one clarifying item from your most recent closeout: a named operations lead and an emergency credential reset procedure. If you cannot get that within a day, escalate.
Then build the spare kit. Put the labeled bin in the storeroom, include the spare controller, serial cable, firmware file on a USB, and the one-page recovery flow, and make sure the team knows where it is.
This episode is a practical reminder that reliable buildings do not come from project completion alone. They come from disciplined turnover that makes systems operable, supportable, and recoverable in the real world.
The real test starts after go-live
In commercial buildings, the formal end of a project is often treated like success. The system was installed, the vendor ran the demo, the team signed off, and the invoice moved through. On paper, everything looks finished.
But operations teams know the real test begins the next morning.
That is the central message from this episode of Built, Wired & Secured, where Alex Morgan speaks with Michael Harrington and James Rogers about the handoff from project delivery to ongoing operations. The discussion centers on a familiar and expensive pattern: a building system goes live, only for frontline staff and operators to discover that the environment is not actually ready to run.
The opening example makes the issue concrete. A new access control rollout goes live on Monday. By Tuesday morning, the front desk cannot badge anyone in. Tenants are delayed, calls are coming in, and the vendor says the system was tested. From a project perspective, that sounds like a frustrating snag. From an operations perspective, it exposes a broken turnover process.
The lesson is clear: a completed project is not the same thing as an operable building.
Why turnover failures keep happening
One of the most useful parts of the episode is how directly it identifies the root causes. These failures do not happen only because technology is complex. They happen because ownership is vague, incentives are misaligned, and documentation is designed for closeout rather than recovery.
Michael argues that the first thing to inspect after a turnover incident is ownership. Too often, handoff is treated like a checkbox at the end of a project. The demo is complete. The signoff is collected. Payment is released. But key operational questions remain unanswered:
- Who holds the credentials?
- Who has the correct firmware image?
- Who is responsible at 2 a.m.?
- What is the escalation path if the system fails under load?
When those questions have no named owner, a small issue becomes a service disruption. In multi-tenant environments, that means more than technical inconvenience. It can disrupt access, tenant comfort, security visibility, and response times across the property.
James adds a second root cause: documentation that exists but is not usable. This distinction matters. Many projects do produce handoff files, but those files often fail the stress test of real operations. A stack of PDFs is not enough if the shift crew cannot quickly find the reset path, follow the recovery steps, or identify which spare to swap in.
The episode outlines what useful documentation should look like in practice:
- Labeled wiring diagrams
- Plain-language sequence of operations
- A one-page recovery flow
- A short list of critical spares
That emphasis on usability is important. Documentation is not there to prove the project happened. It is there to help someone restore service quickly when conditions are messy and time matters.
Capability is not the same as recoverability
The conversation also challenges a common assumption in project closeout: that a vendor demo proves readiness. It does not.
Vendor demos are useful because they show that the system can perform its intended functions in a controlled setting. But operations does not happen in controlled settings. It happens during shift changes, power events, reboot scenarios, account issues, and real-world failures.
That is why the guests insist that operator acceptance testing must go beyond demonstrations. Operators need to test routine use, simulate at least one failure, and verify one real recovery action. They also need to time how long recovery takes.
This is one of the strongest practical insights in the episode. Timed recovery changes the conversation. A system that technically recovers in theory may still be unacceptable if the process is too slow, too unclear, or too dependent on a single vendor contact. Recovery needs to be operationally feasible, not merely technically possible.
A compact acceptance test teams can use right away
The episode offers a realistic model for short operator-led testing. In a 30-minute window, a team can do three high-value things:
- Have the operator log in and perform routine tasks
- Run one failover scenario, such as a controller reboot
- Exercise one recovery action, such as a credential reset
Each step should be timed.
This approach is simple, but it changes accountability. It moves testing from “the vendor showed us it works” to “the operator proved they can run and recover it.” That difference is where many turnover problems are either prevented or exposed early enough to fix.
And as the guests point out, if the vendor cannot support this kind of test as part of the contract, the buyer may be getting a completed installation without the operational certainty the building actually needs.
The business case for spares and recovery kits
Another valuable theme in the episode is the role of spares. In many organizations, spare parts are treated as optional extras that can be deferred. The guests make the opposite case: a small, targeted spare kit is one of the cheapest ways to reduce downtime.
The recommended kit is intentionally modest:
- A spare controller
- A serial adapter or serial cable
- The matching firmware image
- A printed one-page recovery guide
That matters because many early-life failures do not require a major intervention. They require the right part, the right file, and a clear recovery path immediately available to the team on site.
From a business standpoint, this is exactly the kind of low-cost readiness measure that protects tenant continuity and reduces after-hours escalation. A labeled spare bin in the storeroom can be far more valuable than a theoretical next-day shipping promise when a building system fails during active operations.
Make accountability part of the contract
One of the objections raised in the discussion is predictable: won’t vendors view acceptance testing and spare delivery as scope creep?
The answer in the episode is practical and balanced. These requirements only become a surprise if they are introduced late. If they are defined upfront as objective acceptance criteria, they become part of the scope, part of pricing, and part of delivery expectations.
The guests recommend three contract-level protections:
- Define targeted acceptance criteria before work begins
- Include operator testing expectations in the contract
- Make final payment conditional on operator-signed acceptance
This is not about being adversarial. It is about aligning incentives so the delivered system is not only installed but operable. Contracts establish the test. Operations validates usability.
Two examples that show how small fixes drive big results
The episode’s examples make the discussion especially useful.
In one multi-tenant office, updated BAS sequences failed during the first winter evening setback, leaving tenants cold when the system did not restore properly. The corrective actions were not expensive: a two-hour operator walkthrough, a one-page failback procedure taped to the BAS panel, and a labeled spare controller on the shelf. The result was significant. Emergency calls dropped by about 80 percent the following season.
In another example, a camera rollout lacked a documented key hierarchy. After a power event, no one knew the break-glass account, and recorded footage was inaccessible for days. The response was to require an encrypted credential vault handoff and a documented reset path. With the same vendor on the next rollout, credential incidents dropped to zero.
These stories matter because they reinforce a larger principle: operational resilience usually improves through disciplined basics, not just more technology.
A practical handoff playbook for building teams
By the end of the episode, the guests condense their recommendations into a short handoff playbook every property and facilities team can adapt:
- Create a turnover checklist tied to acceptance criteria
- Name operations owners and escalation contacts
- Require credential handoff and support account access
- Run operator-led acceptance tests with failure simulation
- Time recovery steps
- Deliver actual firmware images and at least one labeled critical spare
- Provide a one-page recovery flow taped at the panel
- Schedule a 30-day reconvening under real load
That last step is especially smart. Issues that remain invisible during closeout often appear after several weeks of real usage. A 30-day follow-up creates a structured moment to catch and correct those gaps before they become recurring incidents.
The Monday move
If your team wants to reduce risk immediately, the episode recommends one straightforward action: ask for a named operations lead and an emergency credential reset procedure from your most recent closeout. If you do not get it within a day, escalate.
Then build the spare kit, label it clearly, and tell the team where it is.
That advice captures the broader theme of the episode. Better outcomes do not always require a major capital plan. Often, they begin with small operational decisions made early enough to matter.
If your organization is delivering or inheriting building systems this year, this episode is a strong reminder that turnover is where long-term reliability is either built in or quietly lost. The best projects do more than go live. They leave operations ready to run, recover, and support the building with confidence.
For teams looking to improve uptime, reduce avoidable incidents, and make new systems stick after handoff, this is worth a listen.