Robot Project Change Orders: How to Control Scope Creep After the Purchase Order

Robot Project Change Orders: How to Control Scope Creep After the Purchase Order

The purchase order is signed. The SOW is defined. The robot supplier has started work. Then the changes begin.

The buyer's engineering team visits the supplier's factory and notices the end effector mount does not match the facility's tooling. The supplier suggests a "small modification." A project manager sends an email requesting a different cable routing. The site team calls the supplier's engineer to ask whether the safety controller can be reprogrammed for a different zone layout. Each of these communications feels like a routine project adjustment. None of them goes through a formal change process.

Three months later, the robot arrives with a different end effector mount than the SOW specified, the cable routing does not match the facility's cable trays, and the safety controller is configured for a zone layout that no longer matches the installed perimeter. The buyer asks why. The supplier points to the email. The project manager says it was agreed on a call. The site team thought the engineer would document it. Nobody can find a signed change order.

This is how scope creep happens. Not through dramatic disputes, but through informal communications that accumulate into material changes nobody tracked.

What Scope Creep Looks Like in Robot Projects

PMBOK defines scope creep as "the uncontrolled expansion of project scope without adjustments to time, cost, and resources." In robot projects, scope creep typically takes one of three forms:

Technical specification drift — the delivered robot, end effector, or safety configuration differs from the SOW baseline because of informal technical discussions during the project. Illustrative scenario: the SOW specifies a 50 kg payload end effector. During a technical review, the supplier suggests a 60 kg version "for future flexibility." The buyer's engineer agrees verbally. The delivered robot has a 60 kg end effector, but the safety validation, cycle time, and power consumption were never recalculated for the higher payload.

Scope of work expansion — the supplier is asked to perform tasks that were not in the SOW, without a corresponding adjustment to price or schedule. Illustrative scenario: the SOW says the supplier will install the robot and commission the cell. During installation, the buyer asks the supplier's technician to also integrate the robot with the existing PLC. The technician complies. The integration work was not in the SOW, was not priced, and the PLC integration is incomplete because the technician is not a PLC specialist.

Configuration changes without baseline updates — firmware, parameters, or maps are changed during the project without updating the configuration baseline. Illustrative scenario: the supplier updates the robot's firmware during commissioning to fix a motion planning issue. The new firmware changes the collision avoidance behavior. The SOW baseline references the old firmware. Nobody updates the baseline or validates the new firmware against the application requirements.

In each case, the change itself may be reasonable. The problem is that it was not controlled — it was not submitted through an authorized channel, evaluated for impact, approved by the right authority, documented, and reflected in updated baselines.

Authorized Change Channels: The Core of Change Control

Most project teams focus on change order forms — the document that records an approved change. But the form is the output. The input that matters is the authorized change channel: the defined path through which a change request must travel to be considered for approval.

Without an authorized change channel, every email, phone call, and hallway conversation can become a de facto change instruction. Whether those informal communications carry contractual weight depends on the applicable law and the complete contract — the project team should not assume they are automatically non-binding. Instead, the project team, with legal counsel, should explicitly define:

• What constitutes an authorized change channel — which communication methods (e.g., a formal change request form in a project management system, a signed change order document) are the only recognized paths for requesting and approving changes
• Who has authority to submit change requests — which project roles can initiate a change request
• Who has authority to approve changes — which individuals or bodies can authorize changes at different levels (see CCB section below)
• What recordkeeping is required — how each change request, evaluation, decision, and implementation is documented
• What happens to informal communications — how emails, calls, and verbal discussions that propose changes are handled (typically: they must be converted into a formal change request through the authorized channel to have effect)

This definition should be established before the PO is signed, referenced in the SOW, and reinforced at project kickoff. If the authorized change channel is not defined until the first change request arises, the project has already created a window for uncontrolled changes.

Change Control Board: Who Approves What

PMBOK introduces the concept of a Change Control Board (CCB) — a formally constituted group of stakeholders responsible for reviewing, evaluating, approving, deferring, or rejecting project changes. Whether to establish a CCB depends on the project scope, contract, and delivery model. For robot projects of moderate complexity, a CCB may be appropriate; for simpler projects, a single authorized approver may suffice.

The key principle is not the CCB itself but the definition of approval authority at different levels:

PMBOK distinguishes between changes that affect the project baseline (scope, schedule, cost) and changes that do not. Baseline changes require higher-level approval. Non-baseline changes may be approved by the project manager within delegated authority. The project team should define these thresholds in the change management plan and confirm them with legal counsel — what constitutes a "baseline" change in a specific contract may depend on the contract's definitions.

If the CCB does not include the buyer's project sponsor or a senior decision-maker, certain changes (particularly those affecting budget or delivery commitment) may require additional approval beyond the CCB. The change management plan should identify these escalation paths.

Change Request Lifecycle: From Submission to Closure

A change request should follow a defined lifecycle. The specific steps can be adapted from PMBOK's integrated change control process:

