Systems Integrator Scope of Work: Template and Pitfalls

An illustrative scenario, typical of what we see on controls projects rather than a description of any one client.

A Plant Manager signs a fixed-price proposal for a packaging-line controls retrofit. The proposal lists three bullet points of deliverables and a price. Nine months later the line runs, but the integrator has invoiced two change orders for the historian and the ERP tie-in, the PLC program is locked because nobody agreed who owns the source code, and the factory acceptance test passed against criteria nobody wrote down. The retrofit worked, and the project still ran a third over budget.

Almost every dispute on a controls project traces back to what the systems integrator scope of work failed to say. The proposal was a price and three bullets, not a document that defined the work. This post walks every section an automation scope of work needs, hands over a section template you can adapt, shows how to write acceptance criteria that define done and trigger payment, and names the scope failures that recur on controls projects so you can catch them before you sign.

Why a Generic Scope of Work Template Fails on Controls Projects

A scope of work describes the work itself: the tasks, deliverables, boundaries, and acceptance criteria. It usually sits as a section inside the broader statement of work, which adds the commercial and legal terms such as price, schedule, and warranty. On a controls project, the scope of work is the part that defines the engineering, and it is the part most proposals shortchange.

Search for a scope of work template and you find contract-generic documents. They name deliverables, milestones, and a price, and they explain the difference between a scope of work and a statement of work. None of them names an I/O list, a functional requirements specification, a factory acceptance test, or controller responsibility. The gaps a generic template leaves are exactly the ones that turn into change orders on a controls project, because the engineering questions it never asks are the ones that decide cost.

The other content that ranks comes from integrators describing how they scope their own work. That is useful, but it is written from the seller’s side. The plant is the party whose capital is at risk and who lives with the delivered system for the next 15 years. The scope of work should be written from that side, which means it specifies what the plant needs to accept the system, not just what the integrator intends to deliver. For the wider arc of selecting, contracting, and overseeing an integrator, see Joltek’s guide to working with systems integrators.

The fix is not a longer document. A 40-page generic template still misses the I/O list. The fix is a controls-specific scope of work that names the engineering artifacts, splits responsibility item by item, and defines done in measurable terms. The rest of this post is that document, section by section.

What a Systems Integrator Scope of Work Must Contain

An automation scope of work needs the following sections. Treat this as the table of contents for the document, then fill each one with plant-specific detail.

Section	What it states	What goes wrong without it
Objectives and success criteria	What the system must do in plant terms	Nothing to accept against: “install a new PLC” has no pass mark
Deliverables	The concrete artifacts the integrator hands over	An outcome (“a working line”) that cannot be inspected at a table
Functional requirements specification (FRS)	Control narrative, sequence of operations, I/O list, alarm list	A thin acceptance, where the integrator decides what done means
Hardware and software responsibility matrix	Who buys, configures, installs and commissions each item	Items owned by everyone, so by no one, until commissioning
Integration boundaries and terminal points	Where the integrator’s scope stops	The panel-to-field wiring, network drop or OEM handoff nobody priced
Standards and documentation requirements	Code, tag-naming and drawing standards, and the document set	A system only its author can support
Acceptance criteria	The FAT and SAT that define done	Done becomes negotiable at the worst possible moment
Change-order process	How a change is requested, priced and approved	Changes absorbed as schedule slip or a year-end renegotiation
Schedule and milestones	Milestones tied to acceptance events	Progress measured by the calendar, not by passed tests
Payment terms	Payment tied to the same milestones	Money that moves whether or not the work passed its test
Warranty and support	Period, coverage and response	Nobody owning firmware, patches and spares after handoff
Intellectual property and source-code ownership	Who owns the program and what the plant receives	A plant that owns the hardware and cannot change a setpoint
Training and handoff	Named deliverables with their own acceptance	Training and as-builts treated as informal courtesies

Download the template: the Systems Integrator Scope of Work Template (PDF) lays out all thirteen sections with prompts, a responsibility matrix, an acceptance test script and a pre-signature checklist.

A few of these deserve attention here, and the deeper ones get their own sections below.

Objectives and success criteria come first because they govern everything downstream. State what the system must achieve in plant terms: a throughput target in units per hour, a cycle-time ceiling, a recipe or product-changeover count, a downtime target, or a yield figure. A scope of work that says “install a new PLC” has no objective to accept against. A scope of work that says “the line shall run 120 cases per minute with changeover under 10 minutes” gives every later test something concrete to measure.

