Scope Statement and Basis of Design

Introduction
The PMI Construction Professional (PMI-CP) credential tests whether you can manage the full life cycle of built-environment projects. Two documents sit at the start of almost every successful construction project: the Project Scope Statement and the Basis of Design (BoD). They are closely related to the Owner's Project Requirements (OPR). Together they define what will be built, why it will be built that way, and what is excluded. This guide covers why they matter, what they are, how they work in practice, and how to answer exam questions about them.

1. Why the Scope Statement and Basis of Design Are Important
Most cost overruns, delays, claims and disputes on construction projects come from unclear or changing scope. A well-defined scope statement and BoD:
• Create a shared baseline. The owner, designers, contractors, commissioning agents and the project manager all work from one agreed definition of the work.
• Provide the reference point for change control. A change order can only be judged against a documented baseline. If the original scope was never defined, you cannot tell whether a request is new work or work already included.
• Reduce scope creep and gold plating. Explicit inclusions, exclusions and acceptance criteria stop extra features from slipping in without approval, whether the owner adds them (scope creep) or the team adds them (gold plating).
• Support accurate estimates and schedules. Cost estimates, the WBS, procurement packages and the schedule are all built from the defined scope.
• Preserve design intent through the life cycle. The BoD records the technical assumptions, codes, criteria and rationale behind design decisions. Contractors, reviewers, commissioning agents and future facility managers can then understand why a system was designed as it was.
• Enable commissioning and acceptance. Commissioning verifies that installed systems meet the OPR as interpreted in the BoD. Without a BoD there is no clear standard to test against.
• Reduce legal and contractual risk. Clear scope documents lower the chance of claims, especially under lump-sum and design-build contracts.

2. What They Are
2.1 The Project Scope Statement
The project scope statement is the description of the project scope, the major deliverables, the assumptions and the constraints. It is an output of the Define Scope process. Together with the WBS and WBS dictionary, it forms the scope baseline.

Typical contents in a construction context:
• Project scope description: what the facility or asset is, for example a 5-storey, 12,000 m2 medical office building with underground parking.
• Deliverables: the building, systems, as-built drawings, O&M manuals, warranties, training, and commissioning reports.
• Acceptance criteria: the conditions that must be met before deliverables are accepted, such as substantial completion, certificate of occupancy, LEED certification or performance tests.
• Exclusions (out of scope): for example furniture, fixtures and equipment (FF&E), off-site utility upgrades, tenant fit-out, or hazardous material abatement. Exclusions are among the most powerful dispute-prevention tools.
• Assumptions: for example that the geotechnical conditions match the soil report, that permits will be issued within 60 days, or that the owner will provide site access by a given date.
• Constraints: budget caps, mandated completion dates, site logistics, zoning limits, working hours, union agreements and regulatory requirements.

2.2 The Basis of Design (BoD)
The Basis of Design is a document prepared by the design team. It records the concepts, calculations, decisions, assumptions and product selections used to meet the owner's requirements and applicable codes. In short, it translates the owner's goals into technical design criteria.

Typical contents:
• Design criteria: loads, occupancy, indoor environmental conditions, energy targets, redundancy and capacity.
• Codes, standards and guidelines applied, such as building codes, ASHRAE, NFPA, ACI, local ordinances and owner standards.
• System descriptions: structural system, HVAC concept, electrical distribution, plumbing, fire protection and controls.
• Design assumptions: climate data, occupancy schedules, diversity factors, future expansion allowances.
• Rationale for key decisions: why one option was chosen over alternatives, such as cost, life-cycle cost, reliability or sustainability.
• Performance requirements used for commissioning and testing.

2.3 Owner's Project Requirements (OPR): the companion document
• The OPR is written by or for the owner. It states the owner's goals, functional needs, expectations and success criteria in non-technical terms.
• The BoD is written by the designer. It explains how the design will meet the OPR.
• A simple way to remember it: OPR = what and why (owner); BoD = how (designer); Scope Statement = boundaries, deliverables and acceptance (project management).

2.4 Key differences at a glance
• Author: the scope statement is led by the project manager with stakeholder input. The BoD is authored by the architect and engineers.
• Focus: the scope statement defines boundaries and deliverables. The BoD defines technical criteria and design intent.
• Use: the scope statement anchors scope control and change management. The BoD guides design development, reviews, value engineering and commissioning.
• Updating: both are living documents controlled through formal change management. The BoD is updated at each design milestone, such as schematic design, design development and construction documents.

3. How They Work in Practice
Step 1: Capture the owner's needs. The business case, project charter and OPR identify objectives, budget, schedule and functional requirements. Requirements are gathered through interviews, workshops, benchmarking and stakeholder analysis.

Step 2: Develop the BoD in response to the OPR. During programming and schematic design, the design team prepares the BoD. Each major system is traced back to an OPR requirement.

Step 3: Define the project scope statement. The project manager uses the charter, requirements documentation, OPR and BoD to write the scope statement. Expert judgment, product analysis, alternatives analysis and facilitated workshops are typical tools.

Step 4: Decompose into the WBS. The scope statement is broken into work packages, such as sitework, foundations, superstructure, envelope, MEP and finishes. A WBS dictionary describes each package.

