Method Statement Interface Review: A Practical Checklist

This article provides a practical framework for reviewing interfaces in a method statement: the boundaries and dependencies between work packages, trades, and project functions. A method statement may be technically complete for one activity yet leave unclear what must happen before it, who provides the work area or information, and what evidence allows the next activity to proceed.

Use this as general workflow guidance, not as project approval or a universal construction sequence. The contract, approved drawings and specifications, project procedures, manufacturer instructions, applicable authority requirements, and competent project reviewers govern project-specific decisions. Where those sources differ from this article, follow the applicable approved requirements and resolve conflicts through the project’s established process.

Define the work package and its boundaries

Begin by identifying the asset or system, location, work package, responsible organisation, document revision, and review date. State what the method statement covers and what it excludes. For example, a package might cover preparation, installation, inspection, testing, records, and handover while excluding design approval or energisation by another party. Treat that as an illustration only; establish the actual boundary from the project documents.

List adjacent activities that could affect the work or depend on its completion. Include interfaces with other trades, design, procurement, quality, safety, operations, and programme coordination where relevant. Do not assume an activity is included merely because it appears in a neighbouring method statement. Record boundary gaps and ask the responsible parties to confirm them.

Build a practical interface register

A useful interface review turns broad coordination concerns into entries that can be assigned and closed. As general workflow guidance, create one register row for each material dependency or potential conflict. Capture:

• Interface ID and the two or more activities, packages, or parties involved.
• Location or system, where it can be identified from approved project information.
• Prerequisite: the information, access, approval, completed work, or condition needed before the dependent activity proceeds.
• Sequence dependency: what must precede what, and whether the proposed order conflicts with another method statement or programme assumption.
• Owner for providing the prerequisite and owner for verifying it. Name roles or organisations according to the project’s responsibility structure.
• Inspection, decision, or handover point, including the project-defined evidence required to demonstrate closure.
• Status, open issue or exception, responsible action owner, target date if the project uses one, and closure reference.

Use approved drawings, specifications, schedules, method statements, inspection and test plans, permits, and other applicable project records to establish each entry. Record document revisions and review status. If the source information is missing or inconsistent, mark the interface unresolved rather than guessing at a requirement or declaring it closed.

Example: check a work-area handover between trades

Consider a generic interface in which one trade’s activity is followed by another trade’s installation in the same work area. This is an illustration of the review method, not a claim about a particular project or a prescribed construction sequence.

1. Identify the predecessor and successor activities from the relevant approved work documents. Confirm that the method statements describe the same location and boundary, rather than assuming the package names alone establish scope.
2. Compare their stated prerequisites. Check whether the successor assumes access, completed preceding work, approved materials, survey information, isolation, a permit, or another condition. Include only prerequisites applicable to the actual project and supported by its documents.
3. Compare the proposed sequence and temporary conditions. Look for conflicting assumptions about shared access, work-area availability, protection of completed work, or simultaneous activities. Do not resolve a conflict by inventing a sequence; refer it to the responsible project parties and applicable approved requirements.
4. Assign ownership. Identify who provides the prerequisite, who confirms the area or information is ready, and who accepts the handover under the project’s responsibility arrangements. If responsibility is unclear, record the gap and request an agreed owner.
5. Define closure evidence. Link the handover to the project-required record, inspection, approval, or other observable evidence. Specify who reviews that evidence and where it is retained, as directed by the project process.
6. Record any unresolved conflict or failed check as an exception with an owner and closure evidence. Do not treat planned coordination or a verbal assumption as proof that the interface is closed.

The example’s value is the traceable logic: dependency, sequence, ownership, check, and evidence. The actual handover criteria and records must come from the governing project documents.

Check sequence and prerequisites across trades

Read the proposed sequence step by step, then compare it with adjacent method statements and the available programme information. For each step, ask what must be true before the activity begins, who confirms that condition, what work follows, and whether another trade relies on the result. A sequence should be understandable to someone who was not involved in drafting it.

