Show Notes
Why spare parts planning matters more than most teams realize
Modern buildings depend on a layered mix of switches, controllers, access hardware, sensors, appliances, and firmware-driven systems. In this episode of Built, Wired & Secured, Alex Morgan and Michael Harrington break down a problem many facilities and property teams only confront once something fails: what happens when a critical component is no longer easy to replace.
The conversation centers on a simple but costly reality. A purchasing decision that looks efficient on day one can become extremely expensive later if that device becomes unavailable, unsupported, or incompatible with the rest of the environment. As Michael explains, a building is only as available as its least replaceable component. That framing shifts lifecycle planning from an abstract operational exercise into a business continuity issue.
Instead of focusing on products or vendors, the episode looks at the frameworks owners and operators can use to reduce downtime, avoid emergency procurement, and connect asset decisions to capital planning.
The hidden dependency inside every building
One of the most useful ideas in the episode is the notion that a building contains its own internal supply chain. Devices do not just fail in isolation. They exist inside an ecosystem of parts, firmware versions, warranties, suppliers, and replacement paths. When that ecosystem changes, the operational impact can be immediate.
Michael explains that if a critical component becomes unavailable, teams are usually left with three unattractive options:
- Retrofit around the failed part
- Source an expensive one-off replacement
- Accept reduced functionality until a fix is available
For facilities leaders, that means lifecycle planning is not just about maintenance discipline. It is about avoiding avoidable operational risk and deciding whether those costs show up in a planned capital cycle or in an unplanned emergency.
Building an owner-centric bill of materials
A major part of the discussion focuses on what teams should actually document. Michael argues that many organizations rely too heavily on vendor-centric documentation, which creates a “mystery box” problem. If the vendor changes direction, retires a SKU, or stops supporting a product, the owner is left without actionable information.
His recommendation is to build an owner-centric BOM. That means documenting assets by function first and then mapping technical details underneath that function.
The episode outlines the kinds of information that should be captured:
- What the device does in building operations
- SKU and model information
- Firmware versions and firmware baseline
- Serial ranges
- Procurement date
- Warranty end date
- Compatible interchangeable parts
- Supplier options
The point is practical. A single line item labeled “access controller” does not help much during an outage. A structured inventory that connects functional role to replacement options makes decisions faster, lowers procurement friction, and reduces the chance that a rushed replacement will create a compatibility problem.
Common mistakes that create emergency scrambles
Michael highlights three recurring mistakes teams make when trying to build or maintain asset inventories.
- Relying only on vendor documentation that may disappear when products reach end of life
- Allowing data to live in silos across spreadsheets, CMDBs, and contractor notes
- Tracking only hardware while ignoring firmware and compatibility constraints
That last point is especially important. A replacement may look correct on paper and still fail in practice if the software layer does not match the environment. The episode makes the case that firmware awareness is not a technical luxury. It is part of basic operational readiness.
According to Michael, fixing these issues can dramatically cut emergency response time because teams are no longer starting from scratch when a failure occurs.
How to prioritize where to invest
Not every device deserves the same continuity strategy. The episode offers a risk-tiering approach to help owners decide where to spend money and where they can reasonably accept more risk.
Michael recommends classifying assets by impact, including categories such as:
- Safety critical
- Tenant-facing
- Revenue-impacting
- Operationally essential
- Convenience-based
That classification then informs the response strategy. For safety-critical systems such as fire systems, elevators, or controlled access, teams should budget for immediate replacement options and require stronger vendor continuity. For convenience items, a run-to-failure model may be acceptable.
The episode also adds an important nuance: low cost does not always mean low risk. If a cheap component has a six-month lead time and is used daily, it may represent a serious operational exposure.
Using third-party or refurbished parts without creating new risk
Another useful section addresses third-party sourcing and refurbished equipment. Michael does not dismiss these options, but he is clear that they need governance. They can be a practical continuity strategy, especially when OEM paths are slow or unavailable, but only if teams define acceptance criteria ahead of time.
That includes:
- Functional testing requirements
- Firmware parity expectations
- Known failure modes
- Documented vendor limitations around non-OEM components
The takeaway is not that third-party sourcing is always right or always wrong. It is that blind rejection and unvetted cost cutting are equally risky. Property teams need an informed, documented decision process.
Turning lifecycle data into real operational playbooks
The conversation then moves from inventory strategy to execution. Michael suggests translating asset criticality into three concrete outputs:
- A spare parts list
- A refresh cadence
- A simple runbook
The spare list should define what is held on site, what is stored regionally, and what is covered through supplier arrangements. The refresh cadence should tie expected lifespan, support timelines, firmware end dates, and vendor road maps into a multi-year capital forecast. The runbook should tell operators exactly what to do when a known failure occurs.
One of the strongest operational ideas in the episode is to keep runbooks short. Michael recommends one page per failure scenario. That forces clarity and makes the document usable under pressure.
His example for a door controller outage includes the impact, immediate action, short-term mitigation, spare part reference, firmware validation, escalation path, procurement trigger, signoff thresholds, and communication templates. That is a practical model for turning documentation into response readiness.
Real examples of proactive planning paying off
The episode closes the theory-to-practice gap with two anonymized examples.
- A downtown office tracked firmware and end-of-support dates for access controllers, purchased a limited stock of compatible replacements, and staged them offsite. When the model was discontinued, the team completed a controlled weekend swap with no tenant impact.
- A campus categorized HVAC controllers by criticality and used a five-year phased refresh funded through operating reserves. When supply chain disruptions extended lead times, the organization avoided emergency capital, overtime, and expedited freight because half the fleet had already been replaced on plan.
Both examples reinforce the same business point: thoughtful lifecycle planning reduces downtime, lowers the cost of disruption, and gives operators options before an outage forces their hand.
Three actions to take in the next 30 to 90 days
Michael leaves listeners with three direct action items:
- Build or update an owner-centric BOM that includes firmware and support dates
- Tier assets by operational impact and define a spare strategy for each tier
- Create one-page runbooks for the top five failure scenarios and link them to capital refresh schedules
For property teams, facilities leaders, and owners, this episode offers a useful reminder that resilience is rarely created during the outage itself. It is built earlier through documentation, prioritization, and disciplined planning. The better those decisions are made ahead of time, the less likely building operations are to be shaped by avoidable surprises.
The spare parts problem is really an operations problem
In commercial buildings, technology failures are often treated like isolated maintenance events. A controller fails. A switch goes down. An access reader stops responding. The immediate instinct is to replace the part, restore service, and move on.
But as discussed in this episode of Built, Wired & Secured, that view misses the bigger issue. Building systems do not fail inside a vacuum. They depend on vendor support, firmware compatibility, replacement paths, procurement speed, and asset visibility. When any of those pieces are weak, even a relatively small hardware failure can turn into a costly operational disruption.
That is the core of “the spare parts problem.” It is not just about whether a component breaks. It is about whether the organization knows what the part does, what replaces it, how fast it can be sourced, whether it will work in the current environment, and who owns the decision when time matters.
For property owners, facilities leaders, and operations teams, that is why lifecycle planning belongs in the same conversation as uptime, tenant experience, and capital planning.
A building is only as available as its least replaceable component
One of the clearest ideas in the episode is Michael Harrington’s plain-language explanation of hidden dependency: a building is only as available as its least replaceable component.
That matters because the most operationally dangerous assets are not always the most expensive ones. A low-cost device with poor sourcing options, obsolete firmware, or a six-month lead time can create a bigger business problem than a more expensive asset with strong support and multiple replacement paths.
That is the trap many teams fall into. They optimize for purchase price, not lifecycle resilience. The result is a portfolio of systems that may look cost-effective at install time but become fragile when parts are retired, vendors shift direction, or software dependencies change.
From a business perspective, the consequences show up quickly:
- Longer outages
- Emergency procurement costs
- Tenant dissatisfaction
- Unplanned overtime
- Faster-than-expected capital requests
- Reputational damage when access or essential systems fail
In other words, lifecycle planning is not administrative overhead. It is part of operational continuity.
Why owner-centric documentation beats vendor-centric documentation
A major recommendation in the episode is to move away from a vendor-only view of asset documentation and toward an owner-centric bill of materials.
That distinction matters. Vendor documentation is useful, but it is not built primarily for the owner’s long-term operational needs. It can disappear when products reach end of life. It often reflects a product catalog more than a continuity plan. And it may not help a property team make fast decisions during an outage.
An owner-centric BOM starts with function first. Instead of merely listing model numbers, it defines what each component does for building operations and then ties technical and commercial details to that role.
According to the episode, a useful owner-centric BOM should include:
- Functional role of the device
- SKU or model information
- Firmware version and baseline
- Serial range or identifying details
- Procurement date
- Warranty end date
- Support status
- Compatible alternate parts
- Supplier options
This changes the quality of decision-making. If a door controller fails, the team should not have to start by figuring out what the device is, whether it still has support, or whether a newer replacement will work. Those are questions that should already be answered.
That is where GDS Technology’s Technology Partner approach becomes important in the real world. The value is not just in deploying systems. It is in helping clients document, govern, and maintain environments in a way that supports continuity long after the initial install.
The three documentation failures that create avoidable downtime
The episode identifies three common breakdowns that turn manageable issues into emergency scrambles.
First, many teams rely exclusively on vendor documentation. If that documentation becomes inaccessible or incomplete after end of life, the owner loses visibility at exactly the wrong moment.
Second, asset information often lives in disconnected places. Operations may have a spreadsheet. IT may have CMDB data. Contractors may have implementation notes. None of those systems are inherently wrong, but if they do not align, the team is working from fragments.
Third, organizations often track hardware without tracking firmware or compatibility notes. That creates a false sense of preparedness. A replacement part may be physically correct and still fail because the software layer is out of step with the rest of the environment.
For business leaders, the lesson is straightforward: incomplete documentation is not just a technical issue. It directly affects outage duration, labor efficiency, and capital predictability.
Risk-tiering creates a smarter spare strategy
Not every asset deserves the same level of protection. That is why the episode recommends tiering assets by operational impact instead of trying to apply one universal spare parts policy.
Examples of useful categories include:
- Safety critical
- Tenant-facing
- Revenue-impacting
- Operationally essential
- Convenience-based
This framework helps owners spend intentionally. Safety-critical and access-dependent systems justify stronger continuity measures, such as on-hand spares, stricter vendor continuity, or faster procurement paths. Convenience systems may justify a more relaxed strategy.
Importantly, the conversation also points out that lead time changes the risk profile. A low-cost component with a long replacement cycle may deserve more planning than its price suggests. Teams that focus only on replacement cost can miss the operational cost of being without the asset.
That kind of risk-tiering is where strategy starts to connect to budget. Once asset classes are defined, owners can make clearer decisions about where to hold inventory, where to negotiate support, and where run-to-failure is actually acceptable.
Third-party and refurbished parts can work, but only with governance
The episode takes a balanced view of third-party sourcing. Refurbished or non-OEM parts are not dismissed outright, nor are they treated as an automatic cost-saving win.
Instead, Michael frames them as a pragmatic continuity tool that requires governance. If an organization is willing to use third-party parts, it should do so under a documented framework that covers:
- Acceptance criteria
- Testing requirements
- Firmware parity
- Known failure modes
- Vendor limitations or support restrictions
That matters because the wrong replacement can create a second outage, a support dispute, or a hidden compliance problem. The right governance turns third-party sourcing from an emergency gamble into a managed option.
Runbooks turn planning into response
Inventory alone is not enough. The episode emphasizes that asset criticality should produce three operational outputs: a spare parts list, a refresh cadence, and a runbook.
The runbook recommendation is especially strong because it is intentionally lightweight. One page per failure scenario. That is enough to be useful under pressure and specific enough to drive action.
For a door controller outage, the example includes the impact, immediate mitigation, spare part reference, configuration restore step, firmware validation, escalation path, and emergency procurement process. That is a strong model because it reduces hesitation and clarifies ownership.
For business leaders, one-page runbooks are more than technical documentation. They are a governance tool. They create repeatability, reduce confusion, and help teams act consistently across sites and vendors.
Capital planning should reflect lifecycle reality
The other major output of good lifecycle planning is a refresh cadence tied to real support timelines. Expected lifespan, firmware support, vendor road maps, and obsolescence signals should feed into multi-year capital planning rather than waiting to surface during failure.
The examples shared in the episode make that business case clearly. In one case, an office team pre-positioned compatible access controllers and completed a controlled swap after discontinuation with no tenant disruption. In another, a campus used phased HVAC controller replacement funded through reserves, which protected the organization from supply chain shocks and emergency spending.
Both examples show the same principle: planning early gives operators more choices and usually lowers total disruption cost.
What property and facilities teams should do next
The episode closes with three concrete steps for the next 30 to 90 days:
- Build or update an owner-centric BOM that includes firmware and support dates
- Tier assets by operational impact and define a spare strategy for each tier
- Create one-page runbooks for the top five failure scenarios and connect them to capital refresh schedules
These are practical actions, not abstract best practices. They help teams move from reactive operations to predictable operations.
For organizations managing building technology at scale, that shift matters. The goal is not simply to replace parts faster. The goal is to reduce surprise, protect uptime, and make technology decisions with a long-term ownership mindset. That is what turns building tech from a recurring source of disruption into an asset that supports business continuity.
If this episode’s topic is relevant to your portfolio, listen to the full conversation for a grounded discussion of how spare parts, obsolescence, and lifecycle planning affect real building operations over time.