A construction variation should begin as an identifiable request linked to the affected work package. Record its proposed scope, review owner and decision state, then issue revised site instructions only after the appropriate authorisation. Preserve the original instruction and acknowledgement, so staff can distinguish a requested change from approved work and identify what was already performed.
- A variation request is not an authorised site instruction.
- Preserve original and revised work-package references.
- Track acknowledgement by the affected site owner.
Describe the affected work package clearly
A variation record should identify the project, location and work package it concerns. Capture the requested change in plain terms, with supporting references where needed. A broad project note can leave several site teams unsure whether their current instruction is affected.
Retain the original scope or instruction version and the request source. The review owner needs to understand the proposed difference, not merely view a document labelled revised. Avoid altering the baseline before the business has recorded the appropriate review and authorised decision.
Separate review responsibilities
A change may require operational, technical and commercial review by different responsible personnel. Represent those decisions separately where your process requires them. The project coordinator should know which outcome is still pending rather than interpreting one approval as permission for every aspect of the change.
Technical and contractual decisions belong to the appropriate qualified and authorised people. The record can collect references and preserve their outcomes without prescribing construction methods or legal entitlements. Name the reviewer and scope of their decision so site staff receive the correct instruction.
Issue a controlled site handoff
An approved change needs an identifiable revised instruction and receiving site owner. Record the acknowledgement, especially if an earlier instruction was printed or distributed to a subcontractor. Updating a central document does not establish that the team doing the work saw the new version.
If work has already occurred, record that fact for review. The appropriate owner decides what happens next under the project’s established process. Do not assume that a changed drawing automatically resolves completed work, material commitments or the commercial implications of the request.
Illustrative scenario: a doorway location is questioned
Imagine a customer asks to move a doorway while related work is underway. The coordinator creates a variation request against the relevant package and records the existing instruction version. Responsible reviewers assess the request before any revised site instruction is issued.
The site owner acknowledges the authorised outcome and identifies work already performed. This illustrative scenario explains records and handoffs; it does not determine structural suitability, construction technique, contractual liability or whether the requested change should be accepted.
Review pending requests before they become assumptions
Maintain a queue of requests awaiting decisions, approved changes awaiting acknowledgement and affected work requiring follow-up. Each category needs a named owner. A variation count alone does not show where a project team is at risk of working from conflicting instructions.
Preserve corrections and withdrawn requests with their reasons. A withdrawn discussion may still have produced a site question that needs clarification. Keeping the sequence visible helps a supervisor explain why the current instruction remains unchanged or why an earlier revision no longer applies.
Evaluate using an unapproved request
Ask a demonstrator to receive a request, leave one review pending and inspect the site account. The proposed change should be distinguishable from the current authorised instruction. Then approve it, issue a revision and record acknowledgement from the affected work owner.
EasyManageX catalogue concepts are illustrative. Confirm review states, version references and site permissions against your own project process. Start with one work-package type so the team can establish reliable authorisation and handoff habits before broad document automation is considered.
Your working checklist
- Identify the affected project and work package.
- Retain the original instruction version.
- Separate request and review decision states.
- Name technical and commercial reviewers as applicable.
- Record site acknowledgement of authorised revisions.
- Test a withdrawn request after site discussion.
Common questions
Can a customer message authorise a site change?+
Use the authorisation process and agreements applicable to the project, with appropriate qualified guidance. A message can document a request without settling every technical or commercial decision. Keep the request linked to the current instruction and record the authorised outcome before issuing revised site work.
What if work starts before the review is complete?+
Record the actual work state and escalate through the project’s established authority. Preserve the pending request and the instruction used. The responsible personnel must determine the appropriate next step; software should not retrospectively manufacture an approval to make the timeline appear consistent.
Which variation records need site acknowledgement?+
Identify the changes that affect instructions or work the site team owns. Record the receiving person, version and acknowledgement under your process. A useful demonstration includes a printed earlier instruction, because changing a digital file alone cannot explain what the site actually received.
Sources and further reading
These primary references explain relevant concepts. Our scenarios and working checklists are original, illustrative guidance.
- ERPNext documentation: Project
Further reading on project tasks and ownership; relevant to tracking variation review and revised site handoffs without determining technical suitability.
Published by EasyManageX as practical, AI-assisted guidance. Examples are illustrative. Confirm software capabilities, licence terms and project-specific requirements before committing. Read our editorial policy.
