Robot Project Statement of Work: What Buyers Should Define Before Awarding the Order

Robot Project Statement of Work: What Buyers Should Define Before Awarding the Order

A purchase order for a robot says you are buying a robot. A Statement of Work (SOW) says what the robot must do, how it will be proven to do it, who is responsible for each layer of the project, and what happens when something changes. If your SOW is one page that lists the robot model and a delivery date, you have not defined the project — you have defined an order.

Robot projects can encounter problems in the gaps between what the buyer assumed the supplier would handle and what the supplier assumed the buyer would handle. Integration responsibility, acceptance criteria, software version control, training deliverables, documentation requirements — these are the items that can determine whether the robot works when it arrives and keeps working after the project team leaves. Each one should be explicitly addressed in the SOW, not implied.

In the PMBOK framework, the project SOW is a key input to developing the project charter, alongside the contract and organizational process assets. PMBOK distinguishes between a project SOW (an internal project definition document) and a contract SOW (the document between buyer and supplier). For robot procurement, the contract SOW is the relevant artifact — it helps document agreed obligations between the buyer and the supplier. Whether the SOW's terms are enforceable depends on the complete contract, applicable law, and jurisdiction. This article covers what a robot project SOW should address before the order is awarded. It is not about selecting a supplier (that comes before the SOW) or managing changes after the order (that comes after). It is about the document that sits between selection and award.

The framework below draws on established project management and configuration management practices, including PMI's PMBOK Guide and WBS Practice Standard, ISO 10007:2017 configuration management guidelines, and public-sector procurement frameworks such as the World Bank Procurement Framework and the U.S. Federal Acquisition Regulation (FAR). These sources provide general project management and procurement principles that can be adapted to robot projects. They are not robot-specific standards, and whether any particular element applies depends on the project scope, contract, delivery model, and applicable law.

What a Robot Project SOW Should Address

A robot project SOW should consider six core areas. Not every area will carry the same weight in every project, but each area should be explicitly addressed — even if the answer is "not applicable to this project, because [stated reason]." The depth of each section should be adjusted based on the project scope, contract type, delivery model, and applicable regulatory requirements.

1. Scope of Supply and Scope of Work

These are two different things and both should be defined.

Scope of supply is what physical items and software the supplier delivers: the robot arm, controller, end effector, cables, teach pendant, safety controllers, software licenses, spare parts kit, and any ancillary equipment. Each item should be listed with part numbers, quantities, and revision identifiers where applicable.

Scope of work is what services the supplier performs: site survey, installation, commissioning, integration with existing equipment, programming, safety validation, training, and documentation delivery. Each service should have a defined deliverable, a responsible party, and an acceptance criterion.

The SOW should make explicit which items are included in the supplier's scope and which are the buyer's responsibility. Common gaps include:

• End effector design and fabrication — is the supplier providing a standard gripper, designing a custom end effector, or is the buyer sourcing it separately?
• Safety perimeter and interlocks — is the supplier providing the safety fence, light curtains, and interlock controllers, or is the buyer's integrator responsible?
• Network integration — is the supplier responsible for connecting the robot to the factory network, PLC, or MES/WMS system, or does that responsibility end at the robot controller's network port?
• Utilities — who provides power, air, and cooling to the robot cell?

2. Integration Responsibility Boundaries

Robot projects may involve multiple parties: the robot supplier, the end effector supplier, the safety system integrator, the IT/network team, the facility engineering team, and sometimes a third-party system integrator. The SOW should define where each party's responsibility starts and ends.

Consider defining these boundary points explicitly:

• Mechanical boundary — where does the robot supplier's mechanical responsibility end? At the robot base plate? At the end of the arm? At the tool flange? At the end effector tip?
• Electrical boundary — who provides power to the robot? Who provides power to the safety controllers? Who wires the safety interlocks between the robot and peripheral equipment?
• Control boundary — who programs the robot motion? Who programs the safety logic? Who integrates the robot controller with the PLC or factory control system?
• Network boundary — who configures the robot's network settings? Who is responsible for network security? Where does the supplier's network responsibility end and the buyer's IT team's begin?
• Safety validation boundary — who performs the risk assessment? Who validates that the integrated cell meets applicable safety requirements? Is this the supplier's responsibility, the integrator's, or a third-party assessor's?

