Can the People Responsible for Your Façade Actually Reach It?
A façade access and maintenance strategy can look complete on paper yet still fail in practice. A bold statement, but unfortunately, we are seeing it happening at an alarming rate.
When we think about façade access, or try to explain it to those unfamiliar with the built environment, people often describe it as a system designed for window cleaning alone. The problem is that, increasingly, this is exactly what façade access is becoming.
But what happens when a façade engineer needs to investigate water ingress? When a fire engineer needs to carry out intrusive investigations as part of a Fire Risk Appraisal of External Walls (FRAEW)? Or when hands-on access is needed to assess potentially loose cladding?
Façade warranties typically require building owners to clean, inspect and maintain systems in line with manufacturer specifications. Without suitable access or adequate maintenance records, owners may struggle to demonstrate compliance when defects arise. This can weaken warranty claims and lead to significant investigation and repair costs.
We regularly encounter this in expert-witness work involving water ingress, material failure, defective installations and concerns over falling components. At this point, access is no longer just a maintenance detail; it becomes part of the dispute.
Designing façade access strategies for more than window cleaning
BS 8210:2020 encourages a planned, risk-based approach to building maintenance, including periodic inspection of the façade fabric. An access solution that reaches glazing but not cladding, joints, fixings, or architectural features often cannot facilitate these inspections.
A robust façade access strategy must consider cleaning as its primary objective, but it should also account for inspection, reactive repair, intrusive investigation and eventual replacement as part of the building’s whole-life maintenance requirements.
One recurring challenge we face as designers is persuading clients of the need for collective protection access systems such as Building Maintenance Units (BMUs) and suspended cradles, which allow multiple specialists to work safely at height.
The challenge is that these systems often have a higher capital cost and require space, structural support and client buy-in. They can also impact the overall visual appearance the design set out to achieve. However, project teams can narrow the design brief too early, trying to hide access equipment completely before properly considering its functionality and discussing options for suitable concealment and integration.
Aesthetics matter, but they should not drive the façade access strategy at the expense of functionality. When visual impact outweighs coverage, usability and future maintenance needs, designers are left to deliver the best solution permitted by the constraints, not necessarily the best solution for the building.
Is rope access always the answer?
Rope access highlights this tension. When carried out by trained technicians, it can be an effective and safe method for cleaning and certain maintenance tasks.
However, many façade and fire engineers, building inspectors, and surveyors are not IRATA-qualified rope access technicians. If a building relies solely on abseiling for access, the specialists tasked with diagnosing, remedying and repairing façade defects may not be able to reach them directly.
In such cases, the project may need alternative systems such as MEWPs, scaffolding, or temporary suspended cradles. Introducing these systems after completion can prove costly and disruptive, while roof layouts, ground conditions or public realm constraints can sometimes make them impractical altogether.
Designing façades for long-term maintenance
The real question should never be limited to:
“How will the windows be cleaned?”
It should be:
“Can every part of the façade be safely inspected, maintained, repaired and ultimately replaced by the people who will actually do the work?”
If the answer is no, has the building truly been designed for maintenance or has the problem simply been designed out of sight?