Show Notes
A local change can become a building-wide problem
A tenant was nearly ready to open when a final walkthrough revealed that a new door had changed a shared access workflow. Construction was close to complete, the wall and ceiling work were finished, and the schedule was tight. Yet one basic question had not been answered: who owned the fix?
This episode examines why that situation is so common in tenant fit-outs. A request to move a door, add a network connection, divide a suite, or close a ceiling can appear small when viewed only as a construction task. But commercial buildings operate through connected services: connectivity, pathways, power, access control, security workflows, sensors, automation, maintenance practices, and support responsibilities. A change inside one suite can affect systems, people, and processes beyond that suite.
The tenant change test is a practical pre-change conversation designed to expose those assumptions before design is fixed or construction closes off access. It is not meant to create a large approval process. It is a lightweight way to determine whether a request is truly local or only appears local.
The boundary is more than a location
One of the first assumptions teams make is that everything inside the tenant space is a tenant concern and everything outside belongs to the building. The episode explains why that distinction is often too simple.
- A device may sit inside a tenant suite while its power pathway, network service, control logic, or maintenance responsibility belongs elsewhere.
- A cable serving one suite may travel through a shared pathway or building telecommunications room.
- A tenant-installed door may create access events that feed a shared security workflow.
- A sensor may remain operational while a new room layout changes the conditions it was intended to measure.
Instead of asking only who owns a device, teams should ask what it connects to, who depends on it, who maintains it, and who responds when it behaves unexpectedly. The physical location of a change does not automatically identify every party that needs to be involved.
Use the tenant change test before the design is locked
The discussion offers a simple framework for screening tenant changes. Before construction decisions are finalized, teams should identify the boundary, expose shared dependencies, and define how the completed result will be operated, supported, tested, and reversed if necessary.
For the fictional suite renovation used in the conversation, the tenant divides a large suite into smaller rooms, adds a door, moves a ceiling, and requests a new network connection. Each element creates a different question:
- Does the new connection use a shared pathway or telecommunications room?
- Is supporting power available and accessible?
- Can the connection be inspected and repaired after finishes are complete?
- Could the new door affect access events, alarms, visitor procedures, or routine service visits?
- Will the ceiling change cover a sensor, change airflow, block a panel, or alter an existing operating sequence?
The objective is not to assume that every change needs a committee. It is to give the right people a short opportunity to identify consequences while options still exist.
Start with the path, not the outlet
When a tenant requests connectivity in a new room, the visible outlet is only the final point in a longer support path. The episode emphasizes starting with where the connection travels rather than focusing only on the outlet on the wall.
A connection can work on opening day and still become an operational problem later. The pathway may be inaccessible, labeling may be unclear, or equipment may be surrounded by finishes that make service difficult. A contractor can complete the technical connection, but the building may be left with a service that no one can safely inspect, repair, or support six months later.
That is the difference between technical completion and operational success. Reliability depends on disciplined maintenance, and maintenance depends on practical access. The project team should ask not only whether the new space can be connected, but whether the building can support and maintain that connection consistently without creating trouble for other occupants.
Small construction changes can create permanent workflows
A new door may require modest construction effort, but its operational effect can be much larger. It can change how people move through a space, how staff respond to an access issue, how visitors are handled, and how routine service is performed.
The conversation makes an important distinction: proportional review does not mean no review. Treating every outlet move or door adjustment as a major committee meeting could discourage teams from involving facilities. But skipping the conversation altogether creates a different risk. A lightweight screen with five focused questions can prevent weeks of rework.
For a door change, teams should understand what people experience when the door works normally, when it is unavailable, and when someone needs help. A component may pass a technical test while the actual workflow fails. Even a small adjustment can create a lasting expectation that the building will support a new workflow.
Automation assumptions can survive after the room changes
Ceiling and partition changes can also create failures that are difficult to spot. A sensor may continue reporting normal values even though the renovated space no longer matches the assumptions behind its operating sequence. The sensor may be covered, airflow may change, or equipment may be placed into a different condition.
Those conditions can lead to comfort complaints, wasted energy, or a facilities team chasing symptoms rather than identifying the changed assumption. Nothing may look obviously broken: the equipment is powered, the screen looks normal, and the room still feels wrong.
Before changing the physical environment, teams should understand what the existing system believes that environment is. Service access belongs in the same conversation. If a renovation blocks a panel, changes a route, or requires a new escort process, routine work can become delayed and disruptive for both building staff and tenants.
Bring the right roles into the conversation
Before the design is finalized, the episode recommends involving the property or owner representative, facilities, the tenant, and the contractor. IT or security should be included when the change touches their services.
- The tenant explains the desired outcome in plain language.
- Facilities identifies maintenance and operating impacts.
- The property team clarifies responsibility.
- IT or security explains the implications for their service.
- The contractor helps translate requirements into a workable installation.
The group should ask what stays the same, what changes, and what must be verified before occupancy. They should also discuss the day-one contingency: if a new service is not ready, can work be staged, is there a temporary operating method, and can the prior condition be restored?
A schedule that relies on one untested assumption is not a dependable schedule. It is a hope with dates attached.
Test real experiences and document decisions early
Testing should reflect the real operational scenario. For a door, verify the expected user flow and the response when access is unavailable. For a changed room, verify how the environment performs during normal use. For connectivity, confirm not only that service works but also that the support path is understood.
Finally, record the decision while it is still fresh. The note does not need to be large. It should identify who approved the change, what dependency was found, what was tested, and who owns the next action. A short operational note created during the project can be more valuable than a perfect record produced after the space opens and the reasoning has been forgotten.
Put the tenant change test on the agenda before the next fit-out meeting: Where is the boundary? What else depends on the affected service? What is the operational impact? How will the change be tested or reversed? What needs to be documented for the next person?
The Tenant Change Test: How to Find Hidden Building Dependencies Before They Delay a Fit-Out
Tenant improvements often begin with language that sounds simple: move a door, add a connection, divide a suite, close the ceiling. Each request may be reasonable. Each may also affect a set of assumptions that sit between the tenant space and the building systems that support it.
The problem usually does not appear when the request is made. It appears near the end of the project, when finishes are complete, opening day is approaching, and someone realizes that the work changed a shared access workflow, blocked a service path, altered an automation condition, or created an unclear support responsibility. At that stage, even a modest fix can become schedule pressure, rework, and an operational surprise.
The tenant change test is a practical way to find those hidden dependencies early. It is not a process designed to slow construction. It is a short, proportional conversation that helps property teams, facilities, tenants, contractors, IT, and security determine whether a change is genuinely local or whether it affects a shared service that requires coordination.
Why location does not define responsibility
A common assumption is that a system inside a tenant suite belongs entirely to the tenant, while systems outside the suite belong entirely to the building. In practice, the boundary is rarely that clean.
A device may be physically located within a tenant space while its power pathway, network service, control logic, or maintenance responsibility extends beyond the suite. A cable serving a tenant may travel through a common pathway or a building telecommunications room. A door installed as part of a tenant fit-out may create access events that affect a shared security workflow. A sensor may remain in the same ceiling while a new room configuration changes what the sensor is actually measuring.
That is why the first question should not be only, “Who owns this device?” A more useful sequence is: What does it connect to? Who depends on it? Who has to maintain it? Who responds if it behaves differently from the plan? Can that person still reach the service after the renovation is complete?
Those questions reveal the real operational boundary. If one party uses a service, another supports its pathway, and a facilities or security team responds when something goes wrong, the change is shared whether or not the drawing labels it that way.
Use a lightweight screen, not a large approval process
Teams can make two opposite mistakes. One is to treat every small change as if it requires a lengthy committee review. The other is to decide that a small construction effort does not deserve any operational review at all.
Neither approach is effective. A major process for every outlet move or door adjustment can lead project teams to stop involving facilities. But skipping the screen creates conditions for costly late discoveries. The better approach is proportionality: a short discussion with the people who can identify whether the request touches a shared service.
For a tenant change, five questions provide a useful starting point:
- Where is the boundary between the tenant request and the shared service?
- What other systems, people, or workflows depend on the affected service?
- What will change in daily operations, maintenance, and support?
- How will the completed change be tested, and what is the recovery path if it does not work as planned?
- What decision needs to be documented for the next property, facilities, or service team?
The depth of the review can change based on the project. The questions remain valuable for both a small renovation and a major fit-out.
For connectivity, start with the path rather than the outlet
When a tenant asks for a network connection in a newly created room, it is tempting to focus on the outlet location. But the outlet is only the visible end of a longer path.
Teams should ask where the connection travels, whether it uses a shared pathway or building telecommunications room, whether supporting power is available, and who can inspect or repair the connection later. A network connection that works on opening day is not automatically a connection that can be supported safely and consistently after occupancy.
A contractor can complete a connection and leave behind an installation that appears successful. Yet the pathway could be inaccessible, equipment could be difficult to reach after finishes are complete, or labeling could leave future service personnel uncertain about what they are supporting. The result is a technical success that can become an operational failure months later.
Reliability starts with disciplined maintenance, and maintenance starts with practical access. The goal is not only to connect the space. It is to ensure that the building can support and maintain that connection without creating trouble for the tenant or other occupants.
A new door can change more than the room layout
Door changes offer another useful example. The construction work may be straightforward, but the operating impact can reach much farther. A door can affect how people move, how staff respond to an access issue, how visitors are handled, when a routine service visit can occur, and how security workflows function.
The review does not need to become dramatic. It does need to address normal operation, service unavailability, and the experience of a person who needs help. In other words, test the workflow rather than only the hardware.
A component can pass its test while the real process fails. A door may lock and unlock as intended, but the expected user flow may be unclear when access is unavailable. A small adjustment can also create a permanent expectation that the building will support a new workflow. That expectation should be understood before the work is complete, not discovered during an urgent call after opening.
Physical changes can invalidate automation assumptions
Ceiling and partition work can create less visible problems. Consider a sensor that remains powered and continues reporting normal values after a large suite is divided into smaller rooms. The physical environment may no longer match the assumptions behind the system’s operating sequence.
The sensor could be covered. Airflow could change. Equipment could move into a different condition. The outcome may be comfort complaints, wasted energy, or a facilities team spending time chasing symptoms instead of finding the underlying changed assumption.
These are difficult problems because nothing may appear to have failed. The equipment is alive. The control screen looks normal. The room simply does not behave as people expect. Before changing the physical environment, teams should understand what the existing system believes that environment is.
Service access must be considered at the same time. If the renovation blocks a panel, changes a service route, or requires a new escort process, routine maintenance may no longer be possible as planned. Tenants experience this directly when a simple service visit becomes disruptive or delayed.
Bring in the people who can answer operational questions
Before design is finalized, bring together the property or owner representative, facilities, the tenant, and the contractor. Add IT or security when the change affects their service.
Each role has a different contribution. The tenant can describe the desired outcome in plain language. Facilities can explain maintenance access and operational impact. The property team can clarify responsibility. IT or security can identify shared dependencies. The contractor can help convert the operational requirements into a workable installation.
The conversation should identify what stays the same, what changes, and what must be verified before the space is occupied. It should also address what happens if the new service is not ready on day one. Can the work be staged? Is there a temporary operating method? Can the prior condition be restored?
That is not pessimism. It is schedule protection. A schedule that depends on an untested assumption is not a dependable schedule.
Test the experience, then document the decision
Testing should reflect real use. For a new door, verify normal movement through the space and the response when the service is unavailable. For a newly divided room, confirm how the environment behaves under normal use. For connectivity, confirm that the service works and that the future support path is understood.
After testing, record the decision while the details are still fresh. The record can be short, but it should state who approved the change, which dependency was identified, what was tested, and who owns the next action. This is not paperwork for its own sake. It protects the next property or facilities team from having to rediscover why a ceiling, door, sensor, pathway, or workflow was handled a certain way.
The tenant change test is simple: locate the boundary, expose the shared dependency, and coordinate the change through testing, rollback planning, and documentation. Before the next tenant change meeting, place those questions on the agenda. The result is not a slower project. It is a faster path to opening with fewer surprises and clearer responsibility.
For a practical discussion of this approach, listen to this episode of Built, Wired & Secured.