How do you write a smart building strategy?

Weak smart building strategies fail in a familiar way: they read like a product list. A real strategy is a short, decision-focused document. It states what the building's technology must achieve, for whom and how success will be measured, and then sets the principles that design and procurement have to follow: which use cases take priority, how systems and data are structured, how security is handled, who owns the data and who will run the result. It is written before products are chosen and kept up to date as the design develops.

The best strategies confine themselves to decisions that bind later work, tie every proposed technology to a named outcome and user, and are approved by the client as the design team's reference, in the same way a brief is.

Brief, strategy, specification

The three documents are often confused. The brief describes what the building as a whole must provide. The strategy explains how technology will support that brief and sets the rules for doing so. The specification describes, in technical terms, what contractors must supply and how it will be tested. A strategy that names products has skipped a step; a specification written without a strategy ends up describing whatever one supplier happens to offer.

For an organisation with several buildings, the project strategy also has to fit a wider estate or asset management strategy. ISO 55000, the international overview of asset management, puts the alignment of asset management objectives with organisational objectives at the centre of the discipline. A smart building strategy that cannot say which organisational objective it serves will struggle to survive the first round of cost cutting.

What goes in it

The RIBA Smart Building Overlay to the Plan of Work describes a high-level smart building strategy prepared during Concept Design (Stage 2) and approved by the client. Its contents include user journeys, a use case matrix, business objectives aligned with use cases, prioritised technology selection, a systems list, smart building platforms, data schema and naming, and a response to the built asset security strategy. A strategy that will actually be used also needs an operating model and a measurement plan. A workable outline follows.

What separates a good strategy from a shelf document

Good strategies start from outcomes. "Reduce unplanned plant downtime" and "let tenants book and access shared spaces from one app" are outcomes; "install an IoT platform" is not. Every technology in the document should trace back to at least one of them.

They also prioritise honestly. A use case matrix in which every idea is marked high priority guides nobody, so use a simple scale and say plainly what is being deferred.

Data ownership is settled early. The RIBA overlay recommends considering an independent data layer, so that the client retains the data and it feeds applications, instead of sitting in, and potentially being controlled by, a single system provider. Whatever the choice, the strategy should record who owns the data, where it is stored and how it can be exported.

The people who will run the building are in the room. The overlay recommends forming a smart building user group that draws on the building operations and asset management team, the owner, incumbent suppliers, tenant representatives and occasional visitors such as maintenance staff and guests. A strategy written without the facilities team can produce systems nobody has time to use.

Scope limits are explicit. Fire and life-safety systems, for instance, follow their own regulatory design, so the strategy should state how, if at all, other systems may interact with them, subject to the fire engineer's agreement.

And they are short. Ten to twenty pages that the client has read and approved are worth more than a long document nobody consults; technical detail belongs in the specifications.

Keeping it alive

A strategy is worth the paper only if people go on using it. Review it at the end of each design stage, record the decisions that change it, and check contractors' proposals against it. After occupation, the measures in section 10 show whether it worked, and the lessons feed the next project.