Deliverables come next, and the word that matters is artifacts. A deliverable is a thing the plant can take possession of and verify: an approved FRS, a complete drawing set, a tested control panel, the PLC and HMI source code, as-built documentation, and signed test records. A scope of work that lists “a functioning packaging line” as the deliverable has named an outcome, not an artifact, and an outcome cannot be inspected at a table. Name the artifacts and the format each arrives in, including native project files rather than read-only exports.

The functional requirements specification is the spine of the document. It captures the control narrative, the sequence of operations, the I/O list, and the alarm list. Acceptance is measured against the FRS, so a thin FRS produces a thin acceptance, which means the integrator decides what done means. Insist the FRS be approved before the build starts, not reverse-engineered from the finished system. A practical test of a good FRS: a second integrator could read it and build the same system, because the behavior is described rather than assumed.

Standards and documentation requirements protect the plant’s ability to sustain the system after the integrator leaves. Name the code standard, the tag-naming convention, the drawing standard, the as-built requirement, and the specific documents to hand over. Anchoring these to a recognized reference such as the CSIA Best Practices and Benchmarks gives both sides a common expectation for what a documented, well-managed project looks like, because certified integrators are audited against scope and change-management practices in that manual.

The Responsibility Matrix and Integration Boundaries

Two sections separate a real systems integrator scope of work from a generic one, and they are the two most proposals skip: the responsibility matrix and the integration boundaries.

The hardware and software responsibility matrix lists every item on the project and assigns who is accountable for each phase of it. Apply a RACI discipline, where every item has exactly one accountable owner. When an item is owned by everyone, it is owned by no one, and it surfaces as a finger-pointing meeting at commissioning. A compact version looks like this.

Item	Buy	Configure	Install	Commission
PLC hardware	Integrator	Integrator	Electrical contractor	Integrator
Control panel	Integrator	Integrator	Plant	Integrator
Field wiring	Plant	n/a	Electrical contractor	Integrator
PLC program	Integrator	Integrator	n/a	Integrator
HMI and SCADA	Integrator	Integrator	n/a	Integrator
Historian and server	Plant	Integrator	Plant IT	Integrator

The real document carries more rows: network switches, the server operating system, the database, remote access, and any OEM machine controls already on the floor. The point is that each row has a named owner for each column, so nothing falls into the gap between vendors.

Integration boundaries and terminal points define where the integrator’s responsibility ends and someone else’s begins. Name them explicitly. The classic boundary disputes are the panel-to-field-device wiring, the network drop into the plant’s IT infrastructure, the handoff to ERP or MES, and the existing controls on an OEM machine the new system has to talk to. Each of these is an interface, and each interface should be classified by risk and assigned a single point of responsibility. An unnamed boundary is a change order waiting to happen, because the integrator priced its side of the line and assumed someone else owned the rest.

The cost of leaving boundaries implicit is paid at commissioning, when the line will not start because the field wiring terminated to the wrong points and neither the integrator nor the electrical contractor scoped the reconciliation. A paragraph in the scope of work that says “the integrator terminates and verifies all I/O to the field junction boxes listed in drawing E-204; field-side wiring from junction box to device is by the plant’s electrical contractor” prevents the entire dispute.

The ERP or MES interface deserves its own boundary statement, because it is where two organizations and two skill sets meet. The integrator typically owns the PLC and SCADA side of the connection, and the plant’s IT or enterprise team owns the business-system side, with a defined message format, transport, and data dictionary in between. State who builds the interface, who supplies the message specification, who tests it end to end, and what counts as a passing test, or the interface becomes the last unfinished item on a project everyone thought was done.

Acceptance Criteria: FAT, SAT, and the Definition of Done

Acceptance criteria are the clause in the systems integrator scope of work that says when the work is finished and the milestone is payable. Without written criteria, done is whatever the integrator declares at the test, and the plant has no standing to withhold a payment or a sign-off. This is the clause that converts the functional requirements specification into a gate.

