Show Notes
Why early move-in issues turn into long-term operational drag
Move-in day rarely tells the full story. In this episode of Built, Wired & Secured, Alex Morgan sits down with Michael Harrington to unpack what happens in the first 30, 60, and 90 days after handover, when seemingly minor issues can become recurring tenant complaints, vendor disputes, and unplanned cost conversations. The episode opens with a realistic scenario: flickering conference room lights, HVAC cycling erratically, and nuisance fire alarm inputs all tied to infrastructure decisions that were never fully reversed or documented after installation and testing.
The central message is straightforward: early operational failures are rarely random. They usually trace back to visibility gaps, weak ownership, temporary configurations left in place, or missing evidence at handover. Rather than treating those issues as isolated service tickets, the episode presents a governance-first playbook that property and facilities teams can use to stabilize operations before defects become expensive.
The most common post-handover failure patterns
Michael explains that the same categories of issues tend to resurface across buildings and projects. These are not always major design failures. Often, they are small operational loose ends that only become obvious once tenants begin using the space normally.
- Credential sprawl, including multiple logins, orphaned accounts, and devices left in commissioning mode
- Orphaned PoE devices, such as access panels or PoE lighting, that get moved or repurposed without clear documentation
- Monitoring blind spots, where systems are not tied into the right alerting path and failures remain invisible until a tenant reports them
- Temporary test configurations, including VLAN settings and installation shortcuts, that remain in production longer than intended
One anonymized example ties directly to the episode’s opening vignette. On a midrise project, PoE lighting had been routed through a vendor switch during installation, with some ports left in a default VLAN for testing. Later, when HVAC controls were connected, a mistagged port caused cross talk and false fire inputs. The result was a stream of nuisance alarms and weeks of troubleshooting. The problem was not just the technical fault itself. It was the lack of documented evidence showing what had been placed into test mode, what had been reversed, and who owned validation at handover.
The 30-day goal: establish a stability baseline
Day 30 is about proving that critical systems are functioning under normal business conditions. Michael emphasizes that teams should not overcomplicate the process. Instead, they should focus on a simple evidence standard built around three items:
- A one-page stability log
- A short vendor attestation confirming temporary configurations were removed
- A tenant walkthrough sign-off for primary spaces
The stability log is designed to be concise and auditable. Each line should identify the system, the monitored metric, the observation window, and a pass/fail result or anomaly count. Every line should be backed by timestamped screenshots or exported log snippets. The point is not storytelling. The point is evidence.
Examples mentioned in the episode include tracking PoE lighting power draw variance over 14 days or HVAC supply temperature variance over the same period. If a team cannot produce this level of documentation by day 30, the episode argues they do not yet have real operational confidence.
The 60-day goal: prioritize remediation and manage temporary fixes
By day 60, teams should shift from basic observation to structured prioritization. The baseline created in the first 30 days becomes the input for a remediation register that organizes what needs to happen next.
That register should include:
- A short description of each issue
- Its impact on tenant operations
- An estimated level of effort
- A clear owner for next action
- Any temporary mitigation currently in place
This is one of the episode’s most useful points. Temporary mitigations are acceptable if they are intentional, documented, and time-bounded. Michael gives a practical example: if replacing flaky sensor wiring requires intrusive ceiling work, a team might use a redundant sensor circuit or adjust alert thresholds temporarily to reduce false alarms. What matters is documenting who owns that mitigation and how long it is acceptable before a permanent fix is required.
Without that discipline, short-term workarounds have a way of becoming unowned operating conditions that tenants ultimately feel.
The 90-day goal: operational sign-off with evidence
At day 90, the objective is formal operational readiness. The property team should be able to state, with evidence, that systems are stable enough for normal business operations.
The expected deliverables are:
- The final stability log
- A remediation register showing completed actions and funded items queued
- An updated O&M manual with known exceptions clearly identified
- A short acceptance memo from the operations lead
That memo matters because it marks the transition from project handover into day-to-day operational responsibility. It also separates what operations is accepting now from what still belongs in capital planning or funded remediation. That distinction helps prevent repeated confusion over whether a recurring issue is just a service nuisance or a budgeted building problem.
The remediation ladder: preserve relationships while making defects fundable
A major theme in the episode is that escalation does not need to damage vendor relationships. Teams often avoid raising issues because they fear turning a service correction into a conflict. Michael reframes this with a simple, relationship-aware remediation ladder: start with factual evidence, request correction inside a clear time box, and if the fix cannot be completed, require a documented temporary mitigation and a cost path for owner review.
The example email language is intentionally plain and useful. It references the day 30 stability log, cites repeated resets in a defined building and zone, attaches timestamped logs and vendor attestation, and requests warranty remediation within 14 calendar days. If the timeline cannot be met, the vendor is asked to provide a temporary mitigation plan and an estimated cost for approval.
That structure works because it keeps the conversation grounded in observable evidence, timelines, and business impact rather than blame.
Why this playbook matters
The episode makes a practical business case for disciplined stabilization. Quick undocumented fixes may feel cheaper in the moment, but they often move cost into operations and delay the point at which owners can properly fund a real solution. Tenants do not care whose budget owns the problem. They care whether the building works reliably.
Listeners leave with three immediate actions:
- Create a one-page stability log template and populate it with seven days of alerts for critical systems
- Open remediation register entries for the top two recurring tickets, with owners and temporary mitigations assigned
- Send the first remediation request email for any item that meets the evidence standard, with logs attached and a 14-day remediation window
The episode closes with a reminder to prioritize by asking one simple question: what breaks if this goes down? That question helps property teams decide what belongs on the stability log, what should be escalated first, and where early governance can prevent months of operational friction later.
Stop treating post-move-in issues like isolated tickets
Most move-in problems do not announce themselves as major building failures. They appear as ordinary nuisance tickets. A conference room light flickers. HVAC starts cycling strangely. A fire alarm panel shows an intermittent input that nobody can immediately explain. Someone resets a device, calls a vendor, or reroutes the complaint, and for a moment the issue seems contained. Then it comes back next week. Then again the week after. What started as a small operational annoyance becomes a recurring tenant frustration, a drain on staff time, and eventually a budget question.
That is the problem addressed in this episode of Built, Wired & Secured. Alex Morgan speaks with Michael Harrington about a governance-first 30/60/90 stabilization playbook that property and facilities teams can run after handover to reduce repeat failures, clarify ownership, and create the evidence needed to get defects corrected before they become long-term operational drag.
The conversation is especially relevant for commercial property teams managing environments where building systems increasingly interact. Lighting, HVAC, fire alarm inputs, access control, and monitoring are no longer isolated domains. Temporary installation choices, partial documentation, and weak operational acceptance standards can create failure chains that are hard to see until tenants begin using the space in normal conditions.
Why early failures keep recurring
One of the clearest themes in the episode is that most early operational problems are not purely technical mysteries. They are documentation and ownership problems first. Michael identifies a few recurring patterns that tend to show up after move-in.
The first is credential sprawl. Multiple logins, orphaned accounts, and systems left in commissioning mode create confusion about who can access what and whether devices are actually configured for steady-state operations. The second is orphaned PoE-connected equipment. Access panels, lighting devices, and other powered endpoints often get moved, repurposed, or patched temporarily during installation. If those changes are not documented clearly, later troubleshooting starts from incomplete information. The third pattern is monitoring blind spots. Systems may technically function, but if they are not connected to the correct alerting path, operations does not learn about failures until a tenant is affected.
These patterns matter because they turn short-term project decisions into long-term operating conditions. A test VLAN that was acceptable during installation is dangerous if nobody confirms it was removed. A temporary device setting that helped a vendor finish commissioning becomes a liability if it remains in production unnoticed.
The episode’s example shows how small gaps create bigger consequences
The transcript includes an anonymized case that captures this perfectly. On one midrise project, PoE lighting was routed through a vendor switch during installation, and some switch ports were left in a default VLAN for testing. Later, HVAC controls were connected, and a mistagged port created cross talk that led to false fire inputs. Tenants experienced nuisance alarms, and the issue took weeks to trace.
The technical details matter, but the larger lesson matters more. The building did not fail because complex infrastructure is inherently unmanageable. It failed because the initial handover did not establish clear evidence around test modes, temporary VLANs, and responsibility for confirming that temporary configurations had been reversed. In other words, the operational team inherited risk without inheriting enough proof.
That is why the playbook presented in the episode is built around evidence, not just observation. Teams do not need perfect systems on day one. They need a repeatable way to prove what is stable, identify what is not, and escalate defects before operational cost multiplies.
Day 30: build a stability baseline
The first checkpoint in the playbook is day 30. The goal here is not exhaustive documentation. It is a practical stability baseline that confirms whether critical systems are functioning under normal use.
Michael reduces the standard to three items. First, create a one-page stability log. Second, collect a short vendor attestation stating that temporary configurations were removed. Third, complete a tenant walkthrough sign-off for the primary occupied spaces. If those three items are missing, the team lacks a defensible operational baseline.
The one-page stability log is intentionally simple. For each critical system, list the monitored metric, the observation window, and either a pass/fail result or anomaly count. Then attach a timestamped screenshot or exported log snippet. A line item might track PoE lighting power draw variance over 14 days and note two unexpected resets. Another might track HVAC supply temperature variance over the same period and note zero incidents. The point is not to produce a narrative report. The point is to create evidence that can be reviewed quickly and audited later.
This matters because early post-move-in conversations often get bogged down in memory, opinion, or incomplete anecdotes. A stability log replaces that with traceable facts.
Day 60: separate urgent remediation from temporary mitigation
At day 60, the focus shifts from proving current conditions to organizing response. The baseline built during the first month should now feed a prioritized remediation register.
That register should describe each issue briefly, explain its impact on tenant operations, identify an owner, estimate the level of effort, and record any temporary mitigation currently in use. This is where the episode becomes especially practical. Not every defect can be fixed immediately. Some problems require invasive work, procurement lead time, or capital approval. But that does not justify vague status tracking or indefinite workarounds.
Michael gives a non-technical example that most operators will recognize. If a flaky sensor connection requires ceiling demolition to fix properly, a temporary mitigation might involve adding a redundant sensor circuit or adjusting alert thresholds to reduce false alarms while the permanent work is planned. That is acceptable only if the mitigation is documented, assigned to an owner, and given a time boundary.
Without that discipline, operations teams end up carrying invisible risk. Tenants continue to work around symptoms while ownership remains unclear and the eventual repair becomes more politically and financially difficult.
Day 90: operational sign-off should mean something
By day 90, the team should be ready for operational sign-off. In the episode, that means more than saying things seem calm. It means the property team can point to concrete deliverables that show systems are stable enough for business operations.
Those deliverables include the final stability log, a remediation register showing completed actions and funded items queued, an updated O&M manual with known exceptions called out, and a short acceptance memo from the operations lead. That memo functions as the baton pass. It signals that operations is accepting day-to-day responsibility while also preserving visibility into issues that still need capital planning or formal remediation.
This distinction is important. Many organizations blur the line between accepted operational conditions and unresolved project defects. When that line is blurry, recurring issues keep resurfacing as service tickets instead of being treated as fundable building problems.
A better way to escalate vendor issues
Another strong takeaway from the episode is the remediation ladder. Property teams often hesitate to escalate because they worry about straining vendor relationships or triggering budget fights too early. Michael’s approach is practical and measured. Start with documented evidence. Make a clear request inside a defined remediation window. If a permanent correction cannot happen in time, require a temporary mitigation plan and cost estimate for owner approval.
The sample language in the episode is effective precisely because it stays factual. It references the day 30 stability log, cites repeated resets in a defined area, attaches timestamped logs and vendor attestation, and requests warranty remediation within 14 calendar days. If the timeline cannot be met, it asks for a temporary mitigation plan and an estimated cost.
That approach preserves relationships because it avoids accusation. It also improves the odds that defects become fundable when necessary because the request is tied to evidence, business impact, and a documented timeline.
The business case is bigger than technical cleanup
The broader value of the 30/60/90 playbook is not just cleaner handover. It is lower operational drag. The episode makes the economic point clearly: quick undocumented fixes often push cost into operations, delay capital decisions, and keep tenants exposed to reliability issues. In the tougher case discussed, the absence of a remediation register and clear evidence allowed PoE lighting and HVAC interactions to keep generating nuisance fire inputs. By the time the owner funded a rewiring project six months later, ticket volume had remained high and the cost to stabilize was roughly three times what an earlier funded fix would have been.
That is the real warning for property teams. Failing to define evidence standards early does not save money. It usually changes where the money shows up and how much disruption occurs before someone approves it.
Three actions to take this week
The episode closes with three immediate next steps that are simple enough to implement right away. Create a one-page stability log template and populate it with seven days of current alerts for critical systems. Open remediation register entries for the top two recurring tickets and assign both owners and temporary mitigations. Then send the first remediation request email for any item that already meets the evidence standard, with timestamped logs attached and a 14-day window for correction.
For teams responsible for commercial environments, this is a useful reminder that operational readiness is not a one-day event. It is a short, structured period of validation, prioritization, and acceptance. Buildings do not become stable because the ribbon is cut or the tenant moves in. They become stable because someone creates the evidence, ownership, and escalation path needed to keep small issues from turning into recurring failures.
If this episode sounds familiar to your team, it is worth listening in full and downloading the checklist and templates mentioned in the close. The core question to carry forward is simple: what breaks if this goes down? That question can sharpen your stability log, focus your remediation register, and make your first 90 days after handover far more predictable.
Listen to the full episode and use the playbook to strengthen post-move-in operations before repeat tickets become long-term building problems.