GDS Technology — Built, Wired and Secured podcast banner
Watch on YouTube →
Episodes Built
Episode 77

Temporary to Permanent: Managing Short‑Term Tech Services During Renovations and Events

July 13, 2026
Key takeaways
  • Temporary technology becomes risky when no one assigns ownership, expiration, or decommission responsibility.
  • If a temporary asset is not tagged, logged in CMMS, and monitored, it becomes an invisible failure point.
  • Anything touching security or life safety should be hardened immediately rather than left provisional.
  • A one-page approval form and decommission plan can prevent months of confusion and repeat outages.
  • The best decision test is simple: ask what breaks if the temporary system goes down.

Show Notes

When a temporary fix becomes a permanent problem

This episode of Built, Wired & Secured focuses on a problem property teams, facilities leaders, IT managers, and contractors run into all the time: temporary technology that never actually leaves. What starts as a short-term switch, breaker panel, wireless bridge, or access system to get through a renovation, move-in, pop-up activation, or construction phase can quietly become part of the building's production environment. Once that happens, the risk changes. A stopgap turns into hidden operational debt.

The episode opens with a move-in day failure that makes the stakes clear. A temporary switch had been left in place, marked "do not touch." Months later, a tenant closet was tied into it through an improvised feed. On day one of occupancy, the switch failed under load. Printers, badge readers, and voice services were affected, and even elevator reporting was disrupted. The operational team had no clear answer to the most basic question: who owned the device?

That ownership gap is the thread running through the entire discussion. The issue is not just bad hardware or a rushed install. It is the absence of visibility, accountability, and a real end date.

Why temporary services linger

The guests explain that temporary systems usually become permanent through omission, not intent. Speed matters during projects. Budgets are tight. Teams need something running now. Under that pressure, interim fixes are easy to approve and easy to forget.

  • Contractors assume facilities will take over the asset.
  • Facilities assumes IT will own it.
  • IT assumes the contractor will remove it later.
  • No one assigns a named owner.
  • No one records an expiration date.
  • No one writes a decommission plan into the work order.

That is how a "temporary" service survives for months or years without entering any formal lifecycle process. The episode makes the point that teams often think of something as temporary in conversation, but fail to treat it as temporary inside their systems. If it is not tagged, logged, monitored, or reviewed, it is effectively unmanaged.

The operational cost of invisibility

One of the strongest themes in the episode is that unseen assets do not receive preventive care. If a temporary device never makes it into CMMS, it has no maintenance history, no review schedule, no spare strategy, and no inclusion in emergency procedures. That creates maintenance blind spots that only become visible after something breaks.

The guests frame this as a preventable operations problem. Preventive maintenance beats emergency repairs every time, but preventive maintenance can only happen when the asset is visible in the system. A rented switch still powering badge readers two years later is not just an odd oversight. It is a predictable failure point.

The downstream effects hit more than the operations team. Tenants feel it too. If printers stop working, POS systems drop, badge readers fail, or voice services flicker, the building becomes the first call. Over time, those repeated interruptions damage confidence and trust.

  • Unknown failure points increase outage risk.
  • Missing firmware schedules create avoidable reliability issues.
  • Lack of spare parts planning slows recovery.
  • Assets outside emergency scripts make incident response harder.
  • Tenant-facing disruptions can affect retention and renewals.

When to accept temporary and when to harden immediately

The conversation does not argue that every short-term deployment is wrong. Temporary workarounds are sometimes necessary. The key is deciding where provisional is acceptable and where it is not.

The practical rule from the episode is simple: accept a temporary solution only when it has a documented, enforceable expiration and a real decommission plan. If it touches security or life safety, it should be hardened immediately.

That includes systems tied to access control, emergency power, and other services where failure creates safety risk or major operational disruption. The deciding question is one the guests repeat more than once: what breaks if this goes down? That question forces teams to think in terms of impact instead of convenience.

For lower-risk situations, the middle path is visibility and monitoring. If a team cannot harden immediately, they should still time-box the install, assign ownership, and put health monitoring or scheduled checks in place.

Low-friction controls that actually work

A major strength of this episode is its focus on simple controls that are realistic to enforce. The guests are clear that long policy documents do not solve this problem. Short, mandatory paperwork does.

The recommended controls are deliberately lightweight:

  • A temporary install approval that names an owner and lists an expiration date.
  • A decommission plan attached to the work order.
  • An asset tag for the temporary device.
  • A CMMS entry labeled temporary with a review date.
  • Minimum telemetry or scheduled manual checks.
  • A named escalation contact.
  • A short handover meeting at project close.

That handover meeting is only thirty minutes, but the guests argue it saves hours of future troubleshooting. It is the moment where documentation, asset tags, monitoring expectations, and decommission details are transferred cleanly before everyone disperses.

