Scope Definition and Work Breakdown Structures

Introduction

Construction projects are delivered through a temporary organisation that must transform an approved need into a physical facility. Before activities can be sequenced, durations estimated, resources assigned, or progress measured, the project team must establish what work is included, what work is excluded, and how the work will be organised. This is the purpose of scope definition and the work breakdown structure (WBS).

A reliable planning baseline is more than a list of activities. It is an integrated reference consisting of an approved scope statement, defined deliverables, a hierarchical WBS, coding structures, organisational responsibilities, milestones, calendars, and documented assumptions. Together, these elements provide a common language for the client, consultant, contractor, subcontractors, suppliers, and project controls team.

Poor scope definition produces familiar construction problems: drawings being interpreted differently by different parties, omitted work, duplicated work, unpriced changes, unrealistic schedules, disputes over responsibility, and progress reports that cannot be verified. Conversely, a well-designed WBS allows the team to plan at an appropriate level of detail without losing sight of the project’s intended outcomes.

Learning Objectives

By the end of this chapter, students should be able to:

1. Explain the relationship between project scope, deliverables, requirements, exclusions, assumptions, and constraints.
2. Develop a clear construction scope statement.
3. Construct a deliverable-oriented WBS and distinguish it from an activity list or organisational chart.
4. Apply suitable WBS and cost, location, discipline, and responsibility coding structures.
5. Prepare an organisational breakdown structure (OBS) and responsibility assignment matrix (RAM).
6. Define milestones, calendars, schedule assumptions, and planning basis information.
7. Evaluate the quality, limitations, and governance requirements of a planning baseline.

1. Scope as the Foundation of Construction Planning

Project scope describes the work and outcomes required to satisfy the project’s purpose. In construction, scope has both a product dimension and a project dimension. Product scope concerns the characteristics of the completed facility—for example, floor area, structural system, finishes, services capacity, accessibility, and performance. Project scope concerns the work required to design, procure, construct, test, commission, hand over, and close the project.

The two dimensions must be connected. A building may require a high-performance façade as a product outcome; the project scope must therefore include design development, specialist procurement, mock-up approval, installation, testing, and documentation necessary to achieve that outcome.

Important distinctions include:

• Requirement: A condition or capability demanded by the client, authority, user, contract, or applicable standard.
• Deliverable: A verifiable product, service, or result produced by project work.
• Work package: A manageable component of a WBS for which scope, cost, schedule, responsibility, and progress can be planned and controlled.
• Activity: A scheduled piece of work that consumes time and resources. Activities are normally developed below or from work packages.
• Exclusion: Work explicitly outside the project boundary.
• Assumption: A statement treated as true for planning purposes, although it may involve uncertainty.
• Constraint: A restriction affecting the project, such as a completion date, budget, site access limit, law, or working-hour rule.
• Acceptance criterion: A measurable condition used to determine whether a deliverable is acceptable.

Scope is progressively elaborated. Early information may define a functional requirement and approximate capacity. Later design and procurement information specifies dimensions, materials, interfaces, testing, and acceptance evidence. Progressive elaboration does not justify uncontrolled scope growth. Each refinement should be traceable to an approved requirement, design decision, contract obligation, or authorised change.

Scope boundary and the project triangle

Scope interacts with time, cost, quality, risk, resources, and safety. A change in one dimension may affect the others. For example, adding a basement level changes excavation, temporary works, structural design, waterproofing, programme duration, cost, environmental controls, and risk exposure. The project team should therefore assess scope changes systematically rather than treating them as isolated additions.

A scope statement should make the boundary visible. It should identify what is included, what is excluded, the interfaces with external parties, and the basis on which completion will be judged.

2. Developing the Scope Statement

A scope statement is a controlled description of the project work and its intended outcomes. It is not merely a contract title or a broad sentence such as “construct a commercial building.” A useful statement is sufficiently specific to support estimating, procurement, scheduling, responsibility assignment, and change control.

