Dependency Maps: Visualizing the Dominoes Behind Building Outages

Why hidden dependencies still cause major building outages

This episode opens with a failure that feels small on paper but large in practice: live badge readers at two doors, a dead telecom closet, and tenants locked out for hours because a UPS battery bank failed. That single failure took down closet switches and PoE injectors, which in turn broke access control. The bigger problem was not only the failed battery bank. It was the fact that the full domino chain was not owned, documented, or verified anywhere people could use it in real time.

That is the central theme of this conversation: many outages are not caused by one dramatic event. They happen because teams manage power, networking, security, BAS, and tenant systems in separate lanes, while the real risk lives in the connections between them. Facilities may focus on power, IT may focus on switches, and security may focus on readers, but tenants experience the combined failure. A dependency map helps teams see the chain the way the building actually behaves.

What a dependency map is supposed to do

Michael Harrington and James Rogers describe a dependency map as something practical and readable, not a perfect engineering artifact. It is not meant to replace detailed wiring diagrams, but it also should be more useful than a disconnected spreadsheet. The goal is to expose critical paths, key nodes, and traceable links so a team can answer a simple question quickly: if this fails, what fails next?

• Power source
• UPS
• Panel
• Telecom closet
• Edge switch
• PoE injector
• Card reader
• BAS controller
• Cloud API

The conversation also highlights an important mindset: map the actual dependencies, not the ideal documentation. That means verifying what is truly connected, what assumptions people are making, and which parts of the chain are still unknown.

Start small and make the first hour count

One of the strongest practical recommendations in the episode is to start small. Do not begin with a whole-property audit and expect instant buy-in. Instead, choose one critical asset, one floor, or one tenant-critical area and trace that path upstream.

For a first workshop, the group should include the people who operate the systems and the people who sign off on changes. The suggested mix is straightforward:

• A facility supervisor
• A network lead
• A security representative
• A tenant contact when appropriate

From there, the team should start at the critical asset and work backward through the chain. If the asset is a main entry card reader, then the exercise becomes concrete: which switch supports it, which UPS supports that switch, which breaker supports that UPS, and which feeder supports that breaker? Unknowns should not be hidden or hand-waved. They should be marked clearly and assigned to someone to verify.

The key outcome is not a perfect document. The key outcome is a testable map plus a short list of verification tasks. As the episode puts it, if a one-hour workshop produces a usable map and three verification tasks, that is a meaningful win.

Why layered maps work better than over-detailed maps

Another useful idea in the discussion is the concept of layered maps. A single all-purpose document often fails because it either becomes too detailed for leadership or too shallow for operations. A layered approach keeps the map usable for different audiences.

• A high-level view shows what cascades when a component fails
• An operational lane shows who owns a device, who replaces it, and how long a fix may take
• Ownership and assumptions stay attached to the map so it remains actionable

The speakers make a simple but important point: a map that gets updated is more valuable than a perfect drawing that goes stale. That discipline matters because stale maps do not just become useless. They create false confidence.

How to prioritize fixes without making the exercise academic

Once the map exists, the next question is what to fix first. The episode recommends simple triage rules rather than complicated scoring systems. Paths should be scored primarily by impact and likelihood.

Impact asks who feels the failure immediately. If tenants lose access, a safety-critical system goes down, or a clinic loses operational continuity, that path deserves attention. Likelihood asks whether the chain contains an active single point of failure. Then cost and lead time can help determine what gets done now versus later.

The conversation also adds two refinements that make prioritization more grounded:

• Use simple red, amber, and green ratings with a one-line justification
• Always assign an owner and a next action
• Weight history, especially near misses and repeated manual recovery events

That last point matters. A path that keeps needing manual restarts is already telling you where the building is brittle. Repeated near misses are not background noise. They are a warning signal.

Turning the map into operational work

A dependency map only matters if it changes behavior. The discussion makes clear that the map should be tied directly to change control, work orders, and exercises. If someone is pulling a panel, changing firmware, or modifying a sequence, the map should be reviewed and updated. If ownership is unclear, that gap should be resolved before the map is treated as reliable.

The speakers also recommend using the map in tabletop exercises. For example, simulate a UPS failure and walk the full operational response:

• Who gets called first
• Who transfers loads
• How long systems stay down
• Which unknowns still need verification

This is where the map moves from documentation into resilience work. It becomes part of daily operations rather than a shelf item created after an incident.

A practical example with real payoff

One of the most memorable examples in the episode comes from a medical office floor. A small dependency map revealed that exam room HVAC and critical network patch panels were riding on the same UPS. There was no budget for a second UPS, so the team took two modest steps instead: they rearranged loads and added a manual transfer procedure.

Six months later, the battery bank failed. Because the dependency had already been exposed and the procedure had already been defined, staff transferred the load and the clinic kept running without missed appointments. That story captures the full point of the episode. A small map plus a small procedure can prevent a large operational failure.

What listeners can do this week

The episode closes with a concise action list that building and operations teams can use immediately:

• Pick one critical asset and map upstream to the service entrance
• Run a 60-minute tabletop for the likeliest failure on that path
• Assign an owner and a verification date for every unknown

The broader lesson is simple: map what matters, test what you map, and document your assumptions. Dependency maps are not about creating more paperwork. They are about preventing visible failures, improving coordination across trades, and focusing effort where it will reduce the biggest outages. For property teams, facilities leaders, and tenant-facing operators, that makes the hour well spent.

Dependency maps are one of the simplest ways to reduce building outages

Building outages often look random from the outside. A tenant cannot badge in. A system goes into safe mode. A telecom closet goes dark. A maintenance issue suddenly becomes an access issue, or a network issue, or an operational issue that affects an entire floor. But what this episode makes clear is that many of these failures are not random at all. They are the predictable result of hidden dependencies that nobody has mapped end to end.

The opening example says it all. Two doors had live badge readers, but the telecom closet behind them was down. A UPS battery bank had failed, taking closet switches and PoE injectors down with it. The result was hours of tenant lockout. The technology itself was not especially exotic. What made the outage serious was the domino chain across power, networking, and access control, combined with the fact that no one had that chain documented in a way that could be verified or acted on.

That is why dependency mapping matters. It gives operations, facilities, IT, and security teams a shared view of how systems really depend on one another. More important, it helps them decide what to test, what to fix, and what to prioritize before an avoidable outage becomes visible to tenants or leadership.

The real problem is not the failed device. It is the invisible chain behind it.

One of the most useful ideas in the episode is the distinction between managing individual components and understanding the chain that connects them. Facilities may know the breaker and panel. IT may know the closet switch. Security may know the badge reader. BAS teams may know the controller or cloud sequence. But tenants do not experience those systems in isolation. They experience the whole chain at once.

That is why a failed UPS can become a security incident, and why an expired certificate or heartbeat failure can push a vital AHU into safe mode. A local issue can trigger a building-level consequence because the upstream and downstream relationships were never surfaced clearly.

A dependency map exists to reveal those relationships. Not as an academic exercise, and not as a perfect engineering drawing, but as a practical tool that answers one critical question: if this fails, what fails next?

What a useful dependency map actually looks like

This episode avoids overcomplicating the concept. A dependency map is not a demand for full wiring diagrams on day one, and it is not just a spreadsheet of devices. It is something in between: a readable map of critical paths, major nodes, and traceable links.

That might include a path like this:

• Power source
• UPS
• Panel
• Telecom closet
• Edge switch
• PoE injector
• Card reader

Or it might extend into BAS and remote services:

• BAS controller
• Heartbeat dependency
• Cloud API
• Operating sequence that assumes upstream availability

The important rule is to map actual dependencies, not ideal documentation. In other words, do not assume the drawing is right just because it exists. Walk the path. Verify the connection. Mark what is unknown. Capture who believes what and who needs to confirm it.

Start with one floor, one tenant, or one critical asset

A major reason these efforts stall is scope. Teams often start by imagining a full building audit, then lose momentum before anything becomes usable. The better approach described in this episode is much smaller and faster. Pick one critical asset and trace upstream.

That asset might be:

• Main entry card readers
• Emergency lighting support systems
• A tenant-critical network path
• A medical office operational path

Then build the first map in a one-hour workshop. Bring the people who operate the systems and the people who approve work. The suggested attendees are practical and cross-functional:

• Facility supervisor
• Network lead
• Security representative
• Tenant contact, when the system directly affects tenant operations

Start at the asset and work backward. Which switch supports it? Which UPS supports that switch? Which breaker supports that UPS? Which feeder supports the breaker? Where does anyone have uncertainty? Those unknowns become verification tasks, not buried assumptions.

The standard for success is not perfection. If the workshop ends with a testable map and a few assigned verification tasks, then it already has value.

Keep the map layered so people will actually use it

Another smart recommendation in the episode is to use layered maps rather than trying to force every audience into the same document. Leadership does not need every operational detail. Operations teams do not need only a high-level risk picture. Both need a version they can actually use.

A high-level layer should show what cascades when a critical component fails. An operational layer should show who owns the asset, who replaces the battery, how long the replacement takes, and what tie lines or manual procedures exist. The goal is usability, not elegance.

This matters because the best map is not the prettiest one. It is the one that gets updated. A perfect but stale drawing creates false confidence. A simpler map that reflects current reality is far more valuable.

How to prioritize fixes without getting stuck in theory

Once a team can see the dependencies, the next challenge is deciding what to do first. The episode recommends a straightforward prioritization model: score by impact and likelihood, then factor cost and lead time.

Impact is about who feels the failure immediately. If tenants lose access, if a safety-related function is affected, or if a clinic cannot operate, the impact is high. Likelihood is about whether a single point of failure exists right now. If one battery bank, one switch, or one sequence can take the whole path down, that should move up the list.

The conversation wisely warns against letting scoring systems become too academic. The practical version is simple:

• Use red, amber, and green ratings
• Write a one-line justification
• Assign an owner
• Assign a next action

There is also one more factor worth adding: history. Near misses matter. If a path has already required a manual restart or has shown repeated brittleness, it deserves more urgency than a clean path with no history. Repeated near misses are often the clearest warning that a dependency is too fragile.

Small operational changes can deliver outsized resilience

One of the strongest messages in the episode is that not every improvement requires a large capital project. Sometimes the best next step is a label change, a maintenance adjustment, a load rearrangement, or a manual transfer procedure. That matters for property teams because budget is always constrained, and resilience work competes with many other priorities.

The medical office example makes this concrete. A map showed that exam room HVAC and critical network patch panels were sharing the same UPS. There was no budget for a second UPS, so the team rearranged loads and created a manual transfer procedure. Months later, when the battery bank failed, staff executed the procedure and the clinic did not miss appointments.

That is exactly the kind of result building teams should be chasing: practical risk reduction that aligns with operations, not only long-range capital planning.

How to keep the map from becoming decoration

The episode is equally clear that a dependency map only works if it is embedded in operational routines. It should not live as a static artifact disconnected from change control and maintenance.

To stay useful, the map should be tied to:

• Change control reviews
• Work orders and maintenance tasks
• Tabletop exercises
• Ownership assignments
• Verification dates for unknowns

If a vendor changes firmware, modifies sequences, or alters an upstream dependency, the map owner needs to know. If someone is pulling a panel or making an infrastructure change, the map should be reviewed as part of the work. Without that discipline, maps go stale, and stale maps create exactly the false confidence they were meant to eliminate.

The business value is straightforward

For commercial properties and tenant environments, the business case is not abstract. When outages hit access control, HVAC, or critical network paths, tenants notice immediately. Leadership notices when disruptions become visible. Operations teams absorb the stress either way.

A modest mapping effort improves cross-trade coordination, reveals brittle single points of failure, and helps teams focus effort where it will prevent the most visible outages. It also builds trust. When tenants see quick, concrete fixes from a small mapping exercise, they become more willing to support larger resilience projects later.

If there is one takeaway from this episode, it is this: start small, verify what is real, and connect the map to ownership and action. Dependency maps are not paperwork for its own sake. They are one of the fastest ways to turn hidden building risk into practical resilience work. If your team has one hour this week, pick one critical asset and map the dominoes behind it. That hour may prevent the next outage people would otherwise remember.

To hear the full discussion and the examples behind this framework, listen to the episode at https://builtwiredsecured.com/episodes/dependency-maps-visualizing-building-outage-dominoes.