A factory acceptance test (FAT) is witnessed testing at the integrator’s shop, run against the FRS before the system ships. It uses a test script with expected results and a pass or fail recorded for each item. A site acceptance test (SAT) is the equivalent at the plant on the installed system, including field I/O and live process behavior that the shop test could only simulate. The scope of work should require both, name who witnesses each, and state that the plant signs off before the project advances.

Every test case ties back to a specific FRS line, a P&ID reference, or a named standard, so acceptance is traceable rather than subjective. IEC 62381, whose third edition (2024) sets out requirements and checklists for FAT, SAT and site integration testing of automation systems in the process industry, gives the acceptance section a citable basis when the plant and integrator disagree on what a test should prove. The standard frames itself as a way for the owner, the buyer and the vendor to agree the scope and responsibilities of each test up front, which is exactly the job of this clause. Build the test script as a table that maps each requirement to its test case and its pass criterion, and the FAT stops being a demonstration and becomes a verification. How that verification runs on the day (entry criteria, the four-day rhythm, Critical, Major and Minor defects, and what gets signed before shipment) is covered in our factory acceptance test guide.

Scope gaps should surface before the FAT, not at it. A review cadence of 30, 60, and 90 percent design reviews catches the missing historian tag or the unscoped interface while it is still cheap to fix, and the project culminates in a final factory acceptance test with the plant present. Automation World’s account of navigating system integration projects describes this rhythm of kickoff alignment, staged design reviews, and a witnessed FAT, and it is the cadence that keeps acceptance from becoming a surprise.

Two items belong inside FAT scope that proposals often defer. Data and historian behavior, including OPC UA connectivity and the capture of the tags the plant actually needs, should be tested at the FAT, not discovered missing at the SAT. Cybersecurity validation, such as account hardening and remote-access controls, is now a standard part of acceptance for any networked control system and belongs in the test plan rather than as a follow-up.

Commercial Terms: Schedule, Change Orders, Payment, Warranty, and IP

The commercial half of the systems integrator scope of work is where the plant keeps its negotiating position. Five clauses carry most of the protection.

Schedule and milestones should tie to acceptance events, not calendar dates alone. A milestone for an approved FRS, a milestone for a passed FAT, a milestone for a passed SAT, and a milestone for a closed punch list each mark a verifiable state of the work. Payment tied to those events means money moves when the work passes, not when a date arrives. For how milestones fit the wider arc of selecting, contracting and overseeing an integrator, see the systems integrator playbook.

The change-order process is what keeps scope creep visible and priced instead of silent. The scope of work names how a change is requested, how it is priced, who approves it, and that no out-of-scope work proceeds without a signed change order. A project without a change-order clause does not avoid changes; it absorbs them as schedule slip or as a year-end renegotiation. Configuration management, the practice of controlling change across every deliverable, is part of what audited integrators are expected to run, and the change-order clause is where the plant holds them to it.

Fixed price versus time and materials is a scope decision as much as a commercial one. A fixed price transfers the risk of overruns to the integrator, but it is only meaningful against a tight scope, because a vague scope makes the price unenforceable the moment reality diverges from the assumption. Time and materials suits discovery or genuinely ill-defined work, but it transfers cost risk to the plant. A common and defensible pattern is time and materials for a definition or assessment phase that produces the FRS, then a fixed price for the build once the scope is actually known. Pricing a build fixed before the FRS exists is pricing a guess.

Warranty and support name the warranty period, what it covers, the response time for a defect, and whether a separate support agreement follows. Spare-parts responsibility and software-update responsibility belong here too, so the plant knows who carries firmware and patch obligations after handoff.

Intellectual property and source-code ownership is the clause every generic template omits and the one that strands plants. The scope of work must state who owns the PLC program, the HMI and SCADA application, and the project files, that the plant receives commented source code and project files at handoff, free of passwords and source protection, and whether a source-code escrow arrangement applies. Without this clause, a plant can own the hardware outright and still be unable to change a setpoint, because the program is locked and the only copy lives with the integrator. Training and handoff close the document: operator and maintenance training, the as-built documentation set, and the final handoff package are named deliverables with their own acceptance, not informal courtesies.

The Most Common Systems Integrator Scope of Work Pitfalls

The failures below recur across controls projects. Check any scope of work on your desk against them before signing.

