Robot Project Governance: What Operations, IT, Facilities, Safety, and Procurement Each Need to Own

Robot projects fail between departments, not just in the robot. A robot that meets its technical specifications can still stall during deployment because IT was not told that the robot needs a dedicated Wi-Fi network, or because Facilities was not informed that the robot requires a specific power circuit, or because Safety was not consulted before the robot was installed in a shared workspace. This article explains the governance model that prevents these gaps—a model that defines what each department owns before, during, and after robot deployment.

Why Robot Projects Fail Between Departments, Not Just in the Robot

A recurring governance risk in robot deployment is not a technical failure of the robot. It is an organizational failure where the work that connects the robot to the production environment falls into the gap between departments.

The following are illustrative examples of gap failures:

• IT does not know that the robot needs Wi-Fi coverage across all routes, not just at the docking station. The robot deploys, navigates to the far end of the warehouse, loses connection, and stops.
• Facilities does not know that the robot requires a dedicated 20-amp circuit. The robot is plugged into a shared circuit, trips the breaker during peak load, and shuts down.
• Procurement does not know that integration engineering is excluded from the supplier’s quotation. The robot arrives, no one is contracted to install it, and it sits in the shipping crate for three weeks.
• Safety does not know that the robot operates in a shared workspace with pedestrians. The robot deploys without a risk assessment, an incident occurs, and the robot is shut down pending investigation.
• Operations does not know that the robot requires a dedicated operator for exception handling. The robot deploys, exceptions occur, no one is assigned to handle them, and the robot sits idle waiting for support.

Each of these failures is preventable with a governance model that defines, before deployment begins, who owns each deliverable and who must be consulted at each stage.

Operations: Workflow, KPIs and Exception Handling

Operations owns the production process that the robot supports. The operations team’s responsibilities in a robot project include:

Before Deployment

• Define the current workflow and the expected workflow after robot deployment
• Define the KPIs the robot must meet (throughput, task success rate, cycle time, coverage)
• Identify the shift structure, peak periods, and maintenance windows
• Define exception handling procedures: what happens when the robot faults, mispicks, or goes off-path

During Deployment

• Participate in commissioning to validate that the robot integrates into the production workflow
• Train operators on the SOP
• Define the baseline performance measurement (before robot vs. after robot)

After Go-Live

• Monitor daily performance against KPIs
• Handle routine exceptions per the SOP
• Escalate non-routine issues to the appropriate level
• Own the robot’s operational performance and utilization

The operations team is typically the primary user of the robot after go-live, which means they should have a voice in the deployment scope and acceptance criteria—not just receive the robot after it is installed.

IT/OT: Network, Accounts, APIs, Data and Security

IT/OT owns the digital infrastructure that the robot connects to. Their responsibilities include:

Network Infrastructure

• Verify Wi-Fi coverage across all robot routes (measured, not assumed)
• Allocate IP addresses and configure VLANs
• Configure firewall rules for robot-to-cloud and robot-to-WMS communication
• Ensure network capacity for the expected number of robots (bandwidth, latency, roaming)

System Integration

• Configure API access between the robot and WMS/MES/ERP systems
• Set up data flows for task assignment, status reporting, and error logging
• Verify that the robot’s communication protocols are compatible with the site’s OT infrastructure

Security and Access

• Manage user accounts and permissions for the fleet management platform
• Define data ownership: who owns the robot’s operational data, where is it stored, and who can access it
• Configure remote access for supplier support (if applicable) with appropriate security controls
• Ensure compliance with the enterprise’s cybersecurity policies

After Go-Live

• Monitor network performance and its impact on robot operation
• Manage software and firmware updates
• Maintain API connections and troubleshoot integration failures
• Audit access logs and security configurations periodically

The IT/OT team’s involvement should begin at the RFP stage, not at installation. Network readiness is a prerequisite for deployment, and discovering network gaps after installation causes significant delays.

Facilities: Power, Water, Drainage, Doors, Elevators and Space

Facilities owns the physical infrastructure that the robot operates within. Their responsibilities include:

Power and Utilities

• Install and verify the dedicated power supply required by the robot (correct voltage, amperage, and circuit)
• Install water supply and drainage connections (for cleaning robots, if applicable)
• Install compressed air connections (if required for pneumatic end-effectors)
• Verify that the floor can support the robot’s weight and dynamic loads

Physical Infrastructure

• Prepare the floor surface (flatness, load capacity, surface material)
• Install or modify doors, barriers, and safety perimeters
• Install or verify elevator controller interfaces (for mobile robots)
• Install charging stations and ensure adequate space and power for them