Real examples from the field

The episode includes two short incidents that show how small process changes can reduce repeat problems. In one case, a breaker panel marked temporary was left in a basement for months and eventually powered a tenant closet through an improvised feed. It failed during a load test. The fix was not complicated. The team introduced a two-item signoff: temporary install approval with an expiration date, and a required decommission plan. That created visibility and ownership and stopped the issue from repeating.

In another example, a pop-up retailer relied on a rented wireless bridge for point-of-sale traffic. Because the device was not monitored, packet drops became failed transactions. The response was a one-page contractor checklist that required minimum telemetry and an owner contact. Within weeks, repeat support calls dropped by roughly half.

The message is consistent: modest process discipline produces measurable operational improvement.

The 48-hour checklist for temporary deployments

For teams approving temporary services tomorrow, the episode lays out a practical first-48-hours checklist:

  • Require a temporary install approval with a named owner and explicit expiration date.
  • Create a decommission plan before the work fades into the background.
  • Asset tag the device immediately.
  • Enter it into CMMS as temporary and assign a review date.
  • Require minimum telemetry, or schedule manual health checks if telemetry is not possible.
  • Name an escalation contact.
  • Escalate or harden any device that touches security or life safety.
  • Hold a short handover meeting at project close.

What listeners should take away

The episode closes on a clear operating principle: if it is temporary, make it visible and time-boxed. That is how teams avoid surprise outages, maintenance blind spots, and preventable tenant disruption. Temporary services are not inherently dangerous. Unowned, undocumented, and unmonitored temporary services are.

Listeners also get a useful reminder that operational decisions should begin with business impact. Before approving a shortcut, ask what breaks if it fails. That one question helps separate harmless convenience from serious risk.

If you manage buildings, tenant technology, facilities projects, or contractor scopes, this episode offers a simple framework you can put to work immediately. The one-page checklist, approval form, decommission template, and contractor language mentioned in the episode are positioned as practical tools, not theory. That fits the larger point of the conversation: good operations is usually not about adding more complexity. It is about making ownership visible before a temporary install becomes tomorrow's outage.

Deeper dive

Temporary technology has a way of staying longer than anyone planned

Renovations, move-ins, pop-up activations, construction projects, and special events all create the same pressure: get the space working now, clean it up later. In that environment, temporary switches, rented wireless links, provisional power feeds, and interim access systems can feel reasonable. They solve the immediate problem. They keep the project moving. They buy time.

Then time passes.

What was supposed to last two weeks ends up supporting live operations for months. A temporary switch starts carrying real tenant traffic. A stopgap power feed becomes part of an occupied suite. A rented device winds up serving printers, badge readers, or POS systems long after the original project wraps. Nobody explicitly approved that outcome. It just happened because the temporary install was never fully owned, documented, or removed.

That is the central lesson from this episode of Built, Wired & Secured. Temporary services are not just a project convenience. If they are not controlled early, they become long-term operational debt.

The failure pattern is familiar

The episode opens with a move-in day story that captures the problem fast. A temporary switch had been left in place and marked "do not touch." Later, a tenant closet was tied into it through an improvised feed. On day one of occupancy, the switch failed under load. The fallout reached printers, badge readers, voice services, and elevator reporting. People were on the phone. The ops desk had no clear documentation. Most importantly, no one could say who actually owned the device.

That is what makes temporary services so risky. They often fail at the exact point where the building assumes they are stable. By then, the original context is gone. The contractor has moved on. The project team has disbanded. Facilities thinks IT has it. IT thinks facilities has it. Everyone assumes someone else is responsible.

Temporary becomes permanent by omission.

The real problem is not temporary gear. It is invisible gear.

One of the best points in the episode is that the danger does not come from the word temporary by itself. The danger comes from assets that never enter the system.

If a device is not tagged, it does not have a lifecycle identity. If it is not in CMMS, it does not have a review date, maintenance schedule, or history. If it is not monitored, it can degrade quietly until users feel the failure before operators do. If it is not included in emergency scripts, it becomes a mystery box during an outage.

This is why the guests keep returning to visibility. A visible temporary asset can be managed. An invisible one cannot.

That distinction matters because teams often think they are making a short-term exception. In reality, they are creating a hidden dependency. The business cost shows up later as surprise downtime, reactive support, tenant frustration, and a more fragile operating environment.

Why these decisions keep happening

The episode does not blame one department. It describes a pattern created by time pressure, budget pressure, and fuzzy handoffs.

Projects move quickly. Procurement pushes for the lower-cost path. Contractors are focused on delivering the scope in front of them. Facilities is trying to keep the property operating. IT is managing production risk. Under those conditions, a provisional fix can look like the practical answer.