Check for incompatible assumptions, such as two activities relying on the same access or work area at the same time, one package assuming another has finished without a defined handover, or inspection being described in one document but omitted from the dependent activity. These are review prompts, not findings about a project. Verify each concern against current project information and refer conflicts through the project’s agreed coordination and document-control process.

For each proposed inspection or decision point, record what is checked, who checks it, when it occurs, what evidence is retained, and what happens if the result is not acceptable. Include hold or witness points only when the governing project documents define them. Tie acceptance criteria to the applicable approved specification, drawing, manufacturer instruction, or other authorised source and identify its revision.

Confirm inputs, authority, and project limitations

Before issue, assemble an input register of documents that actually apply: approved drawings, specifications, schedules, material submittals, risk assessments, inspection and test plans, permits, manufacturer information, and project instructions. Note revision, date, owner, and review status where available. Mark missing inputs as gaps rather than filling them with generic requirements.

Identify the local authority requirements, national codes, contract documents, approved design, manufacturer instructions, and project health-and-safety arrangements applicable to the work. Applicability depends on the project, scope, and jurisdiction. Do not insert a standard, legal clause, numerical limit, or product requirement unless its wording and relevance have been verified against an appropriate source. A qualified technical reviewer should assess whether the proposed sequence is safe and buildable for the actual conditions and equipment.

This framework does not replace design approval, permits, method-statement acceptance, competent site supervision, or project-specific safety and environmental controls. Where work involves matters such as isolation, energisation, lifting, access, hazardous materials, fire protection, waste, or environmental controls, address them only as applicable and by reference to verified project requirements.

Manage exceptions and close interfaces

Maintain an exception record for missing information, conflicting instructions, abnormal conditions, failed checks, late approvals, or work that cannot follow the planned sequence. For each entry, state the issue and affected interface, its known impact, the immediate control if one is defined by the project, the responsible owner, and the evidence needed for closure. Use the project’s escalation and approval routes; this article does not prescribe them.

Do not mark an interface closed merely because the related activity appears complete. Confirm that the specified prerequisite or handover evidence exists and has been reviewed by the designated party. Keep installation, inspection, testing, commissioning, document review, and handover distinct where the project treats them as separate gates. Physical completion alone may not demonstrate that required records or decisions are complete.

Pre-issue coordination checklist

• The work scope, exclusions, location, responsible parties, revision, and date are explicit.
• Adjacent trades and relevant project functions have been considered for dependencies and conflicts.
• Each material interface identifies its prerequisite, sequence relationship, owner, check, and closure evidence.
• Sequence assumptions have been compared with relevant approved documents and coordinated where they conflict.
• Inspection and decision points state what is checked, by whom, when, and what record demonstrates the outcome.
• Unresolved information and failed checks remain visible as exceptions with ownership and closure evidence.
• Acceptance criteria and project-specific controls are traceable to applicable, current sources.
• Automated document checks are not presented as a substitute for qualified technical review or approval.

Related EngineersBlog reading

• Method Statement for Installation of UPS System: Review Checklist
• Method Statement for Cctv Installation: Review Checklist
• Ironmongery Method Statement: Scope, Installation and Inspection
• Method Statement for Planted Columns — Engineering Guide and Checklist

Research and source register

• FHWA Construction Team – Construction – Federal Highway Administration
• Creating Helpful, Reliable, People-First Content | Google Search Central | Documentation | Google for Developers

These sources provide general construction or editorial context; they do not establish acceptance criteria for a particular project. Use approved project documents and appropriately qualified reviewers for project decisions.

Conclusion

An effective method statement interface review makes trade coordination verifiable. Define the boundaries, map dependencies, compare sequence assumptions, assign ownership, identify checks, and record closure evidence. Keep unresolved matters visible and tie project-specific requirements to approved sources. This checklist supports review; the authorised project documents and responsible people determine what is acceptable for the work.