A practical brief / Chapter 03

Prepare for everyday operation

Prepare people to use and support the service, then review its performance against the outcomes agreed in the strategy.

Exposed white pipes, conduits and wiring across a building ceiling

Prepare the operating team from the start.

Plan handover around the people who will run the service. Give them a clear account of what was delivered, the requirements demonstrated, open actions and the support available. Start that preparation during the project.

Name the service owner, system administrator, support supplier and information owner. Agree operating hours, support, licence renewals and maintenance. Record warranty and ongoing support as separate commitments, with the owner of each made clear.

Involve operators while requirements and delivery arrangements can still change. Agree who checks the information, what they can decide, when specialists are needed and how support works outside normal hours. Give investigation and response a place in the operating scope.

Plan for use from the start. BSRIA's Soft Landings approach connects project decisions with operation and aftercare. The Department for Education's Soft Landings Guide shows a sector-specific application. Agree the appropriate training, support and review activities in the client's own appointment and delivery programme.

Rehearse failure and recovery.

Prepare for ordinary interruptions: a sensor stops reporting, a credential expires, an application is unavailable or a gateway needs restarting. Agree how the team detects each issue, continues the service and obtains help.

Include agreed failure and recovery scenarios in the delivery checks. Capture the service behaviour and information available to the operator. Have the responsible specialists define safety, security and control requirements for those tests.

Rehearse an exception with the people expected to deal with it. For an unavailable room-occupancy feed, can they distinguish a sensor fault from a connector problem? Does the application show “unknown” rather than confidently presenting an old value? Can the service continue under an agreed fallback while the responsible team investigates?

Agree failure and recovery tests with the appointed specialists, including their authorisation, operating impact and evidence requirements. Tests affecting security, life-safety or building control belong within the responsible teams' approved procedures.

Make the handover usable.

The operating team needs current system and interface records, configuration information, authorised access arrangements, support contacts, training and relevant test evidence. Keep passwords and other credentials in the approved secure system, with custody recorded separately.

Give outstanding defects an owner, treatment and review date. Present demonstrated requirements, limitations and open actions together so the authorised client can make an informed acceptance decision.

Organise handover around tasks rather than a folder of files: how to add an approved user, recognise stale information, locate an interface record, report a fault and understand a limitation. Training should use the configuration being handed over, with concise reference material that remains available afterwards.

A readiness record should separate demonstrated requirements, open defects, accepted limitations and actions still due. Each open item needs an owner and a review date. Licences, support periods and renewal responsibilities should be visible to the client; credentials remain in the approved secure system, not a handover appendix.

Plan how the strategic outcomes will be measured.

For each intended improvement, agree the measure, source, baseline, review period and interpretation. Record influences such as operating hours, occupancy and measurement coverage. These give the first performance review a clear basis.

Review technical performance alongside people’s experience. Ask whether users understand the information and whether the operating team can act on it. Use those findings to prioritise the improvement plan.

Set a review question and a suitable period before collecting more data. For overnight electricity demand, check the operating schedule, meter boundary, missing readings and whether cleaning, equipment or occupancy changed. A single quieter day is not a reliable measure of the effect of a technology decision.

The US Department of Energy: Measurement and Verification Options describes approaches that account for relevant changes when assessing savings. The method must suit the actual project; this guide does not prescribe a savings calculation. Where formal verification is required, agree the scope and competent specialist input before making a performance claim.

Make performance reporting traceable.

Organise assessment evidence around the applicable scheme, route, scope and appointed assessment team. Technology can support the required records; the scheme’s assessment process determines the building’s rating.

Use the same discipline in management reporting: state coverage, collection method and known gaps, then give the next action an owner and a date.

Separate viewing information from improving performance. The US Department of Energy: Energy Management Information System Capabilities describes capabilities including interval analysis, fault investigation and measurement and verification. A useful view supports an operating process; it does not itself establish that a fault was corrected or a saving achieved.

Retain enough information to explain a reported number: source and coverage, reporting period, exclusions, quality checks, known gaps and the person who approved its use. If a certification or assessment is intended, confirm the scheme and assessor’s evidence requirements rather than assuming one dashboard meets every scheme.

Give each alert a response.

A dashboard should make the next action clearer. For an unusual water pattern, name who checks the reading, who investigates the location and how an urgent issue is escalated. For persistent electricity demand, identify the operator who can explain the schedule and the team authorised to make a change.

Indoor conditions need the same discipline. If a room's CO₂ reading rises, check the occupied period, the sensor's position, calibration requirements and data freshness before interpreting the pattern. HSE guidance explains why monitor location and repeated observations matter. NIST's work on indoor CO₂ metrics explains the limitations of a single concentration as an overall measure of ventilation or indoor air quality.

Assign interpretation and response for each measurement. Carbon dioxide (CO₂), particles, volatile organic compounds (VOCs), temperature and humidity describe different conditions. Keep the measures and their meaning clear within the operating process.

At the first review, check which alerts led to action, which remain open and which arose from missing or stale information. Use the findings to choose the next improvement: coverage, response procedures or alert logic.

A first review that leads to action.

Illustrative scenario: an operating team receives a new occupancy-and-electricity view. The first review finds a persistent evening load, a gap in one data feed and a dashboard account with no clear owner. These are three separate actions: investigate the load with the relevant technical team, resolve the information gap and assign service ownership.

Record what was observed, how reliable the evidence is, who will act and when the decision will be revisited. At the next review, distinguish “investigation completed”, “configuration changed” and “improvement evidenced”, with the supporting record for each.

Good Buildings’ role is agreed in the appointment: clarify requirements, coordinate the evidence and help the client make the next decision. Detailed engineering, installation, specialist commissioning, security approvals and operation remain with the appointed responsible parties.

Questions before service entry.

  • Who owns the service, information and support arrangements?
  • Which requirements have been demonstrated, and what remains unresolved?
  • Can the team recognise a fault and use an agreed fallback?
  • Are training, licences and current records available?
  • Which baseline and review method will support performance claims?
  • Who will prioritise the improvements identified in early operation?

Sources and further reading.