A practical scope statement normally contains the following elements:

Requirements traceability

Requirements should be traceable from their source to the deliverables and, where practical, to WBS elements and acceptance evidence. A simple requirements traceability structure may contain:

Traceability reduces the risk that a requirement is mentioned in a brief but absent from the schedule, procurement plan, inspection plan, or handover records.

Scope verification and validation

Scope verification asks whether the defined deliverables correspond to the approved requirements and contract obligations. Validation asks whether the client or authorised user accepts the resulting deliverable. These are related but different. A contractor may verify that a pump has been installed according to approved drawings; the client or commissioning authority may still need to validate that the system satisfies operational requirements.

3. The Work Breakdown Structure

The WBS is a hierarchical decomposition of the total project scope into progressively smaller components. Its defining principle is the 100 percent rule: the WBS should represent all of the work required by the approved project scope, including project management, design, procurement, construction, testing, commissioning, handover, and closeout where these are part of the project. It should not contain work outside the approved scope.

The WBS is deliverable-oriented. It describes what must be produced or controlled, not primarily the sequence in which work occurs. For example, “structural frame” is a deliverable-oriented element, whereas “pour concrete” is an activity. The activity list can be developed from work packages after the scope has been decomposed.

Levels of decomposition

A typical construction WBS may contain:

1. Project
2. Major phases or control accounts
3. Systems, areas, or major deliverables
4. Subsystems or trade deliverables
5. Work packages
6. Activities and tasks, developed for scheduling purposes

The number of levels is not fixed. Decomposition should stop when the work package is sufficiently defined to estimate, assign, schedule, measure, and control. Excessive decomposition creates administrative burden and false precision. Insufficient decomposition hides interfaces, risks, and responsibility gaps.

A possible WBS for a small educational building is shown below:

1.0 Community Learning Centre
    1.1 Project management and controls
    1.2 Design and approvals
    1.3 Site preparation
        1.3.1 Site establishment
        1.3.2 Demolition and clearing
        1.3.3 Earthworks and temporary drainage
    1.4 Substructure
        1.4.1 Foundations
        1.4.2 Ground beams
        1.4.3 Ground floor slab
    1.5 Superstructure
        1.5.1 Frame
        1.5.2 External walls
        1.5.3 Roof structure and covering
    1.6 Building services
        1.6.1 Mechanical services
        1.6.2 Electrical services
        1.6.3 Plumbing and fire protection
    1.7 Internal finishes and fixtures
    1.8 External works and landscaping
    1.9 Testing, commissioning, and handover
    1.10 Project closeout

This hierarchy is only a planning model. A real project may use zones, buildings, systems, contract packages, or a combination of these as major branches. The selected structure should reflect how the project will be designed, procured, constructed, reported, and managed.

WBS design principles

Deliverable orientation. The WBS should identify outputs and scope components rather than reproduce a calendar of operations.

Mutual exclusivity. A scope item should not be assigned to two WBS branches unless the allocation rule is explicitly defined. For instance, external lighting should not be ambiguously included under both electrical services and external works.

Completeness. The branches should collectively cover the approved scope. Management and integration work must not be omitted merely because it does not become part of the permanent facility.

Consistent level of detail. Sibling elements should be decomposed to broadly comparable planning depth. One branch should not be divided into individual fixing operations while another remains a single unmeasurable heading without a reason.

Manageability. A work package should have a clear owner, defined boundaries, measurable output, known interfaces, and a practical basis for estimating and progress measurement.

Stability. The WBS should remain sufficiently stable to support baseline comparison. Changes are permitted, but revisions should be controlled and traceable.

WBS dictionary

The WBS alone is not enough to remove ambiguity. A WBS dictionary provides supporting information for each control account or work package. Typical fields include:

• WBS code and title
• Scope description
• Included and excluded work
• Responsible manager or organisation
• Inputs and predecessor conditions
• Required resources and procurement approach
• Estimated quantities, cost, and duration basis
• Interfaces and constraints
• Quality and safety requirements
• Acceptance criteria
• Planned start and finish conditions
• Progress measurement method
• Applicable drawings, specifications, and revisions

The dictionary is especially useful where a short WBS label could be interpreted in several ways. “External works,” for example, might include drainage, paving, boundary walls, landscaping, lighting, utility connections, or only some of these.

4. Coding Structures and Information Integration

Coding structures assign identifiers to scope and schedule information. A sound coding system permits information to be sorted, filtered, aggregated, and reconciled across the WBS, estimate, procurement register, schedule, cost report, document management system, and model.

Common coding dimensions include:

Codes should be governed by naming rules, ownership, permitted values, revision procedures, and a policy for new codes. A code should have one meaning. If “03” means a location in one system and a cost category in another, data integration becomes unreliable.

A useful schedule activity identifier may combine stable attributes, but it should not be so complicated that staff cannot apply it consistently. For example, an activity may be associated with WBS 1.6.2, location B1-L02, discipline ELEC, and subcontract package CP-06 without embedding every attribute in a single long number. Modern project systems can store these as separate fields and generate reports from them.

Coding and model-based planning

Building information modelling (BIM) can strengthen scope control when model elements are linked to WBS, location, specification, procurement, and schedule information. This is not automatic. Model objects may be incomplete, duplicated, incorrectly classified, or developed at different levels of information. The project team should define information requirements, naming conventions, ownership, exchange formats, and approval status. A visually detailed model is not necessarily a complete construction scope.

5. Organisational Breakdown Structures and Responsibility Matrices

The organisational breakdown structure (OBS) represents the organisations, departments, teams, and roles involved in project delivery. It answers “who is organised to perform or control the work?” The WBS answers “what scope must be delivered?”

A simplified OBS might include:

Project governance
├── Client
│   ├── Project director
│   └── User and operations representatives
├── Consultant team
│   ├── Lead designer
│   ├── Architect and engineers
│   └── Clerk of works / inspection team
└── Main contractor
    ├── Project manager
    ├── Construction management
    ├── Commercial and planning team
    ├── Quality and safety team
    └── Trade subcontractors and suppliers

The OBS should show reporting and coordination relationships without pretending that all contractual relationships are identical to internal reporting lines. A subcontractor may report operationally to the main contractor while retaining independent commercial obligations.

Responsibility assignment matrix

A responsibility assignment matrix (RAM) maps WBS elements to organisations or roles. The commonly used RACI model classifies participation as:

• R — Responsible: Performs or leads the work.
• A — Accountable: Owns the outcome and approves completion; normally one accountable role should be identified for a deliverable.
• C — Consulted: Provides input before a decision or output is finalised.
• I — Informed: Receives relevant information.

Example:

RACI is a communication and governance tool, not a substitute for the contract. Contractual duties, professional liabilities, statutory responsibilities, and approval authorities must be checked against the actual agreement and applicable law.

A good RAM helps identify gaps and overload. If no role is responsible for a deliverable, it is unassigned. If several parties are accountable without a decision rule, approval may be delayed. If one manager is accountable for nearly every work package, the matrix may be technically complete but operationally unrealistic.

6. Milestones, Calendars, and Schedule Assumptions

Milestones

A milestone is a significant event or decision point used to mark progress, control interfaces, or define a contractual obligation. Examples include site possession, planning approval, design release, procurement award, building watertight, energisation, practical completion, occupancy approval, and final handover.

Many scheduling systems represent milestones as zero-duration activities. This is a modelling convention, not a claim that the event requires no effort. The work needed to achieve “building watertight” has duration; the milestone marks the point at which the condition is achieved. A milestone should have an objective definition and evidence, such as an inspection record, approval, certificate, or signed decision.

Milestones may be:

• Contractual: linked to payment, liquidated damages, possession, or completion obligations.
• Management: used for internal control and executive reporting.
• Interface: marks information, access, approval, or handover between parties.
• Technical: represents testing, energisation, commissioning, or performance achievement.

Calendars

A schedule calendar defines when work may occur. It should record ordinary working days, shifts, public holidays, planned shutdowns, seasonal restrictions, access windows, noise limits, and resource-specific availability. Calendars may be assigned to activities, resources, or both.

A calendar must not be used to conceal unrealistic productivity. If a crew can work only during a night possession, that restriction should be visible and supported by the access agreement. If weather affects excavation, the planning basis should state how the risk is treated rather than simply deleting wet-season days without evidence.

Schedule assumptions and constraints register

Every baseline contains assumptions. Examples include:

• site possession will occur on the stated date;
• issued-for-construction information will be available before the related work;
• long-lead equipment will be approved within the assumed review period;
• utilities shown on available records are reasonably accurate;
• permits will be obtained by the identified party;
• specified labour, plant, and access routes will be available;
• no unrecorded contamination will be encountered.

Assumptions should be assigned an owner, date, confidence or status, consequence if invalid, and required action. They should not be buried in personal spreadsheets. A critical assumption may need a risk response, a schedule allowance, an alternative method, or a contractual clarification.

A planning assumption differs from a constraint. “The client will approve shop drawings within ten working days” is an assumption unless contractually guaranteed. “Work is prohibited outside 07:00–18:00 by the permit” is a constraint.

7. Developing the Planning Baseline

The planning baseline is the approved reference against which actual performance and authorised change are assessed. It commonly includes:

1. Scope statement and requirements basis.
2. WBS and WBS dictionary.
3. Responsibility and coding structures.
4. Activity list derived from work packages.
5. Logic relationships and schedule calendars.
6. Resource, cost, and procurement assumptions.
7. Milestone dates and acceptance conditions.
8. Risk, interface, and assumptions registers.
9. Baseline approval record and revision history.

The sequence is iterative rather than strictly linear. For example, decomposition may reveal an omitted procurement deliverable, which may require a scope clarification. A responsibility review may reveal that a utility connection has no owner. A schedule development workshop may show that the proposed milestone is not achievable under the stated access calendar.

Baseline quality can be assessed through questions such as:

• Does every approved requirement map to one or more deliverables?
• Does every deliverable map to a WBS element and responsible party?
• Are exclusions explicit?
• Are interfaces and handoffs visible?
• Can progress be measured objectively?
• Are calendar assumptions realistic and documented?
• Can cost, schedule, procurement, and design information be reconciled?
• Is the baseline approved by the appropriate authority?
• Is there a controlled process for change?

Worked Example: Defining a Work Package

Consider the work package “1.4.2 Ground floor slab” for a two-storey classroom building. A weak definition would be: “Construct slab.” It does not state whether blinding, insulation, reinforcement, service penetrations, testing, curing, or survey records are included.

A stronger work-package definition is:

From this work package, activities might include formation acceptance, blinding, membrane installation, reinforcement fixing, services coordination, inspection, concrete placement, finishing, curing, and records submission. The activity sequence and durations are developed after the work package boundary is clear.

The example illustrates an important control principle: schedule detail should be derived from a scope definition, not used to disguise an incomplete scope definition.

Applied Case: Riverside Community Health Centre

Background

This illustrative case concerns a contractor appointed to deliver a three-storey community health centre on a constrained urban site. The project includes the building, external utilities, access works, mechanical and electrical services, medical gas installation, commissioning, and handover. The client will supply loose clinical equipment and an information-technology vendor will install network equipment.

Problem

The initial six-month schedule contained approximately 250 activities, but progress reporting was disputed. The client believed medical gas testing and utility connections were included in the contract. The contractor treated them as provisional or third-party work. Several activities had no clear owner, and the schedule showed “complete” for floors where commissioning records were absent.

Analysis