Scope creep starts early, not late. Practitioners who recover troubled projects find that the creep traces to early omissions rather than late additions. Data requirements, historian capture, ERP or MES integration, OT infrastructure, and cybersecurity get under-scoped at the front end, then surface as change orders at the point where they are most expensive to add. The PMI’s scope research puts unclear objectives among the leading causes of project failure, and a controls scope of work that never named the historian was always going to pay for it later.

The other recurring pitfalls:

• No source-code ownership clause. The plant owns the line and cannot change the program.
• Acceptance criteria written after the FAT, or not at all. Done becomes negotiable at the worst possible moment.
• Unassigned integration boundaries. The panel-to-field wiring, the network drop, and the OEM machine handoff that nobody scoped.
• Deliverables named as outcomes, not artifacts. “A working line” cannot be accepted; an FRS, a drawing set, as-builts, source code, and signed test records can.
• Milestones tied to dates, not acceptance. Payment flows whether or not the work passed its test.
• No change-order process. Every change becomes a renegotiation or a silent absorption that lands as a schedule slip.

Each of these is a sentence the scope of work failed to write. A controls scope of work that names the artifacts, splits the responsibility, defines acceptance against the FRS, and assigns ownership removes most of the ambiguity that these failures live in. The document does not have to be long. It has to be specific.

Frequently Asked Questions About the Systems Integrator Scope of Work

What is the difference between a scope of work and a statement of work?

The scope of work describes the work itself: the tasks, deliverables, boundaries, and acceptance criteria. The statement of work is the broader document that wraps the scope of work with commercial and legal terms such as payment, schedule, and warranty. On a controls project, the scope of work is the engineering core inside the statement of work, and it is the part that defines what the integrator builds and how the plant accepts it.

Who owns the PLC and HMI source code after a systems integrator finishes?

Whoever the scope of work says owns it, which is why the clause matters. Without a written clause, ownership and access are ambiguous, and an integrator can hand over a locked or password-protected program. A protective scope of work states that the plant receives commented source code and project files for the PLC, HMI, and SCADA at handoff, free of passwords and source protection, and whether a source-code escrow arrangement applies.

What is the difference between a FAT and a SAT?

A factory acceptance test (FAT) is witnessed testing at the integrator’s shop against the functional requirements specification before the system ships. A site acceptance test (SAT) is the equivalent at the plant on the installed system, including field I/O and live process behavior. Both should run against written, traceable criteria, where each test case ties back to a specific requirement, P&ID reference, or standard.

Should an automation project be fixed price or time and materials?

Fixed price transfers the risk of overruns to the integrator and requires a tight scope of work to be meaningful, because a vague scope makes a fixed price unenforceable. Time and materials suits discovery or ill-defined work but transfers cost risk to the plant. A common pattern is time and materials for a definition or assessment phase, then a fixed price once the functional requirements specification is set.

What should a systems integrator scope of work include?

A controls scope of work should include objectives in plant terms, deliverables named as artifacts, a functional requirements specification, a hardware and software responsibility matrix, integration boundaries and terminal points, standards and documentation, FAT and SAT acceptance criteria, a change-order process, milestones and payment tied to acceptance, warranty and support, source-code ownership, and training and handoff. The responsibility matrix, the boundaries and the source-code clause are the sections generic templates leave out.

Who should write the scope of work, the plant or the integrator?

The plant, or an independent advisor acting for it, should write the scope of work before integrators are asked to price it. An integrator-written scope describes what that integrator intends to deliver, not what the plant needs to accept the system. When the plant cannot write it alone, a paid definition phase that produces the functional requirements specification gives every bidder the same document to price against.

A Scope of Work Is the Document That Defines Done

The systems integrator scope of work is the document that defines done, controls payment, and assigns ownership of the delivered system. Most controls-project disputes are not failures of engineering; they are failures of the document that traced back to a sentence it never wrote. The section template in this post, the responsibility matrix, the acceptance criteria tied to the functional requirements specification, and the source-code clause are the parts that protect the plant, and they are the parts generic templates leave out.

Before signing the next proposal, check it against the sections above and the pitfalls list. If a clause is missing, that is the clause that becomes a change order. For an independent review of a vendor-proposed scope before it is signed, Joltek acts as the plant’s owner’s engineer, and that question is exactly what the role is for. When we deliver the build ourselves, our systems integration work is written against the same sections, so the plant can check us the way this post says to check anyone.