The twelve-part scope
A strong scope does not need to be long. It needs to remove the assumptions that would otherwise become RFIs, revisions or coordination disputes.
01 — Purpose
State what the model or document package must enable: design review, coordination, issue, tender, construction, fabrication, quantities, handover or another defined use.
02 — Inputs
List every source file, its revision/status, known gaps and whether it is approved for production.
03 — Deliverables
Name the native models, exports, drawings, schedules, issue reports and supporting records required.
04 — LOD + information
Define geometry and information by model element and intended use. Do not apply one unexplained LOD label to the entire project.
05 — Standards
Provide templates, naming, units, coordinates, classification, family rules, drawing standards, exchange requirements and the relevant BEP.
06 — Responsibilities
Identify design decision owners, model authors, coordinators, reviewers, approvers and who may authorize changes.
07 — Coordination
Define federated inputs, disciplines, rules, tolerances, priorities, RFI route and the required issue/close-out record.
08 — Program
Set mobilization, sample approval, review windows, milestones, issue dates, time-zone overlap and change cut-offs.
09 — QA + acceptance
Name the checks and acceptance criteria: coordinates, model health, parameters, drawings, revisions, links, exports and file opening.
10 — Commercial assumptions
State pricing basis, included revisions, client dependencies, exclusions, delay effects and what triggers a change request.
11 — Security + access
Define NDA, access permissions, approved storage, subcontractor rules, retention/deletion expectations and incident contacts.
12 — Handover
List final source files, exports, registers, documentation, ownership, support period and close-out criteria.
Fastest useful first step: send one source file, one sample output, the required issue date and the name of the person who owns design decisions. Those four items reveal much of the real scoping work.
What to send for a first review
- Project type, location, area and current stage
- Required service and disciplines
- Current source-model or drawing sample
- Target output and sample standard
- Software and version
- Target LOD/LOI or intended use
- First review and final issue dates
- Known information gaps or coordination risks