A scope workshop compared the employer’s requirements, drawings, specifications, contract clarifications, procurement package, and utility correspondence. The team identified four issues:

1. Deliverables were mixed with activities, making completeness difficult to assess.
2. Interfaces with the utility authority and IT vendor were not represented as explicit deliverables.
3. The original WBS grouped all services under one heading, hiding separate testing and commissioning obligations.
4. Progress rules measured visible installation but not documentation or performance acceptance.

Approach and solution

The team developed a revised scope statement and WBS. The services branch was divided into mechanical, electrical, public health, fire protection, medical gas, controls, testing, commissioning, and handover records. A WBS dictionary defined inclusions and exclusions for each branch. A RAM assigned the contractor accountability for coordination and installation, specialist subcontractors responsibility for technical work, the consultant responsibility for design review, and the client responsibility for operational acceptance where specified.

Two interface milestones were added: “utility connection available for commissioning” and “IT vendor network infrastructure ready for systems integration.” The commissioning plan was linked to inspection records, test certificates, training, and as-built documentation. The calendar recorded restricted access during clinic operating hours and required night work for the final utility tie-in.

The baseline was reissued with a change log. The contractor did not claim that the new WBS itself changed the contractual scope; rather, it clarified and made traceable the obligations already present in the approved documents. Any genuinely additional work was routed through formal change control.

Outcome

Progress reporting became more credible because installation, testing, documentation, and acceptance were separately visible. The project team identified the utility dependency six weeks earlier than under the original schedule and arranged a joint planning meeting with the authority. The client also accepted that loose clinical equipment and network equipment were excluded, while the contractor’s coordination duties remained included.

Learning points

• Ambiguity is often caused by missing interfaces rather than missing trade headings.
• A schedule can be detailed yet unreliable if its scope basis is weak.
• Testing, commissioning, records, and training are deliverables when required for operational acceptance.
• Exclusions protect all parties only when they are explicit and consistent with contract documents.
• A revised WBS should improve traceability without being used to alter scope unilaterally.

Challenges, Limitations, and Governance

WBS development involves judgement. Different structures may be valid for the same project. A design-build contractor may organise around systems and procurement packages, while an owner may prefer buildings, floors, and operational outcomes. The chosen structure should support the decisions the project team must make.

Common limitations include:

• False precision: Very small work packages may imply certainty that design, productivity, or access conditions do not support.
• Trade bias: A structure based only on trades may hide systems integration and user outcomes.
• Location duplication: Repeating identical work for every room or zone can create a large, difficult-to-maintain schedule.
• Contract mismatch: An internal WBS does not replace contractual scope allocation.
• Changing design: Early WBS branches may need controlled revision as design develops.
• Data inconsistency: Uncontrolled codes create unreliable reports and duplicate records.
• Progress subjectivity: Percent complete is weak when acceptance evidence and measurement rules are not defined.

Governance requires authorised scope ownership, document control, change management, audit trails, and protection against inappropriate manipulation. A planner should not split or rename work solely to make performance appear better. Safety-critical, environmental, accessibility, and statutory obligations should be represented in the scope and verification arrangements even when they do not appear as visible construction items.

Ethically, planners must communicate uncertainty honestly. An assumption should not be presented as a confirmed fact; an excluded item should not be silently transferred to another party; and a milestone should not be reported complete without its defined evidence. Transparent scope management supports fair commercial administration and safer delivery.

Technology and Contemporary Practice

Cloud-based common data environments, integrated cost and schedule systems, 4D BIM, digital field reporting, and mobile inspection applications can improve traceability. Their value depends on disciplined information structures. A sophisticated platform cannot correct an undefined scope, an ambiguous code, or an unassigned responsibility.

Artificial intelligence may assist with document classification, requirement extraction, comparison of drawing revisions, identification of missing WBS links, and analysis of schedule narratives. These uses require human review because AI systems may misread contractual qualifications, confuse a proposed design with an approved design, or infer scope from incomplete documents. Sensitive project information should be handled under the organisation’s information-security and confidentiality rules. AI-generated classifications should be recorded as support to professional judgement, not as unaudited contractual decisions.