Step 5: Baseline and approve. The owner and key stakeholders formally approve the scope baseline. The BoD is accepted by the owner, often with the commissioning authority's review.

Step 6: Use as the reference for change control. When an RFI, field condition, owner request or design revision arises:
• Compare it to the scope statement. Is it included, excluded or ambiguous?
• Compare it to the BoD. Does it alter design criteria or system performance?
• Assess the impact on cost, schedule, risk, quality and commissioning.
• Route it through the integrated change control process, which may involve a change control board.
• If approved, issue a change order and update the scope baseline, BoD, drawings, specifications, schedule and budget.

Step 7: Validate and commission. Deliverables are validated against the acceptance criteria in the scope statement through the Validate Scope process. Systems are commissioned against the BoD and OPR. Final as-builts and an updated BoD are handed over to operations.

Example: The BoD specifies that the data center is designed for N+1 cooling redundancy. During construction, the owner asks for 2N redundancy. This is a change to the BoD and to the scope. The PM should evaluate its impact, possibly through value engineering or alternatives. The PM should then submit it through formal change control and, if approved, update the BoD, scope statement, cost and schedule before the work proceeds.

4. Common Pitfalls
• Vague scope descriptions, for example "complete MEP systems" with no criteria.
• Missing exclusions, which lead to assumptions about who pays for what.
• A BoD that is not updated after design changes, so commissioning tests against outdated criteria.
• Contractors proceeding with verbal owner requests outside formal change control.
• Confusing the OPR with the BoD, or treating specifications as a substitute for the BoD.
• Assumptions that are never validated, such as soil conditions or utility capacity.

5. Exam Tips: Answering Questions on Scope Statement and Basis of Design
Tip 1: Know who owns which document. The owner provides the OPR, the design team prepares the BoD, and the project manager leads development of the scope statement. Watch for answer options that assign authorship to the wrong party.

Tip 2: Go back to the baseline first. When a question describes a disputed request or a possible change, the best first step is usually to review the scope statement, contract and BoD to determine whether the item is in scope. Avoid answers that jump straight to doing the work, refusing it or escalating it.

Tip 3: Change always goes through formal change control. PMI's preferred answer is to assess the impact and then submit a change request for evaluation. Never implement an unapproved change, even if the owner asks verbally or the cost seems small. Gold plating is always wrong in PMI logic.

Tip 4: Exclusions and assumptions are dispute preventers. If a question asks how to reduce future claims or misunderstandings, look for answers that strengthen exclusions, document assumptions and define acceptance criteria.

Tip 5: Link the BoD to commissioning and quality. Questions about verifying system performance, testing or commissioning failures often point back to the BoD and OPR. The correct answer is often to verify the installation against the BoD criteria, or to update the BoD if the design changed.

Tip 6: Keep documents current. If a scenario shows that an approved change was made but the documents were not revised, the answer usually involves updating the scope baseline, BoD and related plans. Look for the option that maintains traceability.

Tip 7: Distinguish Validate Scope from Control Quality. Validate Scope is formal acceptance of deliverables by the customer or owner. Control Quality is internal verification of correctness. Commissioning against the BoD supports quality; owner sign-off supports scope validation.

Tip 8: Scope creep versus gold plating. Scope creep is uncontrolled expansion, often stakeholder-driven, without adjusting time, cost or resources. Gold plating is the team adding extras on its own. Both are prevented by a clear scope statement and strict change control.

Tip 9: Choose the proactive, collaborative answer. PMI favors early stakeholder engagement, workshops to clarify requirements, and documented agreements. If the answers include "meet with the owner and designer to clarify requirements and update the documents," that is often better than a unilateral action.

Tip 10: Watch the timing in the life cycle. Early in a project, the focus is on developing and approving the OPR, BoD and scope. During construction, the focus is on controlling scope against those baselines. At closeout, the focus is on validation, commissioning and handing over the updated BoD and as-builts.

Tip 11: Read for keywords.
• "Design intent," "criteria" or "rationale" points to the BoD.
• "Owner goals" or "functional expectations" points to the OPR.
• "Boundaries," "deliverables," "exclusions" or "acceptance criteria" points to the scope statement.
• "Scope baseline" means the scope statement plus the WBS plus the WBS dictionary.

Tip 12: Eliminate extreme answers. Options such as "stop all work," "terminate the contractor" or "ignore the request" are rarely correct. The best answer is usually analytical (assess impact), procedural (follow change control) and communicative (inform stakeholders).

Sample Question
During construction, the mechanical subcontractor proposes a different chiller that is cheaper but less efficient than the one in the design documents. What should the project manager do first?
A. Approve it to save money
B. Reject it immediately
C. Review the proposal against the Basis of Design and OPR, then process it through change control
D. Ask the owner to decide informally
Answer: C. The BoD records the efficiency criteria and the reasoning behind the original selection. Any deviation must be evaluated against the design intent and owner requirements, then handled through formal change management.

6. Quick Summary
• The OPR states what the owner needs. The BoD explains how the design meets those needs. The scope statement defines project boundaries, deliverables, exclusions, assumptions, constraints and acceptance criteria.
• Together they form the baseline for estimating, scheduling, procurement, change control, commissioning and acceptance.
• On the exam, always check the baseline first, assess impacts, follow integrated change control, keep documents updated and engage stakeholders collaboratively.