1. Submission — a change request is submitted through the authorized change channel, with a description of the requested change, the reason, and the originator
2. Impact assessment — the change is evaluated for impact on scope, schedule, cost, technical performance, safety, and integration. PMBOK recommends alternatives analysis and cost-benefit analysis as evaluation tools
3. Decision — the change is approved, rejected, or deferred by the appropriate authority (CCB, project manager, or technical lead depending on the change type)
4. Documentation — the decision and its rationale are recorded in a change log. If approved, the updated scope, schedule, cost, and configuration baselines are documented
5. Implementation — the approved change is implemented, with verification that the implementation matches the approved change request
6. Closure — the change is verified, the baselines are updated, and the change is closed in the change log

ISO 10007:2017, which provides guidelines for configuration management, includes change control as one of its five core processes. ISO 10007's change control process aligns with the lifecycle above — it addresses the identification, evaluation, approval, implementation, and verification of changes to configuration items. ISO 10007 is a guideline standard, not a mandatory requirement. Whether to adopt its practices depends on the organization, contract, and applicable regulations.

The distinction between configuration control and change control matters here. PMBOK distinguishes the two:

• Configuration control focuses on the technical specifications and physical state of deliverables — identifying configuration items, recording their status, and verifying them through audits
• Change control focuses on the process of managing changes — identifying, recording, deciding, and tracking changes

For robot projects, this means configuration control addresses "what is the current technical state of the robot?" while change control addresses "how did we decide to change it and who approved it?" Both are needed, but they serve different purposes. Configuration management across a fleet of robots is covered in a separate article — this article focuses on the contract-level change control process.

Common Change Order Pitfalls

Pitfall 1: Treating Email as a Change Order

Illustrative scenario: a buyer's engineer emails the supplier's project manager requesting a different sensor mounting bracket. The supplier's project manager replies "noted, we will adjust." The bracket is changed. Three months later, the buyer's procurement team disputes the cost because the bracket was a custom part not in the original SOW. The supplier points to the email. Whether this email constitutes an authorized change depends on the contract's change control provisions and applicable law — but if the project had defined an authorized change channel, this situation would not arise.

Pitfall 2: Approving Changes Without Impact Assessment

A change request is approved because it seems minor. But the change has downstream effects: a different end effector changes the payload, which changes the safety validation, which changes the cycle time, which changes the throughput calculation. PMBOK warns that implementing changes without considering their impact on the entire project can increase overall project risk. Every change request should go through an impact assessment, even if the assessment is brief for minor changes.

Pitfall 3: Not Updating the Configuration Baseline

A firmware update is installed during commissioning. The change is approved through the proper channel. But the configuration baseline in the SOW is never updated. When the robot is delivered, the as-built documentation references the old firmware. Six months later, a maintenance technician needs to troubleshoot an issue and cannot match the documentation to the installed software. Every approved change that affects the configuration should trigger a baseline update.

Pitfall 4: Undefined Authority for Safety-Affecting Changes

The supplier's technician adjusts the safety zone parameters during installation to accommodate a layout change. The technician has the technical capability to make the change, but does not have the authority to approve safety-affecting modifications. The change management plan should explicitly define who has authority to approve changes that affect safety functions — this may require sign-off from a safety responsible person, not just the project manager or supplier's technician.

Pitfall 5: No Change Log

The project team handles changes informally and does not maintain a change log. At project closure, there is no record of what changed, why it changed, who approved it, and what the impact was. The as-built configuration does not match the SOW, and nobody can reconstruct the chain of changes. A change log — even a simple spreadsheet — is the minimum recordkeeping requirement for any project that experiences changes.

Robot Project Change Order Checklist

Use this checklist to verify that your change control process is defined before changes start occurring. Items should be adapted based on the project scope, contract, delivery model, and applicable law.

Authorized Change Channel

• [ ] Authorized change channel defined (what communication methods are recognized)
• [ ] Informal communications (email, call, verbal) addressed in change management plan
• [ ] Legal counsel consulted on what constitutes a binding change under applicable law
• [ ] Change management plan referenced in SOW and reinforced at project kickoff

Approval Authority

• [ ] Approval authority defined by change type (baseline, technical, administrative, safety-affecting)
• [ ] CCB or equivalent approval body established (if applicable to project scope)
• [ ] Escalation paths defined for changes beyond delegated authority
• [ ] Safety-affecting changes require sign-off from defined safety responsible person

Change Request Lifecycle

• [ ] Submission process defined (form, system, required fields)
• [ ] Impact assessment process defined (scope, schedule, cost, technical, safety, integration)
• [ ] Decision process defined (who decides, timeline, documentation)
• [ ] Implementation verification process defined
• [ ] Change log maintained (request, assessment, decision, implementation, closure)

Configuration Baseline

• [ ] Configuration baseline established at time of PO (from SOW)
• [ ] Baseline update process defined for approved changes
• [ ] As-built configuration documented at project closure
• [ ] Baseline updates communicated to all relevant parties

Source List