Contemporary practice increasingly emphasises information requirements, digital handover, carbon and environmental deliverables, and whole-life performance. These should be incorporated into the WBS when they are part of the project obligation. For example, embodied-carbon reporting, commissioning data, maintainability information, and materials passports may require defined deliverables, owners, review points, and acceptance criteria.

Best-Practice Checklist

Before approving a scope-based planning baseline, the project team should confirm that:

1. The project purpose and intended outcomes are clear.
2. Product and project scope are both represented.
3. Inclusions, exclusions, interfaces, assumptions, and constraints are documented.
4. Requirements are traceable to deliverables and verification evidence.
5. The WBS follows the 100 percent rule and is deliverable-oriented.
6. Work packages are measurable, assignable, and manageable.
7. The WBS dictionary defines boundaries and acceptance criteria.
8. Coding structures are consistent across schedule, cost, procurement, and documents.
9. The OBS and RAM identify responsible and accountable parties.
10. Milestones have objective definitions and evidence.
11. Calendars reflect actual access, working, and resource conditions.
12. Baseline approval, revision, and change-control procedures are established.
13. Safety, environmental, statutory, commissioning, and handover obligations are not omitted.

Chapter Summary

Scope definition establishes the boundary and intended outcomes of construction work. It distinguishes requirements, deliverables, activities, exclusions, assumptions, constraints, and acceptance criteria. A well-formed scope statement supports estimating, procurement, scheduling, reporting, and change control.

The WBS decomposes the total approved scope into a hierarchy of deliverables and manageable work packages. It should satisfy the 100 percent rule, avoid overlap, provide practical control points, and be supported by a WBS dictionary. Coding structures connect WBS elements to cost, location, discipline, contract, organisation, document, and information systems.

The OBS describes the delivery organisation, while the RAM connects organisational roles to WBS elements. RACI classifications can expose gaps, duplication, and unclear approval authority, but they do not replace contractual obligations. Milestones mark significant events and interfaces; calendars define when work can occur; assumptions and constraints record the planning basis.

A reliable baseline integrates scope, WBS, responsibilities, codes, milestones, calendars, activities, and evidence of acceptance. It must be governed through authorised change, transparent documentation, and ethical reporting. Digital tools, BIM, and AI can strengthen traceability, but only when the underlying scope and information rules are sound.

Key Terms

Scope: The total work and outcomes required to deliver the project.

Product scope: The characteristics and performance of the completed facility.

Project scope: The work required to produce, deliver, commission, and close the project.

Requirement: A condition or capability demanded by an authorised source.

Deliverable: A verifiable product, service, or result produced by project work.

Acceptance criterion: A condition used to judge whether a deliverable is acceptable.

Exclusion: Work explicitly outside the project boundary.

Assumption: A planning premise treated as true pending confirmation.

Constraint: A restriction affecting project delivery.

Work breakdown structure (WBS): A hierarchical decomposition of total project scope.

100 percent rule: The principle that the WBS includes all approved project scope and no unauthorised scope.

Work package: A manageable WBS component used for planning and control.

WBS dictionary: Supporting information that defines a WBS element’s content and control basis.

Coding structure: A system of identifiers used to classify and integrate project information.

Organisational breakdown structure (OBS): A hierarchy representing project organisations and roles.

Responsibility assignment matrix (RAM): A matrix linking scope elements to responsible organisations or roles.

RACI: Responsible, Accountable, Consulted, and Informed participation categories.

Milestone: A significant event, decision, or condition used for project control.

Calendar: A representation of permitted working time and availability.

Planning baseline: The approved reference used to compare planned and actual performance.

Review Questions

Short Answer Questions

