The scope of work document is where most scan-to-BIM project problems originate. Vague descriptions of deliverables, unstated assumptions about LOD, and missing definitions of project boundaries create disputes that consume time and budget long after the scanning is complete.
A well-written scan-to-BIM scope of work protects both the client and the provider by establishing clear expectations before work begins. Every dollar spent on scope definition saves multiples during execution.
The physical scope defines exactly what gets scanned and what gets modeled. Floor plans with highlighted zones, not just area descriptions, eliminate ambiguity about boundaries. Vertical scope from slab to slab, from slab to deck, or from finish floor to a specific elevation above ceiling must be stated explicitly.
Exclusions are as important as inclusions. If certain rooms, floors, or areas are not part of the scope, list them. If exterior scanning is excluded, state it. Assumptions that seem obvious during proposal development become disputes when they are not documented.
Access constraints should be addressed in the scope. Are there areas that require escorts, off-hours access, or special safety training? Will the scanning crew have continuous access or limited time windows? These constraints affect scheduling, pricing, and coverage completeness.
Every deliverable should be described with enough specificity that both parties understand what will be produced. A point cloud deliverable specification should include format, coordinate system, density, and noise tolerance. A BIM model specification should include software version, LOD by discipline, file structure, and naming conventions.
LOD specifications need to go beyond citing a number. Include descriptions of what each LOD level means for each discipline in the project. Structural LOD 300 looks different from mechanical LOD 300 and plumbing LOD 300. Reference images or example models reduce interpretation differences.
Intermediate deliverables and review milestones should be specified if they are expected. Will the client review registration reports? Is there a model review at 50% completion? Are there hold points where approval is required before proceeding? Define these checkpoints in the scope to prevent surprises.
Numeric accuracy requirements remove subjectivity from quality discussions. Registration accuracy, model-to-cloud deviation tolerances, and dimensional accuracy targets should all be stated with specific values. Generic language like high accuracy or tight tolerances invites disagreement.
Quality control procedures should be outlined in the scope. Who performs QC, what metrics are checked, and what happens when deliverables do not meet accuracy requirements should all be defined before work begins. Rework provisions protect the client. Clear acceptance criteria protect the provider.
Realistic timelines account for access scheduling, processing time, modeling effort, and review cycles. A scope that promises a 100,000 square foot scan-to-BIM deliverable in two weeks is setting up both parties for disappointment.
Schedule dependencies should be explicit. The scanning schedule depends on site access. Processing depends on scanning completion. Modeling depends on processed data delivery. Client review periods add time between milestones. Each dependency should be stated with a duration estimate.
The scope should include a change management process for the inevitable adjustments that occur during project execution. Additional areas, LOD upgrades, and schedule changes all require a defined process for requesting, approving, and pricing changes. Without this process, scope creep becomes a source of conflict rather than a managed reality of project work.