The trouble starts when that fix is not paired with four basic controls:

  • A named owner
  • An expiration date
  • A decommission plan
  • Some form of monitoring or review

Without those controls, the temporary install is not temporary in any meaningful operational sense. It is just undocumented production infrastructure.

Not every temporary install needs the same response

The conversation avoids an overly rigid answer, and that matters. The recommendation is not to harden every short-term service immediately, no matter the cost. The recommendation is to prioritize by impact.

The practical decision test from the episode is simple: what breaks if this goes down?

If failure affects core tenant services, building operations, security, or life safety, the answer is to harden now or escalate immediately. That includes systems tied to access control, emergency power, and other essential functions where the cost of failure is far higher than the cost of doing the work right.

If the impact is lower, the middle path is acceptable. Time-box the installation. Assign an owner. Add monitoring. Put the asset into CMMS with a temporary label and review date. Require telemetry where possible. If telemetry is not available, require manual checks and a named escalation contact.

That approach keeps teams from overengineering low-risk situations while still preventing the most common failure mode: forgetting the asset exists.

Minimal process beats perfect policy

Another useful theme in the episode is that effective control does not require a mountain of paperwork. In fact, the guests argue the opposite. Long policy documents are hard to enforce. Short mandatory controls are much more likely to stick.

The recommended package is intentionally small:

  • A temporary install approval with a named owner and expiration date
  • A decommission plan attached to the work order
  • An asset tag
  • A CMMS entry marked temporary with a review date
  • Minimum telemetry or scheduled manual checks
  • A short handover meeting at project close

That last item deserves more attention than it usually gets. A thirty-minute handover meeting sounds minor, but it closes one of the biggest operational gaps. It is where ownership is transferred, documentation is reviewed, tags are confirmed, monitoring expectations are set, and the decommission plan is handed off before memories fade.

Most recurring temporary-service problems are not caused by technical complexity. They are caused by that missing last step.

Small controls can produce outsized results

The episode backs up its advice with real examples. In one case, a breaker panel marked temporary stayed in place for months and ended up feeding a tenant closet through an improvised connection. It failed during a load test. The fix was not a giant new program. The team implemented a two-item signoff: temporary approval with an expiration date, plus a required decommission plan. That alone created the visibility and accountability needed to stop recurrence.

In another case, a pop-up retailer depended on a rented wireless bridge for point-of-sale traffic. Because the device was not monitored, packet drops became failed transactions. A one-page contractor checklist requiring minimum telemetry and an owner contact reduced repeat support calls by roughly half within weeks.

That is the operational value of basic discipline. The goal is not bureaucratic perfection. The goal is fewer surprises.

A practical 48-hour checklist

For anyone approving temporary technology services during a project, the episode offers a short list of actions to take in the first 48 hours:

  • Approve the install in writing with a named owner.
  • Set an explicit expiration date.
  • Require a decommission plan before the project disappears into the background.
  • Asset tag the device immediately.
  • Enter it into CMMS as temporary with a review date.
  • Require minimum health reporting, or schedule manual checks.
  • Name an escalation contact.
  • Escalate or harden anything tied to security or life safety.
  • Hold a closeout handover meeting.

None of these steps are complicated. That is the point. They are simple enough to become standard language in procurement, work orders, and contractor expectations.

Why this matters to business leaders, not just operators

It is easy to hear a conversation about temporary switches, breaker panels, and CMMS entries and assume this is purely a facilities or IT topic. It is not. The transcript makes a business case throughout.

When undocumented temporary systems fail, tenants experience the outage first. That damages trust. It increases support volume. It pulls teams into emergency mode. It creates preventable maintenance work and often leads to higher replacement cost later. In some cases, it also exposes security or safety risk that should never have been left provisional.

That is why the question "what breaks if this goes down?" matters so much. It ties technical decisions back to operational and business impact. A cheap temporary install is not really cheap if it creates avoidable downtime, support burden, or tenant dissatisfaction later.

The takeaway

The clearest line in the episode may also be the most useful: if it is temporary, make it visible and time-boxed.

That one principle captures the whole operating model. Temporary services are sometimes necessary. Hidden temporary services are not. If a short-term device is going to touch the real business, it needs ownership, monitoring, a review date, and a planned exit. If it touches life safety or security, it needs more than that. It needs to be hardened or escalated immediately.

For property owners, facilities teams, IT leaders, and contractors, the value here is not abstract. It is practical. Small process changes can reduce repeat failures, lower support noise, and keep temporary convenience from turning into permanent fragility.

If this topic hits close to home, listen to the full episode and grab the checklist, approval form, decommission template, and contractor language referenced in the discussion. The advice is straightforward, and that is exactly why it works.