If the SOW does not define these boundaries, each party may assume the other is handling it. The gap may surface during installation or commissioning, when it is typically more costly to resolve.

3. Acceptance Criteria

The SOW should consider defining what "done" looks like. This may include acceptance criteria at two stages:

Factory Acceptance Test (FAT) — what the supplier demonstrates before the robot ships. This may include:

• Functional demonstration of motion, speed, and accuracy under defined test conditions
• Safety function verification (emergency stop, protective stop, collaborative mode operation if applicable)
• Software and firmware version confirmation
• Visual inspection of workmanship, cabling, and labeling
• Performance test results against stated specifications

Site Acceptance Test (SAT) — what the robot demonstrates after installation at the buyer's facility. This may include:

• Repeatability and accuracy under actual application conditions (payload, speed, environment)
• Integration with peripheral equipment (conveyors, vision systems, safety systems)
• Cycle time verification under production conditions
• Safety system validation in the final integrated configuration
• Operator and maintenance training completion

FAT and SAT are established acceptance practices in equipment procurement. Whether to use one or both, and what specific tests to include, depends on the project scope, contract, and delivery model. The SOW should consider specifying who defines the test plan, who witnesses the tests, what the pass/fail criteria are, and what happens if a test fails. If the SOW does not define acceptance criteria, the buyer may have a weaker documented basis to address a robot that technically "works" but does not meet the application's requirements. Contract remedies for non-conformance depend on the complete contract and applicable law.

Note: FAT and SAT are covered in detail in a separate broad guide. This SOW section only addresses that the SOW should consider referencing and defining them — not how to design them.

4. Software, Firmware, and Configuration Baseline

The SOW should consider recording the software and firmware baseline at the time of order. This means documenting:

• Robot controller firmware version
• Motion control software version
• Safety controller firmware version
• Any application-specific software or parameters
• End effector control software version (if applicable)
• Network configuration parameters
• Map files or navigation parameters (for mobile robots)

Why this matters: suppliers may update firmware and software periodically. Illustrative scenario: a robot delivered six months after an initial demo may run a different firmware version than the one that was demonstrated. If the SOW does not lock the baseline, the buyer may have a weaker documented basis to request the tested version or to require that updates be validated against the application configuration.

The SOW should also consider addressing:

• Whether the supplier should notify the buyer of firmware updates during the warranty period
• Whether the agreement grants a review or approval process for updates that may affect safety functionality — whether the buyer has a right to review or refuse such updates depends on the specific contract terms, not on an assumed default right
• What documentation of the installed configuration the supplier should deliver (parameter files, map files, program files)

ISO 10007:2017 provides guidelines for configuration management, including configuration identification and change control processes. These guidelines can inform how the SOW addresses software baseline management. ISO 10007 is a guideline standard, not a mandatory requirement — whether to adopt its practices depends on the organization, contract, and applicable regulations.

5. Training and Knowledge Transfer

The SOW should consider defining what training the supplier will deliver, to whom, and with what content. A vague line item for "operator training" is not sufficient.

Consider defining training by role:

The durations above are illustrative — actual training needs depend on the robot type, application complexity, and the skill level of the receiving team.

The SOW should consider specifying:

• Number of training sessions and number of participants per session
• Whether training is on-site, at the supplier's facility, or remote
• Whether training materials (manuals, videos, presentations) are included as deliverables
• Language of training and materials
• Whether refresher training is included and within what timeframe

6. Documentation Deliverables

The SOW should consider listing every document the supplier should deliver, with format, language, and delivery timing:

• Installation manual
• Operation manual
• Programming manual
• Maintenance manual (including preventive maintenance schedule and spare parts list)
• Safety documentation (risk assessment, safety function description, validation report if applicable)
• Electrical and mechanical drawings
• Software and firmware documentation (installed versions, parameter files, backup procedures)
• Compliance documentation (declarations, test reports, certificates — as applicable to the robot type and destination market; applicability should be confirmed by a qualified compliance consultant)
• Training materials

