MEP Coordination: Responsibilities, Reviews and Deliverables
MEP coordination needs more than clash reports. Define model inputs, decision owners, review cycles and the evidence required to close an issue.
MEP coordination brings mechanical, electrical and plumbing information together with the surrounding architecture and structure to review interfaces. Fire protection and specialist systems may also be included; the scope should name them explicitly.
The goal is a coordinated information package that supports the next project decision. A clash report is one input to that process, not proof that the design is resolved or the work is ready for installation.
Agree responsibilities before testing
Name who supplies each model, who checks submissions, who runs coordination and who can resolve design questions. Specify who approves the resulting drawings or work package. These roles may belong to different organizations.
For each review cycle, agree submission dates, source revisions, the coordination meeting and the deadline for updates. Record missing submissions so a partial review is not mistaken for a complete one.
Check the model inputs
- Coordinates, units, levels and discipline boundaries.
- Model revision and intended use.
- Included systems and the information needed for the review.
- Duplicate or outdated linked files.
- Known gaps, assumptions and areas awaiting design decisions.
A model that looks aligned at one location can still have inconsistencies elsewhere. Check representative locations and follow the project's quality plan.
Choose tests around the actual interfaces
Autodesk distinguishes geometric intersections, clearance tests and duplicate-geometry checks in Navisworks. Select rules and tolerances for the project question instead of using a single default for every system. Navisworks clash-test options.
Include reviews for installation and maintenance access where required. The presence of clear geometry does not prove sufficient working space; any needed access envelopes or checks must be part of the scope.
Turn results into actionable issues
Illustrative example: several clash results concern a duct crossing the same beam. Review whether they represent one design issue or several independent conditions. Grouping should make the decision clearer without hiding affected locations.
An issue record should include a stable identifier, location, affected elements, source revision, description, responsible person, due date and status. Add the proposed action and the evidence used to verify the revised arrangement.
Prioritize using the project's release dates, impact and dependencies. A large raw count is not a useful meeting agenda by itself.
Run the review and verify updates
- 1Confirm the current information and focus on decisions due for the next milestone.
- 2Review alternatives with the responsible participants.
- 3Record actions, owners and unresolved dependencies.
- 4Receive and check updated models.
- 5Retest relevant interfaces and review affected drawings.
- 6Record closure evidence or keep the issue open.
An issue marked resolved by its author may still need verification. Document the status definitions so every participant understands what “closed” means.
What should the coordination package contain?
Agree the federated model or review files, test definitions, issue register, meeting actions and required drawings. Identify outstanding issues and release limitations. If the service includes shop drawings, specify them separately; they are not an automatic by-product of running clash tests.
For a drawing package, review the Revit deliverables guide. For the service scope, see BIM and MEP coordination.
Questions teams often ask
Does zero clashes mean the design is correct?
No. A test only reviews the included information under its selected rules. Unmodeled items, missing submissions, design calculations and field conditions may require separate review.
Can coordination be delivered remotely?
Many model-review and issue-management activities can be remote. Agree communication, platform access and how site information reaches the team. Field verification responsibilities still need to be assigned.
How do we judge progress?
Track issues by status, age, owner and package milestone, alongside submission completeness. Compare like-for-like reviews; changing the model scope or test rules changes what the numbers mean.
Let's talk about your project.
Share the intended use, available information and target date. We can help define the scope and deliverables for your BIM or VDC work.
