Most building owners can tell you what they want from a new facility. Far fewer have written it down in a form a design team can design to, a contractor can build to and a commissioning agent can test against. That written form is the Owner's Project Requirements, or OPR. When it's missing or vague, the first time anyone checks whether the building does what the owner needed is at turnover, when the answers are expensive.
This guide explains what goes into an OPR, how it links to commissioning under ASHRAE Guideline 0, how it differs from a functional program, and how to keep it current so it's still useful on the day the building opens.
What the OPR is, and what it isn't
ASHRAE Standard 202 defines the OPR as a document that sets out a project's requirements and the expectations for how the building will be used and operated. An OPR isn't a wish list of features. It describes the outcomes the owner needs and how the building will actually run once the design team and contractor have gone home.
A good OPR answers questions such as:
- Who will occupy the building, during what hours, and how will that change over time?
- What indoor conditions must be held, with what tolerances, in which spaces?
- What energy, water and sustainability targets apply, and how will they be measured?
- Who will operate and maintain the systems, and what skills and tools will they have?
- Which systems need the highest confidence that they'll work, and why?
- What does success look like one year after occupancy?
It isn't a design document. It shouldn't specify a chiller model or a duct size. Those decisions belong to the design team, and they're recorded in a separate document, the Basis of Design (BOD), which explains how the design meets the OPR.
The commissioning link: why ASHRAE Guideline 0 starts here
ASHRAE Guideline 0-2019, The Commissioning Process, describes commissioning as a process for verifying that a facility and its systems meet the OPR. Its scope runs from predesign through occupancy and operation. Commissioning isn't a test bolted on at the end. It's a quality process that uses the OPR as its yardstick from the start.
That has a practical consequence owners often miss. If there's no OPR, the commissioning agent has nothing to verify against except the contract documents. They can confirm the building was built as drawn. They can't confirm it was drawn to meet the owner's needs. A perfectly installed system that was designed to the wrong requirement will pass functional testing and still fail the occupants.
In Canada, CSA Z320, Building commissioning, covers commissioning for new construction and renovations. Its stated aim is to document that a building meets the basis of design and the owner's operational requirements. Whichever standard your project references, the logic is the same: the owner's requirements come first, and everything downstream is checked against them.
What goes into an OPR
The Whole Building Design Guide's commissioning resources list typical OPR contents. Adapted for a commercial, retail or institutional owner, a workable OPR usually covers:
- Project objectives and background. Why the project exists, the business case in a paragraph, the size and location, and the expected life of the building.
- Users and operations. Occupancy, hours, seasonal peaks, future flexibility and any special uses such as food service, labs or data rooms.
- Performance targets. Energy and water goals, certification targets if any, and the metric each will be measured by.
- Indoor environment. Temperature, humidity, ventilation, lighting and acoustic requirements by space type, with setpoints and acceptable tolerances.
- Codes, standards and owner standards. The building code and referenced standards, plus the owner's own design standards and preferred equipment lists.
- Operations and maintenance. Staffing, maintainability, access, spare parts, training and the documentation operators will need.
- Commissioning scope. Which systems are commissioned and to what level of rigour, depending on how critical each one is.
- Budget and schedule constraints. Where cost or time limits will shape choices, stated honestly.
- Success criteria. Measurable tests of whether the building meets the requirements after handover.
A Kentucky state guideline adds a useful point: the OPR should carry the functional and performance requirements found in the architect's program, but in measurable form, with benchmarks and success criteria. "Comfortable offices" is a hope. "Office spaces held at 22°C plus or minus 1°C during occupied hours" is a requirement you can test.
Functional program vs OPR vs Basis of Design
Owners in Ontario often already have a functional program, and it's tempting to treat it as the OPR. They overlap, but they do different jobs.
A functional program describes the spaces the organization needs: rooms, areas, adjacencies, headcounts and equipment. It's mostly about quantity and relationships. It's essential for space planning.
The OPR describes how the building must perform and be operated. It picks up the program's key requirements but adds the performance, operating and maintenance expectations that a program rarely covers. The University of Michigan's design guideline, for example, draws the OPR's key concepts from the program and attaches room data sheets as an appendix to the OPR.
The Basis of Design is the design team's response. It records their assumptions, calculations, system selections and operating conditions, and it's formatted to answer the OPR point by point. Together, the OPR and BOD describe the project's design intent.
The split keeps accountability clear. The owner owns the requirements; the design team owns the solution.
View the data
| Document | Written by | Describes | Typical timing | Used to check |
|---|---|---|---|---|
| Functional program | Owner or programmer | Spaces, areas, adjacencies | Before design (feasibility) | Space planning and areas |
| OPR | Owner, with a Cx facilitator | Performance, use and operation | Predesign; updated every phase | Design reviews and commissioning |
| Basis of Design | Design team | Assumptions, calcs, system choices | Schematic design onward | That the design meets the OPR |
Who writes it, and who owns it
Practice varies. WBDG says the owner or owner's representative originates the OPR and gives final acceptance, with the commissioning provider usually facilitating workshops that include the design team, operators and end users. Some institutional guidelines hand drafting to the architect or engineer. The University of Michigan, for instance, asks the design professional to deliver a draft no later than 50% schematic design.
Our view is that drafting can be delegated, but ownership can't. The design team has a natural interest in requirements it knows it can meet. The commissioning agent knows systems but may not know your business. The person who signs the OPR should be the owner, and the owner's operations staff should be in the room when it's written. On programs we've supported, the most useful OPR workshops were the ones where facility managers described the last building that disappointed them, in detail.
Two other points on ownership:
- Owner approval of changes. Whoever maintains the document, revisions should need the owner's written approval. The Kentucky guideline puts it that way: the commissioning authority keeps the current version, and the owner approves changes.
- Start from a template, not a blank page. Owners with several buildings can keep a standard OPR and adapt it for each project, as WBDG suggests. That's especially useful for retail and multi-site programs, where most requirements repeat.
Keeping it current
An OPR written in predesign and never opened again is worse than useless, because people will assume it still reflects the owner's position. Every guideline we reviewed calls it a living document.
A practical update rhythm:
- Predesign: first issue, owner-approved, before the design team starts schematic design. WBDG says it should be available no later than predesign.
- End of each design phase: update with decisions made, scope changes and code interpretations, and record who decided and when. Michigan's guideline asks for updates at the end of schematic design, design development and construction documents.
- Construction: flag any addendum, change directive or RFI response that affects the OPR or BOD. Michigan's guideline asks for these to be marked "Impact on OPR/BOD" so they aren't lost.
- Turnover: issue a final version alongside the as-built documents, so operators have the record of what the building was meant to do.
The update log is as valuable as the document. When a value engineering exercise drops a requirement, the log shows that it was a decision, who made it and why. Without it, the requirement simply disappears, and nobody can say when.
Where OPRs go wrong
Common failures we see:
- Too generic. A copied template with the project name changed. It has every heading and no real requirements.
- Not measurable. Words like "efficient", "flexible" and "easy to maintain" without a number or test attached.
- Written too late. Produced in design development to satisfy a certification checklist, after the key decisions were already made.
- No operator input. Written by the project team alone, so the building suits the people who built it rather than the people who run it.
- Silent on trade-offs. It lists every goal at equal priority, so when budget pressure hits, nobody knows which ones matter most.
The fix for the last one is simple: rank the requirements. Mark the handful that can't be traded away, and say so in writing. That gives the design team and the owner's own approvers a clear basis for change decisions later.
What owners should do
- Write the OPR before schematic design starts. Make its acceptance a condition of moving into design.
- Put operators and users in the workshops. Ask them what failed in the last building and turn the answers into requirements.
- Make every requirement testable. If the commissioning agent can't verify it, rewrite it until they can.
- Require a Basis of Design that answers the OPR point by point, and review it at each design submission.
- Control changes. Keep a revision log and require owner sign-off for any change, especially during value engineering.
- Hand it to operations at turnover. The final OPR belongs in the building's permanent records, next to the as-builts.
The bottom line
The OPR is the cheapest quality control document on a building project. It costs a few workshops and some careful writing. In return, the design team knows what to design to, the commissioning agent knows what to test against, and the owner has a record of what was promised. Owners who skip it still find out whether the building meets their needs, just later and at a higher price.
Want help writing or reviewing an OPR before design starts? Book a 30-minute call with Benjamin R. Consulting.
Sources: ASHRAE, Standards and guidelines: titles, purposes and scopes (Guideline 0-2019, The Commissioning Process; Standard 202); Whole Building Design Guide Commissioning Committee, Owner's Project Requirements; University of Michigan, Design Guideline 2.1: Owner's Project Requirements and Basis of Design; Commonwealth of Kentucky, 01 91 13: Owner's Project Requirements Overview; CSA Group, Z320-11 (R2026) Building commissioning. This article is general information, not legal advice.