The SOW should consider defining when each document is delivered: before shipment (for engineering review), at delivery (for installation), or after commissioning (for as-built documentation).

Common SOW Gaps That Can Cause Project Problems

Gap 1: "Integration" Without a Defined Boundary

The SOW says "supplier will integrate the robot into the production line." But integration has many layers: mechanical mounting, electrical wiring, safety interlocks, PLC communication, MES/WMS integration, and network security. If each layer is not assigned to a specific party, the integration may stall at the first undefined boundary.

Gap 2: Acceptance Criteria Based on Robot Specifications, Not Application Requirements

The SOW references the robot's datasheet specifications as acceptance criteria. But datasheet specifications are measured under controlled test conditions that may not match the application environment. The SOW should consider defining acceptance criteria based on the application's actual requirements — cycle time with the real payload, accuracy with the real end effector, uptime in the real environment — not just the robot's rated performance.

Gap 3: Software Baseline Not Locked

Illustrative scenario: a supplier demonstrates a robot running firmware version 3.2. The delivered robot runs firmware version 3.5, which has a different motion planning algorithm that may affect cycle time. Without a locked baseline in the SOW, the buyer may have a weaker documented basis to request version 3.2 or to require that version 3.5 be validated against the application before deployment. Whether the buyer can require a specific version depends on the contract terms and applicable law.

Gap 4: Training Treated as a Line Item

"Training: included" is not a deliverable. The SOW should consider defining training by role, content, duration, format, materials, and language. Without these details, the supplier may deliver a brief overview session when the maintenance team needs a multi-day hands-on workshop. Illustrative scenario: a two-hour general session versus a multi-day role-specific workshop — the difference matters, and the SOW should specify which the project requires.

Gap 5: No Defined Change Process

Even before the order is awarded, the SOW should consider referencing how changes will be handled after award. This does not need to be a full change management procedure (that is covered in a separate article on change orders), but the SOW should state that any scope additions, configuration changes, or schedule modifications after award should be handled through a defined change order process. The project team, with legal counsel, should define what constitutes an authorized change channel, who has approval authority, and what recordkeeping is required. Whether informal communications (email, verbal) carry contractual weight depends on the applicable law and the complete contract — the SOW should not assume that informal channels are automatically excluded, but should instead establish the authorized process explicitly.

Robot Project SOW Checklist

Use this checklist to consider whether your SOW addresses the items above before awarding the order. Items should be adapted based on the project scope, contract, delivery model, and applicable law.

Scope

• [ ] Scope of supply lists all physical items with part numbers and quantities
• [ ] Scope of work lists all services with deliverables and responsible parties
• [ ] Items explicitly excluded from supplier scope are listed

Integration Boundaries

• [ ] Mechanical boundary defined (where supplier responsibility ends)
• [ ] Electrical boundary defined
• [ ] Control boundary defined (who programs motion, safety, integration)
• [ ] Network boundary defined (where supplier IT responsibility ends)
• [ ] Safety validation responsibility assigned

Acceptance Criteria

• [ ] FAT requirements considered (what should be demonstrated before shipment)
• [ ] SAT requirements considered (what should be demonstrated after installation)
• [ ] Test plan responsibility assigned (who writes, who witnesses, who approves)
• [ ] Pass/fail criteria stated
• [ ] Remediation path defined (what happens if a test fails)

Software and Configuration

• [ ] Firmware and software versions documented at time of order
• [ ] Configuration parameters documented
• [ ] Update notification requirements during warranty considered
• [ ] Review/approval process for safety-affecting updates addressed in contract

Training

• [ ] Training considered by role (operators, maintenance, engineering, IT)
• [ ] Duration, format, and language specified for each role
• [ ] Training materials listed as deliverables
• [ ] Number of sessions and participants defined

Documentation

• [ ] Required documents listed with format and language
• [ ] Delivery timing defined (pre-shipment, at delivery, post-commissioning)
• [ ] Compliance documentation included (as applicable to robot type and destination market)

Change Management

• [ ] SOW references a change order process for post-award modifications
• [ ] Authorized change channels, approval authority, and recordkeeping defined with legal counsel

Source List