Few phrases cause more tension during robotic system acceptance than “But that is not what we agreed on.” Often, the issue is not a major design failure. It is a sequence of sensible, small changes that took place during integration and were never formally communicated to everyone responsible for project acceptance.
A pickup point moves, a task sequence changes or the operator interface is adjusted. Engineers at the customer site participate and the integrator reasonably believes that the change is understood. But the management team reviewing acceptance may still be comparing the delivered system with the original agreement.
01 / Recognize the two versions of the same project
One group remembers the approved specification. Another remembers the practical decisions made while solving real site problems. Without a controlled record, both may be acting in good faith and still have fundamentally different acceptance expectations.
The result is an avoidable dispute about scope, cost, commissioning time and sometimes safety.
02 / Distinguish technical agreement from authority
Being involved in a site decision does not automatically confer contractual approval authority. Agree at project kickoff who may propose, technically endorse and formally authorize different categories of changes.
Not every adjustment requires a steering committee. But a change that affects safety, throughput, interfaces, cost, schedule or acceptance criteria needs the appropriate traceable approval.
03 / Maintain a lightweight change record
For each material change, record the previous and new condition, reason, impact, proposer, reviewer, approver, date and affected documents or tests. A short form, shared issue tracker or confirmed email can be sufficient when it is part of an agreed process.
Keep document revisions consistent: mechanical layout, interface specification, mission sequence and acceptance matrix should reflect the same approved reality.
04 / Recheck FAT and SAT scope after changes
FAT typically verifies agreed functions under controlled conditions, often at a supplier site. SAT checks the relevant installed solution in the customer environment. Depending on the project, tests and integration changes may also occur at the customer site outside a conventional FAT.
Regardless of terminology, acceptance should trace to the current approved baseline. A change that invalidates an earlier test must have a clear retest decision and evidence.
05 / Communicate changes at the right frequency
A brief weekly digest of approved decisions and open impacts can prevent weeks of later reconstruction. Management should understand material deviations before acceptance day; engineers should not have to defend undocumented changes they believed were agreed.
Change control is not bureaucracy for its own sake. It protects the customer, integrator and operational team from different interpretations of the delivered system.
“We thought you knew” is not an acceptance strategy. A written decision now is easier than a disputed recollection later.