Connecting BIM Construction Progress to Site Records and Issue Review
To keep BIM progress aligned with the site, link executable tasks to buildings, floors, zones and elements, then retain planned dates, reported quantities and review status separately. Model colors should read those business records. Issues need owners, evidence and review outcomes; a green element is not proof that the work has been accepted.
On this page5 sections
Choose a model scope that matches an executable task
Project managers need to know which work is late, where the impact is and who should act. Start with a task unit that a site team can verify, such as one operation in a defined floor zone. Link its task ID to the relevant elements. Do not distribute progress evenly across model elements simply because the model contains them.
An element can pass through installation, inspection and rework, while several tasks can share the same location. Keep the task, operation, element set or zone, and model version in the mapping. If reliable element identifiers are unavailable, begin at an explicitly defined zone level. The interface should reflect that limitation instead of implying element-level precision.
If the schedule uses a work breakdown structure (WBS), retain its task identifiers and hierarchy. One task may cover many elements, and one element may support several operations. Make those relationships explicit instead of using an element name as a task ID. Link photographs and field reports to the relevant task and date so an older image is not mistaken for current progress evidence.
A completion percentage also needs a denominator. Agree whether progress uses measured quantities, work packages or milestones, with units and weights approved by the project team. Lengths, item counts and areas from different trades cannot simply be added. Where comparable weights are unavailable, separate task states are more verifiable than a single overall percentage.
Keep planning, reporting and review records separate
| Record | What to retain | What the interface explains |
|---|---|---|
| Plan baseline | Task, scope, planned dates, quantity, version | Which plan is being used for comparison |
| Site report | Actual dates, quantity reported, person, time, photographs | How much progress the site has reported |
| Progress review | Confirmed quantity, reviewer, evidence, rejection reason | Which progress has been verified |
| Issue record | Issue, location, owner, due date, review outcome | Whether completed work still has open issues |
An installation may be reported complete while a quality issue awaits review. Show both facts. Avoid using one color for progress, quality and safety at the same time. The legend and filters should state which status the current view represents.
Keep historical records locatable after revisions
When a weekly plan changes, retain the original baseline, revised version, approval time and reason. Managers need both the current forecast and the variance from the original plan. Overwriting the old date can make an earlier delay disappear from reporting.
Before replacing a model, check whether element identifiers remain stable. Split, merged or re-exported elements need an old-to-new mapping and a list of records that cannot be matched automatically. Preserve the original model context for historical photographs and issues. A similar element name is not sufficient reason to silently move an old issue to a new object.
Define who can confirm that an issue is resolved
An issue needs its location, related task, observed problem, responsible party, deadline, site evidence and reviewer role. After the owner submits corrective action and new evidence, the designated reviewer accepts or returns it. Keep earlier review comments and retain the same issue ID when a problem is reopened.
For collaboration between applications, evaluate buildingSMART's BCF, which supports exchanging model-based issues with object references and viewpoints. It can preserve spatial context, but approval rights and closure criteria still need project agreements. Test the fields actually supported by both applications.
The location view should help the owner find the relevant zone or element and inspect before-and-after evidence. Model navigation and issue handling must use the same issue ID to avoid a closed state in the viewer while the site register still shows outstanding work.
Trial the workflow in one construction zone
Choose a zone with real tasks, a usable model and participation from its site owner. Complete a reporting, rejection, correction and review cycle before demonstrating plan and model revisions. Actual users should operate the workflow rather than only watching a prepared animation.
- A delayed task locates its agreed scope and identifies the plan version used for comparison.
- A quantity correction updates the list, model state and totals while retaining the correction record.
- A rejected remedy remains traceable without overwriting progress confirmation or quality review.
- After a model replacement, old issues retain their evidence and unmatched records appear in a worklist.