1. Distinguish product scope from project scope, using one construction example for each.
2. What is the purpose of a WBS dictionary?
3. Explain the 100 percent rule.
4. State the difference between an assumption and a constraint.
5. What is the primary purpose of a responsibility assignment matrix?

Long Answer Questions

1. Explain how a scope statement should be developed and identify the information it should contain.
2. Describe the principles of a good construction WBS and explain why a WBS should be deliverable-oriented.
3. Compare a WBS, an OBS, and a RAM in terms of purpose and relationship.
4. Discuss the role of milestones, calendars, and assumptions in establishing a reliable schedule baseline.
5. Explain how coding structures support integration between scope, cost, schedule, procurement, and document control.

Analytical / Application Questions

1. A project schedule contains activities for installing lifts but no activities for approvals, testing, commissioning, or handover records. Analyse the scope-control weaknesses and propose WBS and milestone additions.
2. Develop a three-level WBS for a small warehouse project. State your decomposition logic, two exclusions, and two assumptions.
3. A subcontractor claims that utility connection work is outside its package, while the client believes it is included. Describe a structured method for analysing the dispute using requirements traceability, the WBS dictionary, the RAM, and change control.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a work breakdown structure?

A. A chronological list of all site activities

B. A hierarchical decomposition of the total approved project scope

C. An organisational chart showing reporting relationships

D. A register of project risks and assumptions

Correct Answer: B. A hierarchical decomposition of the total approved project scope

Question 2

Under the 100 percent rule, a WBS should include:

A. Only physical construction activities

B. Only work performed by the main contractor

C. All approved project scope and no unauthorised scope

D. Only work that affects the critical path

Correct Answer: C. All approved project scope and no unauthorised scope

Question 3

Which item is an acceptance criterion?

A. The client may change the room layout later

B. The subcontractor expects materials next month

C. The fire alarm passes the specified functional test

D. The project team will meet weekly

Correct Answer: C. The fire alarm passes the specified functional test

Question 4

What is the main distinction between a WBS and an OBS?

A. The WBS represents scope, whereas the OBS represents organisations and roles

B. The WBS represents cost, whereas the OBS represents quality

C. The WBS represents risks, whereas the OBS represents milestones

D. The WBS represents contracts, whereas the OBS represents drawings

Correct Answer: A. The WBS represents scope, whereas the OBS represents organisations and roles

Question 5

In a RACI matrix, the accountable role normally:

A. Receives information only

B. Provides specialist advice but cannot approve

C. Owns the outcome and approves completion

D. Performs every task personally

Correct Answer: C. Owns the outcome and approves completion

Question 6

Which is the best example of a project interface milestone?

A. Place concrete

B. Utility connection available for commissioning

C. Purchase hand tools

D. Review yesterday’s productivity

Correct Answer: B. Utility connection available for commissioning

Question 7

Why is a WBS dictionary important?

A. It replaces the project contract

B. It defines the content, boundaries, interfaces, and control basis of WBS elements

C. It automatically calculates every activity duration

D. It removes the need for acceptance criteria

Correct Answer: B. It defines the content, boundaries, interfaces, and control basis of WBS elements

Question 8

Which statement about a schedule calendar is correct?

A. It defines permitted working time and availability

B. It guarantees productivity regardless of conditions

C. It is used only for contractual milestones

D. It eliminates the need to document access restrictions

Correct Answer: A. It defines permitted working time and availability

Question 9

A planner records that site possession will occur on a proposed date, although it is not yet confirmed. This is best classified as a:

A. Constraint

B. Milestone already achieved

C. Planning assumption

D. Completed deliverable

Correct Answer: C. Planning assumption

Question 10

Which practice most improves scope-to-progress traceability?

A. Reporting only visible physical installation

B. Assigning deliverables clear owners, acceptance criteria, codes, and measurement rules

C. Using one broad activity for all building services

D. Changing WBS codes whenever progress is behind plan

Correct Answer: B. Assigning deliverables clear owners, acceptance criteria, codes, and measurement rules