Show Notes
When “Critical” Is Not a Priority
A building can have many systems that matter: access control, tenant connectivity, automation controls, equipment monitoring, and the operational processes that keep occupants moving safely. The problem begins when every team labels its own system “critical” without agreeing on what that label means in the moment.
This episode examines a realistic Monday-morning disruption in a full 20-story office building. Access is working at some entrances but not others. Tenant connectivity is dropping across several floors. Building automation controls have gone quiet, while temperatures remain stable. With one facilities engineer on site and multiple teams demanding attention, the question is not which alarm looks most serious or which team is loudest. The practical question is: what becomes unsafe, unusable, or much harder to recover if the team waits?
Critical to What?
The conversation separates technical importance from operational consequence. A system may be technically important because other systems depend on it. Another may be operationally important because occupants cannot work without it. A third may create serious business consequences even when its early failure is quiet.
- Access control may affect controlled entry, exit, movement, and security visibility.
- Connectivity failures may affect hundreds of occupants and interrupt tenant operations immediately.
- Automation outages may represent a loss of visibility, a loss of control, or an emerging equipment problem.
- The same system can require a different response depending on current building conditions.
“Critical” is therefore a warning that deserves attention, not a ranking that tells an operator what to do first. Teams need to finish the sentence: critical to occupant comfort, equipment protection, controlled movement, tenant operations, or recovery?
Use Current Consequences, Not System Names
In the episode’s scenario, the first action is to establish whether people can enter, exit, and move through the building in a controlled way. If access can be managed manually for a limited period, it may be containable. The team must also verify actual building conditions rather than assume a quiet automation screen means equipment is failing.
A loss of automation visibility is not automatically the same as a loss of control. If temperatures are stable and equipment is behaving normally, the team may have time to focus technical effort on the widespread connectivity issue. But if field readings show temperatures rising or equipment behavior worsening, the automation issue may move ahead of connectivity because the available recovery options can shrink with every minute.
The lesson is straightforward: the response order should be based on current consequence. A useful priority map does not permanently place one system above another. It includes the conditions and trigger points that change the order.
Shared Input, Accountable Decisions
Property management, facilities, IT, security, and tenant teams each see a different form of impact. Property management sees continuity and disruption. Facilities sees safe operation, equipment condition, staffing, and workarounds. IT sees connectivity and technical dependencies. Security sees access, movement, and visibility. Tenants know what work stops when a service degrades.
That broad input is necessary, but it cannot become shared indecision. The episode argues for gathering perspectives together and then making one accountable operating decision. A priority map should help someone act at 2 a.m., not simply produce an attractive planning document where every line says urgent.
Make the Map Simple Enough to Use
The recommended approach is not a complicated scoring model. Use plain-language questions that expose assumptions and guide action:
- Who is affected?
- How quickly does the consequence become serious?
- What becomes harder to control, protect, or recover?
- What recovery options are actually available?
- Who owns the next action?
- What condition would change the response order?
- When should affected people receive an update?
Classifying an issue as immediate, near-term, or manageable for now can be more useful than pursuing mathematical precision. The goal is not to create a perfect ranking. It is to make assumptions visible before pressure arrives.
Workarounds and Redundancy Have Limits
A manual workaround is not free simply because it exists. A process that requires three trained people for six hours creates fatigue, communication gaps, and less capacity to respond to the next problem. Teams should document who performs the workaround, how long it can be sustained, and what it costs operationally.
Redundancy also does not erase consequences. It only buys time when the backup is available, maintained, understood, and usable. A backup path that has never been practiced may look strong in documentation but fail to provide the expected response window during a real disruption. Redundancy changes the clock; it does not remove the need to make a priority decision.
A 30-Minute Planning Exercise
Before the next disruption, bring property management, facilities, IT, security, and affected business teams together for a focused 30-minute session. Choose one realistic scenario rather than attempting to model every possible failure. Ask who is affected at 15 minutes and at four hours. Identify what becomes harder to control, protect, or recover. Name the real workaround, its staffing requirement, and the condition that would change the order of response.
If teams rank the scenario differently, do not smooth over the disagreement. Ask what each group is trying to prevent. That discussion reveals the trade-offs a building needs to make when attention, staffing, maintenance time, and recovery capacity are limited.
The objective is not to neglect lower-ranked systems. Every system still needs responsible management. Prioritization makes limited attention honest and turns recovery into a deliberate sequence rather than a contest between competing alarms.
When Every Building System Is Critical, Nothing Is Truly Prioritized
Modern commercial buildings depend on a growing number of systems that influence safety, productivity, tenant experience, equipment protection, and business continuity. Access control governs movement. Network connectivity supports tenant operations. Building automation provides visibility and control over equipment. Security systems support awareness. Facilities teams manage the physical environment that makes the rest of the building usable.
It is reasonable for the people responsible for these systems to describe them as critical. The problem is that “critical” is often used as a label rather than a decision. When several systems degrade at once and staffing, time, or recovery capacity is limited, a building cannot respond to every alarm with equal urgency.
A useful operating plan answers a harder question: what becomes unsafe, unusable, or much more difficult to recover if action waits?
A Familiar Disruption Scenario
Consider a full 20-story office building on a Monday morning. Access works at some entrances and fails at others. Tenant connectivity is dropping across several floors. The building automation controls have gone quiet, but temperatures remain stable. One facilities engineer is available while multiple teams insist their issue is critical.
Choosing a response based on the loudest complaint, the most alarming screen, or a permanent system ranking is risky. The building team needs to understand the immediate operational condition.
Can occupants enter, exit, and move through the building in a controlled way? Can staff manage access manually for a short period? Are equipment readings stable, or are temperatures rising? How broad is the tenant connectivity impact? Which condition becomes materially worse in 15 minutes, four hours, or by the next business day?
Those questions turn an argument about system ownership into an operating decision.
Technical Importance Is Not the Same as Operational Consequence
A system can be important in several different ways. A technical dependency may affect multiple downstream systems. A tenant-facing service may immediately interrupt work. A quiet failure may create an escalating risk that is not obvious at first. None of those conditions automatically establishes first priority.
For example, a silent building automation screen can mean several different things. It may mean the team has lost visibility while equipment continues operating normally. It may mean the team has lost control. Or it may indicate that equipment is moving toward a condition nobody can see clearly. The correct response depends on actual field conditions, not the name of the system that generated the alert.
If field readings show stable temperatures and normal equipment behavior, the team may be able to monitor the automation condition while focusing the next technical effort on degraded connectivity affecting most occupants. If temperatures are climbing and equipment behavior is worsening, the automation problem may need to move ahead because the opportunity to protect equipment and preserve recovery options is shrinking.
The priority is not fixed. The consequence is what matters.
Bring the Right Perspectives Together
Buildings operate across organizational boundaries. Property management understands tenant disruption and continuity concerns. Facilities understands safe operation, equipment condition, staffing, and manual processes. IT understands connectivity and technical dependencies. Security understands access, controlled movement, and visibility. Tenant teams understand which work stops when a service is impaired.
No one group sees the entire consequence on its own. But broad participation should not become broad indecision. A planning process needs input from every relevant perspective, followed by one accountable operating decision.
This distinction is essential. A map that says every system is urgent leaves the on-site engineer with no guidance. A useful map supports action under pressure. It clarifies who owns the next action, what conditions should be monitored, what would change the order, and when affected people need an update.
Build a Priority Map Around Conditions and Triggers
Many organizations make prioritization harder than necessary by trying to construct a complex scoring model. The episode makes the case for a simpler, more usable approach. Start with plain-language questions:
- Who is affected by this condition?
- How quickly does the consequence become serious?
- What becomes harder to control, protect, or recover if the team waits?
- What workaround exists in reality?
- Who must perform that workaround?
- How long can the workaround be sustained?
- What condition would change the response order?
Classifying issues as immediate, near-term, or manageable for now can help teams make their assumptions visible. The goal is not mathematical precision. It is a practical, shared decision framework that can be used during a noisy and confusing event.
Trigger points are especially valuable. They prevent a priority map from becoming a permanent podium on which one system always wins. Occupancy, weather, staffing, equipment condition, available workarounds, and the duration of an outage can all change the correct response. A loss of automation visibility is different from loss of control with worsening equipment behavior. An access issue that can be managed by staff is different from one that prevents controlled movement. A backup network path that has been tested is different from one that exists only in a document.
Do Not Treat Workarounds as Free
Manual fallbacks often look reassuring in planning discussions. But they have a real cost. A workaround requiring three trained people for six hours can create fatigue, communication gaps, and reduced capacity to manage the next failure. It may preserve operations temporarily, but it consumes people and attention.
That means the fallback must be evaluated as an operating condition, not treated as a box checked in a continuity plan. Teams should know who can perform it, what resources it requires, how long it can be sustained, and what breaks when that capacity is consumed elsewhere.
The same principle applies to redundancy. Redundancy buys time only if it is available, maintained, understood, and usable. A backup path that has never been practiced can produce a false sense of resilience. A well-maintained backup that provides four hours instead of 15 minutes changes the response window, but it does not eliminate the business consequence or the need for disciplined action.
Communication Is Part of the Response
When connectivity affects hundreds of occupants, the technical repair is only part of the work. Property management needs to communicate what people can expect. Silence creates a second problem: occupants create their own explanations while facilities and IT teams lose time responding to uncertainty.
A priority map should therefore be a communication tool as well as a technical one. It should identify who is working the immediate issue, who is monitoring the secondary condition, what would trigger escalation, and when the people affected will receive an update. This gives teams a coherent way to act without pretending every issue has been solved at once.
Keep the Map Current
Priority maps become dangerous when organizations treat them as permanent. Buildings change after renovations. Occupancy changes. Operating hours change. Staffing changes. Equipment is added, modified, or retired. A priority that made sense last year may no longer reflect current risks or available recovery options.
Siloed calendars create another problem. Facilities may schedule around equipment needs, IT around connectivity work, and property management around tenant activity. Each schedule can be reasonable independently while the combined effect produces an unnecessarily difficult day for the building. Coordinated planning helps reveal those conflicts before they become disruption.
Prioritization also should never be interpreted as permission to neglect lower-ranked systems. Every system still deserves responsible management. Ranking simply makes the trade-offs visible when limited attention must be directed somewhere first. After the first issue is stabilized, the next issue may become the highest priority. Recovery is a sequence, not one heroic repair.
Start With One 30-Minute Conversation
A practical first step is to choose one realistic scenario and bring together property management, facilities, IT, security, and the affected business teams. Ask who is affected after 15 minutes and after four hours. Ask what becomes harder to control, protect, or recover. Identify the actual workaround, the people it requires, its sustainable duration, and the assumptions that would change the response order.
If teams rank the problem differently, do not erase the disagreement to create a neat document. Ask what each group is trying to prevent. That is where the useful planning begins.
For more discussion on making better operational decisions across building technology, listen to this episode of Built, Wired & Secured. The goal is not to make every system seem less important. It is to give the people responsible for the building a clear, usable way to respond when everything cannot receive equal attention.