A practical brief / Chapter 01

Start with the decision

Define what the building should achieve, explore the possibilities and agree a strategy before selecting technology.

Updated 11 November 2026 · 7 minute read

Hands pointing and writing on architectural drawings spread across a table.

Agree the ambition and decision owner.

Start with the building’s purpose and the change you want to achieve. Then name the decision, its approver and its timing. A refurbishment tender, workplace move and investigation into overnight electricity use each needs a brief built around its outcomes.

Bring owners, occupiers and operators into the same conversation. The owner may be planning a refurbishment, the occupier shaping workplace services and the operator investigating recurring issues. A shared brief gives each perspective a place in the strategy.

Make the decision precise enough to assign. “We need a smart building” has no clear end point. “We need an agreed technology scope before the refurbishment tender is issued” does. Record the decision date, the approver and the people who can explain the operating consequences. A facilities manager may understand the support burden; an occupier may control a booking system; the landlord may control access to building data.

Involve the people who can approve investment, explain daily operation and confirm access to existing systems. Agree the decisions and commitments each person owns, then resolve responsibility gaps before procurement.

If a wider construction programme already has decision gates, put the technology decisions on that programme. RIBA's Plan of Work and Smart Building Overlay provide a reference for aligning the brief, specialist inputs and information exchanges with project stages. The client should be able to see when a late technology decision will affect procurement or occupation.

Describe clear, measurable outcomes.

Begin with a sentence someone can act on. A visitor should receive consistent instructions from invitation to meeting room. The facilities team should be able to investigate electricity demand outside occupied hours. The workplace team should understand the difference between reserved and used rooms.

Make the outcome specific: identify the people, floors, hours and information involved. Describe the normal journey and the ordinary exceptions. Use those details to form requirements that can guide selection, specification and delivery checks.

For an arrival experience, describe an invited visitor, an early arrival, a visitor without a working phone and a host who is unavailable. For operating information, name the question and the intended response: an operator sees persistent overnight demand, checks whether the data is current and investigates the relevant schedules with the responsible team. A feature list becomes much more useful when it describes a complete task.

Product pages can help identify possibilities. Smart Spaces: Smart Workplace features describes access, bookings and visitor services. That is a starting point for questions about the client’s required journey; it does not establish which features, integrations or licences suit a particular appointment.

Understand the starting point.

Existing systems, licences, networks and operating arrangements shape the available options. Some information may be well documented; other capabilities may be asserted but untested. Record what is known, who supplied it and what needs verification.

Match the assessment to the decision: a focused review of one service or a broader examination of several systems. State the coverage and required specialist inputs so the client understands the basis of the recommendation.

Use a short evidence register: the fact or claim, its source and date, its confidence, and what would resolve the uncertainty. An equipment schedule, a recent export, a witnessed demonstration and a supplier’s verbal assurance are different kinds of evidence. A missing interface licence may change the preferred option more than an attractive application screen.

Identify personal information early. Is the question about a count of people in a room, a named person’s movements or the validity of a visitor credential? These are different requirements. ICO: Data protection by design and by default explains the need to consider privacy throughout the lifecycle. The brief should identify the client’s privacy approver and the information actually needed, before selection narrows the options.

Ask whether the question needs a named individual at all. A count may answer a space-planning question while a visitor invitation needs an identity. The ICO's data-minimisation guidance makes purpose central to deciding what personal information to collect. Agree the privacy decision before adding identity to an otherwise anonymous measurement.

Plan how the outcomes will be checked.

Define the evidence for each requirement. Demonstrate a journey through agreed scenarios, check a dashboard’s coverage and completeness, and confirm an operational service has a named owner and tested fallback. Put the review points into the programme.

Plan checks at practical completion and in operation. The team can demonstrate that a system meets its specification before enough operating evidence exists to assess an environmental or workplace benefit. Give both stages an appropriate method and owner.

Write acceptance requirements as observable behaviour: the agreed room identifier appears consistently in the booking application and operating view; an unavailable source is marked as unavailable; an operator can trace a displayed value to its source and time. Let the client and appointed technical teams agree the relevant tolerances, test conditions and specialist criteria.

Use the launch demonstration to confirm the delivered behaviour. Evaluate changes in resource use or everyday experience over a suitable operating period, with reliable evidence and an agreed method.

Compare the routes to the outcome.

Explore the full range of options: improve existing configuration, add a targeted connection, carry out a focused measurement exercise or introduce a new platform. Compare each route against the same outcome, review period and operating responsibility.

For after-hours electricity, a current meter export and an operator's schedule may answer the first question. For an arrival journey, the obstacle may be a visitor policy or a missing host response rather than a reader. Establish which part of the problem a technology purchase would actually resolve.

Put the continuing commitment beside the purchase: subscriptions, interface licences, configuration changes, sensor maintenance, support and the time needed to investigate findings. BSRIA's life-cycle costing guidance considers capital, operating and end-of-life costs. For the client, the question is whether the chosen route remains worthwhile when those responsibilities are included.

Before proceeding, ask: what evidence would make us choose a smaller intervention, defer the purchase or decide that the existing service is sufficient? Put that test in the brief while the alternatives are still open.

Leave the workshop with a return brief.

Leave the workshop with a return brief: the consultant’s account of the agreed outcomes, strategy, scope, priority use cases, evidence gaps and next actions. Name the people who approve the requirements and provide specialist input.

Use the confirmed brief to develop specifications, assess proposals and review changes. It gives the team a clear reason to include each feature and a shared reference for checking delivery.

Keep priorities visible: essential for the agreed outcome, useful if affordable, and outside the current appointment. Record the next uncertainty to resolve, not every technology the market can supply. The return brief should make it possible to explain both why a feature is included and why another can wait.

A worked brief: understanding electricity after hours.

Illustrative scenario: an occupier wants to understand why a floor appears to use electricity after most people have left. The first decision is whether the existing information is sufficient to investigate, or whether limited additional measurement is justified. It is not yet a decision to replace the building platform.

The brief records the floor and meter boundary, the available time interval, operating hours, the distinction between observed presence and access events, and the person who will review the findings. It asks which systems remain legitimately active and which team can explain their schedules. A first output could be a data-availability review and a plan for a representative comparison.

Check whether the meter includes other floors or occupancy measurement covers only selected rooms. Resolve those boundaries before procuring another dashboard. The next appointment can then establish the investigation plan and any additional information required.

Questions to take into the first workshop.

  • What decision must be made, by whom and by when?
  • Which experience or operating task should improve?
  • What is the building doing today, and what evidence describes it?
  • Which systems and teams sit inside the appointment boundary?
  • What evidence would let the client accept the service?
  • What information or specialist input is needed before proceeding?

Sources and further reading.

Continue exploring

Make the connections explicit Technology strategy and roadmaps