Space and Access

• Allocate floor space for the robot, charging station, spare parts storage, and maintenance access
• Ensure that robot routes are clear of obstacles and meet width and clearance requirements
• Coordinate with other facility users (forklift traffic, pedestrian routes, storage areas)

After Go-Live

• Maintain floor conditions (cleaning, repair, surface treatment)
• Manage changes to the facility layout that affect robot routes
• Coordinate utility maintenance that may affect robot operation (power outages, water shutoffs)

Safety/EHS: Risk Assessment and Operating Procedures

Safety/EHS owns the safety compliance and risk management for the robot deployment. Their responsibilities include:

Before Deployment

• Conduct or review the risk assessment for the installed configuration
• Define the safety zones, speed limits, and pedestrian separation requirements
• Verify compliance with applicable safety standards. For industrial robot applications: ISO 10218-1:2025 and ISO 10218-2:2025 (internationally), ANSI/A3 R15.06-2025 (United States). For collaborative industrial applications: ISO/TS 15066:2016 within its scope. For driverless industrial trucks / many AMR applications: ISO 3691-4:2023. These standards must not be generalized to robot types or applications outside their scope.
• Define the emergency stop and recovery procedures

During Deployment

• Validate that safety systems (light curtains, area scanners, safety PLC) are correctly installed and configured
• Verify that safety zones match the actual layout and traffic patterns
• Review and approve the operator SOPs from a safety perspective

After Go-Live

• Monitor safety incidents and near-misses
• Conduct periodic safety audits
• Update the risk assessment when the layout, robot configuration, or operational use changes
• Manage regulatory inspections and compliance documentation

The appropriate Safety/EHS function should be involved early enough to review applicable requirements before equipment and system design decisions are finalized. Some robots may not meet the site’s safety requirements, and discovering this after purchase is costly.

Procurement: Scope, Commercial Terms, Documentation and Supplier Accountability

Procurement owns the commercial relationship with the supplier and the contractual framework that governs the project. Their responsibilities include:

Before Purchase

• Define the RFP scope and ensure that all integration, training, and support requirements are included
• Negotiate commercial terms: price, payment schedule, delivery terms, warranty, and service level agreements
• Ensure that the contract defines responsibility for FAT, SAT, installation, commissioning, and ongoing support
• Verify that the contract includes change order procedures and dispute resolution mechanisms

During Deployment

• Track actual costs against the quotation and flag scope changes that may result in additional charges
• Manage the supplier relationship and escalation
• Ensure that all contractual deliverables (documentation, training, spare parts) are received

After Go-Live

• Manage warranty claims and service contract renewals
• Track supplier performance against SLA commitments
• Maintain the supplier accountability framework for ongoing support

Who Owns the Robot After Go-Live?

One of the most frequently unanswered questions in robot governance is: “Who owns the robot after it goes live?” The answer is not the supplier, the integrator, or the project team—it is the operating site. But “the site” is not a person; it is a collection of roles that must be defined.

Without this ownership matrix, the robot becomes orphaned after the project team departs. No one is sure who is responsible for what, and issues fall through the gaps until they become emergencies.

RACI-Style Governance Checklist for Robot Projects

The following RACI matrix defines, for each major project deliverable, who is Responsible (does the work), Accountable (approves the work), Consulted (provides input), and Informed (kept in the loop).

This matrix is an illustrative governance model. Different organizations have different responsibility structures—the RACI assignments should be formally confirmed by the organization’s project governance process. The key principle is that every deliverable has exactly one Accountable party—no deliverable should have shared accountability, because shared accountability means no accountability. In the Go-live authorization row, Operations is Accountable for the decision in this example, but the organization’s governance process should include documented safety approval before go-live. If safety compliance is not met, the robot should not go live regardless of Operations’ authorization.

Research Sources Used

1. Source / organization: IEEE (project governance and cross-functional responsibility frameworks) | URL: https://ieeexplore.ieee.org/ | Version/date: as cited in report_batch_b
2. Source / organization: ISO (ISO 10218-1:2025, ISO 10218-2:2025, ISO/TS 15066:2016, ISO 3691-4:2023) | URL: https://www.iso.org/ | Version/date: as applicable
3. Source / organization: ANSI/A3 (R15.06-2025) | URL: https://www.a3automate.org/ | Version/date: 2025

Internal product/material source: report_batch_b (batch B research report) [TO VERIFY]: none