The Systems Integrator Playbook: A Plant's Guide

The scenario below is a composite, drawn from patterns that recur across integrator projects rather than from any single client.

A VP of Engineering signed a $1,800,000 packaging line modernization contract with a well-known systems integrator last spring. By month eight, the line was three months behind schedule, the change-order log had crossed $420,000, the plant’s internal controls engineer had quit, and the integrator was presenting a recovery plan that asked for another $350,000. Nothing the VP reviewed before signing predicted any of this. The integrator did nothing strictly wrong. The plant did nothing strictly wrong. The project failed anyway.

The failure had one root cause. The plant did not run a systems integrator playbook. Integrators have one. The Control System Integrators Association publishes its Best Practices and Benchmarks Manual, which defines what a well-managed integrator looks like across 10 management areas. Plants have no equivalent. This post fills that gap. It names the six stages of an integrator engagement, the red flags that appear in proposals, the scope discipline that prevents change-order abuse, and the triggers that move a project from routine oversight into formal recovery.

What a Systems Integrator Playbook Actually Covers

A systems integrator playbook is the set of practices, documents, and oversight disciplines a plant uses to buy, scope, contract, oversee, commission, and hand off work performed by an outside systems integrator. The playbook is owned by the plant, not by the integrator. An integrator-authored playbook is the integrator’s sales process, which is a different document with a different purpose.

The six stages of the arc, the document that closes each one, and the failure that follows when the stage is skipped or compressed:

Stage	What the plant does	Document that closes the stage	What goes wrong if it is skipped
1. Selection and qualification	Filters for domain, platform, geography and size; calls every reference	A short list of four to six firms, with named staff committed in writing	Junior staff assigned to the project, or a firm learning the domain on the plant’s budget
2. RFP and scope of work	Writes objectives, deliverables, exclusions and measurable acceptance criteria before the integrator is chosen	The scope of work, ideally authored by the plant or its advisor	Every gap becomes a change order during execution
3. Contract and commercial terms	Names the change control board, caps time and materials, sets retention and source-code ownership	The signed contract	Change orders the plant never approved, and a plant that cannot edit its own logic
4. Execution and progress oversight	Runs progress reviews and gate reviews; owns the risk register	Signed gate reviews that release each phase and payment	A quiet slide toward a loud discovery at commissioning
5. Commissioning: FAT and SAT	Witnesses FAT at the shop and owns the SAT protocol at the plant	Signed FAT and SAT reports with every defect classified	Go-live with an unsigned SAT, after which the plant’s leverage drops fastest
6. Handoff and sustainment transition	Checks every handoff deliverable and runs the 30 to 90 day transition	The signed handoff package	A routine change, months later, that needs a purchase order to the integrator

Each stage has its own work products, its own discipline, and its own failure modes. A plant that runs all six well rarely ends up in the opening vignette. A plant that skips or compresses any of them routinely ends up there. What a systems integrator actually does is deliver the scope of the contract. What a systems integrator does not do, and is not paid to do, is represent the plant’s interests across the six stages. That is the plant’s job, or the job of an advisor the plant hires to act on its behalf.

On the integrator side, the CSIA Best Practices and Benchmarks Manual (version 6.1 as of October 2026) covers 10 management areas, and Control Engineering reports the certification audit at 76 criteria. A CSIA certified integrator has passed an independent audit against those criteria. This is a meaningful signal, though not a sufficient one by itself. A comparable, plant-side manual does not exist, which is why most plants build their own playbook out of scar tissue rather than published standards. This post is a structured starting point for that playbook.

The sections that follow walk each stage of the arc in the order a real engagement unfolds. The two sections after the arc address scope drift and change-order mechanics (stage 3 in practice, not on paper) and the escalation triggers that send a project into recovery. The final section differentiates the four actors a plant can involve in an automation project (consultant, integrator, vendor, and internal team) and names which one does what. The thesis that runs through every section is the same: the integrator is not the plant’s advisor. Every section of the playbook is an answer to what the plant does, with or without a formal advisor, because the integrator will not.

The Role of the Plant’s Independent Technical Advisor

The plant’s independent technical advisor is a consultant or a senior internal engineer who represents the plant’s interests across the engagement. The advisor has no commercial incentive tied to scope expansion and no downstream revenue at stake in change orders. The advisor authors or reviews the scope, issues the RFP, evaluates responses, disciplines the contract, witnesses FAT and SAT, verifies the handoff, and names the escalation triggers when the project drifts. On a well-run engagement, the advisor is invisible most of the time and decisive at the moments that matter.

The integrator is a different role. The integrator is accountable for delivery of the scope in the contract. The integrator is not accountable for whether that scope was the right scope, whether the contract was the right contract, or whether the capital plan was the right plan. Those are the plant’s questions. They are also the questions that determine whether a project succeeds or ends up in the opening vignette. Conflating the two roles is the most common structural error on the plant side, and it is structural rather than conceptual because plants without a technical advisor have no choice but to lean on the integrator for guidance. The integrator gives the guidance honestly and competently; the integrator also gives it from a position where scope expansion is good for revenue.

Three commercial forms of the advisor role exist in practice:

• Senior internal engineer. A plant with a director of controls and a senior automation engineer sometimes has the internal capacity to run the advisor role, at least on routine projects. The tradeoff is that the internal role is often overloaded with sustainment work and cannot carry the oversight of a major capital project without neglecting the rest of the plant.
• Independent consultant. An individual or a small firm engaged on a retainer or a project basis to act as the plant’s advisor. Good for well-scoped projects where the retainer cost is a small fraction of the capital at stake.
• Technical Lead as a Service (TLaaS). A consultancy retained for the duration of the project, embedded with the plant’s internal team, carrying the advisor role through selection, RFP, execution, and handoff. Joltek’s owner’s engineer service is designed for this.

The CSIA Best Practices and Benchmarks Manual names 10 management areas that an integrator is audited against: general management; human resources management; marketing, business development, sales and opportunity management; financial management; project management; the system development life cycle; supporting activities (which include configuration management); quality management; service and support; and information systems management and cybersecurity. The advisor’s counterpart competencies mirror this list. The advisor evaluates whether the integrator’s management maturity matches the complexity of the project. A highly mature integrator on a simple project is overhead. A thinly managed integrator on a complex project is a failure waiting to happen.

One practical rule follows from the role distinction: the advisor is hired before the integrator, not after. An advisor hired after the integrator is in place can still add value, but the advisor is now renegotiating a relationship rather than shaping it. The advisor hired first writes the scope the integrator responds to, which is the most leverage the plant ever has in the engagement.

Integrator Selection and Qualification

Selection and qualification is the first stage of the arc. The goal is a short list of four to six firms, each of which could plausibly execute the project. The inputs to the short list are domain fit, platform fit, geography, and size.

Domain fit. A food and beverage plant needs an integrator who has delivered in food and beverage, because the regulatory framework (FSMA, SQF, BRC), the sanitation design considerations, and the changeover patterns are specific. A discrete manufacturer needs a different set of references. A pharmaceutical operation needs firms who know 21 CFR Part 11 and validation. An integrator who has never worked in the domain can learn, but learning on your project is not what the project budget is for. Joltek’s guide to what changes in automation from one industry to the next sets out those differences for 39 industries.

Platform fit. Rockwell integrators differ from Siemens integrators differ from Inductive Automation Ignition integrators. A firm whose 80% revenue is Rockwell is usually not the right partner for a Siemens TIA Portal project, even if the firm says it can do both. Ask for the revenue split across platforms. Ask how many active engineers the firm has certified on the specific platform.

Geography. A firm whose nearest office is 800 miles away will charge for travel, respond slowly to site calls during commissioning, and struggle to supply the kind of quick-turn engineering that commissioning routinely requires. Remote execution of design work is fine; remote execution of site work is not.

Size. An integrator whose annual revenue is $50,000,000 will treat a $1,200,000 project as a nuisance and assign junior staff. An integrator whose annual revenue is $4,000,000 cannot carry the resource risk of a $3,000,000 project without overloading its bench. Match the size of the firm to the size of the project, roughly in the 5% to 20% range of annual revenue.

CSIA certification is a filter worth applying. CSIA certification is a third-party audit against 76 criteria covering management practices, not technical depth. A CSIA certified integrator is likely to run disciplined project management, invoice cleanly, document the system development lifecycle, and carry insurance. It does not guarantee the senior engineer the firm assigns to your project is any good, because certification audits the firm and not the individual. Treat certification as a meaningful signal paired with independent review, not as a substitute for it.

Reference checks. Ask every candidate for three references on similar scope. Call all of them. The questions that matter are not “were you happy” (always yes) but:

• What changed during the project from what was originally scoped?
• What went over budget and why?
• Who was the project manager and did she last the full engagement?
• What do you wish you had asked before signing?

The last question generates the most honest answers because it invites the reference to share her own regret.

Staff continuity. The integrator’s proposal will name a project manager, a lead engineer, and a commissioning engineer. Get it in writing that those specific people will execute the project. Substitutions mid-project are the most common early warning sign of a struggling engagement, and they happen most often when the named staff were assigned at proposal time but never formally committed.

Insurance and financial health. Require current certificates of insurance at the levels specified by the plant’s risk management function. Ask for audited financial statements or, at minimum, a banker’s reference. For projects above $1,000,000, require performance and payment bonds. A firm that resists bonding is usually a firm whose bonding capacity is already used up or whose financial position the plant should investigate further.

The RFP and the Red Flags That Appear in Responses

An RFP is not a purchase order. Its job is to extract enough specificity from each candidate that a reasonable scope of work can be written before a contract is signed. Plants that skip the RFP and issue a purchase order against a salesperson’s slide deck are not buying an outcome. They are buying a relationship and hoping it produces an outcome.

The required sections of a disciplined RFP are:

• Executive summary and project goals, stated in business terms
• Current-state description with reference documents (P&IDs, network diagrams, existing controls architecture, prior engineering packages)
• Functional requirements: what the system does
• Technical requirements: platform, I/O counts, network architecture, cybersecurity posture, safety integrity level where applicable
• Deliverables and acceptance criteria
• Schedule and milestones
• Commercial structure (fixed price, time and materials, or hybrid, and how each component is priced)
• Assumptions and exclusions
• Evaluation criteria and selection process

Evaluation runs across four tracks: functional (does the proposed solution do what the plant needs), technical (is the architecture sound), commercial (is the price justified and the structure fair), and delivery risk (does the firm have the capacity, staff, and track record to execute). Gartner’s toolkit commentary on RFP evaluation established the four-track structure for IT integration engagements, and it translates directly to industrial automation.

When responses come back, seven specific patterns predict trouble. Each one on its own is a caution. Two or more in combination is a disqualification.

1. The assumptions section is short or absent. A disciplined integrator writes more assumptions than the plant expects. A thin assumptions section is not evidence of a simple project; it is evidence that the integrator plans to convert every gap into a change order during execution.
2. The proposal restates the RFP back as the scope of work. This is a sign that the integrator did not read the RFP carefully, or read it and declined to think about it. Either way, the firm will not catch the gaps the plant missed.
3. The schedule is presented as a single bar with no milestones. Milestones are the plant’s leverage during execution; their absence is deliberate. A schedule without milestones cannot be enforced.
4. The team section names titles, not people. “Senior engineer to be assigned” is a substitution risk disguised as a staffing plan. The people who win the work should be the people who do the work.
5. The commercial section is time-and-materials with no cap. Time and materials is legitimate for well-defined investigation work with a bounded budget. It is not a legitimate primary commercial structure for a modernization project. An uncapped T&M contract shifts all cost risk to the plant.
6. The change-order process is vague or one-sided. A disciplined integrator states a change-order mechanism that gives the plant a right to approve or reject before work is performed. A vague process means the integrator will perform the work and bill for it, and the plant will find out at invoice time.
7. References are all from the last six months. A firm whose only references are new engagements has no evidence it can finish a project cleanly. The strongest references are projects completed 12 to 24 months ago where the plant has lived with the delivered system long enough to judge it.

A proposal that clears all seven red flags is not automatically the right choice, but a proposal that trips two or more of them is rarely the right choice even when the price looks competitive.

Writing a Clean Scope of Work

The scope of work is the single most high-leverage document in the entire engagement. A clean scope produces a project that delivers what the plant expected. A dirty scope produces change orders, schedule slips, disputes at commissioning, and, occasionally, the opening vignette.

A clean scope of work has four sections of equal weight.

Objectives are stated at the business level. “Reduce changeover time on Line 3 from 45 minutes to 20 minutes.” Not “install new HMI.” The objective is what the plant is buying. The deliverables are the mechanism. Scopes that skip objectives force every downstream question through the deliverable list, which means the plant ends up accepting a system that technically meets the deliverables while missing the business outcome.

Deliverables are specific. “Replace PLC-5 at Line 3 with CompactLogix 5380, migrate logic, validate changeover sequence against signed-off functional specification.” Not “upgrade controls.” Every deliverable names the system, the platform, and the proof of completion. A deliverable that cannot be checked off against an artifact is not a deliverable; it is a hope.

Exclusions are the difference between a mature scope and an immature one. Exclusions name the items the plant might assume are included and the integrator might not have priced. Common exclusions that belong in every industrial scope:

• Field device replacement
• Network cabling and infrastructure
• Cybersecurity remediation on adjacent systems
• Operator training beyond a named number of hours
• Documentation updates on adjacent systems
• Validation support for regulated production
• Spare parts
• Subcontractor management for items outside the integrator’s direct capability

If an item is not named as included or excluded, it will be argued later. The argument always favors the party with the better paper trail, which is usually the integrator.

Acceptance criteria are measurable. “System passes FAT per signed FAT protocol. SAT passes with fewer than five Category-1 defects. Changeover time is measured at 20 minutes or less across three consecutive changeovers under production conditions.” Acceptance criteria that do not name a measurable threshold are aspirational. Aspirational acceptance criteria produce disputes at commissioning because neither side can prove the criterion was met.

For projects above $1,000,000, the scope should be modular. Modular scoping means the project is broken into work packages that each have independent acceptance. A module that passes acceptance is closed. A module that slips does not hold the rest of the project hostage. The ISA-88 series is a useful source of module boundaries: in batch, its equipment and procedural models; in packaging, ISA-TR88.00.02 (Machine and Unit States), which gives every machine module a common state model to specify and accept against.

The writing of the scope itself is a discipline. The best scopes are written by the plant or by an independent advisor before the integrator is selected. A scope written by the integrator who will execute it has a systematic bias toward the work the integrator is good at and away from the work that is harder to price. A plant that does not have internal capacity to write the scope should engage a modernization strategy the plant owns before hiring the integrator, not as a deliverable of the integrator engagement itself. The section-by-section version of this stage, with a responsibility matrix and acceptance-criteria language, is in our guide to the systems integrator scope of work, and the scope of work template (PDF) gives the thirteen sections as a document to fill in.

Scope Drift, Change Orders, and the Contract

Scope drift and scope change are not the same. Scope change is a formal modification to the contract with cost and schedule impact agreed on both sides. Scope drift is the slow accumulation of informal additions that never pass through a change-order process. Drift is dangerous because nobody authorized it. At commissioning, the plant discovers it paid for extras it never approved and is owed credit for scope that quietly disappeared.

Change orders are legitimate when:

• The plant directs a change
• The plant’s reference documents turn out to be wrong
• The plant’s existing systems turn out to be different than documented
• An assumption in the integrator’s proposal was wrong and the integrator flags it promptly when discovered

Change orders become abusive when:

• The integrator consistently finds the same class of gap on every project, which is evidence of systematically optimistic estimating rather than unpredictable surprise
• The change orders are presented late rather than at the moment of discovery, a pattern of withheld leverage the plant only sees at invoice time
• The change-order process is one-sided, with the integrator deciding what counts as a change
• Change-order volume crosses 15% to 20% of original contract value without a major scope direction from the plant

The opening vignette’s $420,000 change-order log against an $1,800,000 contract represents a 23% change-order rate without a corresponding major scope direction. That rate is not a scope change; it is an estimating failure or a scope-management failure, or both.

The contract mechanisms that prevent abuse are:

• A formal change control board (CCB) that meets on a defined cadence (weekly or biweekly during active execution)
• A right to reject or re-scope a proposed change before work is performed
• A cap on any time-and-materials components of the contract
• Liquidated damages tied to schedule milestones for projects where schedule is material to the business case
• A retention or holdback against the final payment, commonly 10% to 15%, released after SAT acceptance and defect closure

PMI’s PMBOK guide names integrated change control as the standard mechanism. Industrial projects should name a change control board in the contract and require that every change flow through it. The CCB’s composition is typically the plant’s project manager, the integrator’s project manager, the plant’s independent advisor if one is engaged, and a plant finance representative with authority to approve cost changes.

Dollar discipline matters. A change order below a named threshold (for example, $10,000) can be approved by the plant’s project manager without convening the full CCB. Above that threshold, the CCB decides. The threshold belongs in the contract, negotiated at signing rather than invented later.

The contract is also where cybersecurity, intellectual property, source code ownership, warranty terms, and dispute resolution are named. The most common omission across poorly contracted integrator engagements is the absence of a source-code ownership clause in favor of the plant. Without that clause, every future modification to the delivered system requires re-engaging the integrator.

Execution, Progress Oversight, FAT, and SAT

The execution phase is where most of the project’s dollars are spent and most of its risks are realized. The disciplines that prevent surprises at commissioning are progress reviews, gate reviews, FAT, and SAT. None of them are new inventions. All four are consistently under-run on struggling projects.

Progress reviews are not status meetings. A status meeting reports what happened since the last meeting. A progress review tests whether the project is still on track against the scope, schedule, and risk register. Progress reviews happen every two weeks at minimum on active execution, and more often near gate reviews. The right outcome of a progress review is not a feel-good report; it is an explicit statement of what changed in the plan since the previous review and what the plant and the integrator are doing about it.

Gate reviews are the formal checkpoints that release the next phase of work and the next payment milestone. A gate review has explicit entrance criteria (what is complete), evidence (what the integrator presents to prove completion), and exit criteria (what the plant signs to release the next phase). Missed gate criteria do not produce a gate pass because the schedule is pressing. A gate pass on incomplete criteria is the single most reliable predictor of a commissioning problem. The schedule pressure that led to the premature gate pass is always dwarfed by the commissioning delay it causes.

The FAT (factory acceptance test) happens at the integrator’s facility before shipment. The plant attends. The FAT protocol is signed by both sides before execution. The plant’s lead engineer or independent advisor verifies that each test is run as written, and Category-1 defects block shipment until they are resolved. A well-run FAT catches 80% of the defects that would otherwise surface at the plant during SAT, which is the phase where defect resolution is most expensive in time and dollars. IEC 62381 is the international reference for structuring both tests, and our factory acceptance test guide walks the FAT day by day, from entry criteria to defect classes and sign-off.

The SAT (site acceptance test) happens at the plant after installation. The SAT protocol is owned by the plant. Commissioning is not complete until SAT passes. When the plant does not have the hands to run SAT and start-up itself, commissioning support is the role to buy separately from the build. The single most common cause of post-commissioning disputes is go-live under schedule pressure with an unsigned or partially signed SAT protocol. Once production is running on the new system, the integrator’s leverage to close residual defects drops. The plant’s leverage to enforce acceptance drops faster.

The risk register is owned by the plant or the advisor, not the integrator. An integrator-owned risk register tracks the risks the integrator wants the plant to accept. The plant’s register tracks the risks the plant is actually carrying: platform risk, staff continuity risk, change-order trend risk, schedule risk, and integration risk with adjacent systems. The register is reviewed at every progress review and updated in real time, not at month-end.

Execution is the stage where oversight discipline matters most. Without disciplined oversight, execution becomes a long period of quiet assumption that the project is on track, punctuated by a loud discovery at commissioning that it is not. By the time a project is three months behind schedule and the change-order log is at $420,000, the gate reviews have already been skipped or attended as ceremony rather than run as gates. The cost to recover from that position is always higher than the cost of the disciplined progress reviews that would have prevented it.

Handoff, Sustainment, and Avoiding Integrator Dependency

A handoff that delivers a working system is not a handoff. A handoff delivers a working system plus the documentation, source control access, license assignments, and training the plant needs to operate and modify the system without calling the integrator. A handoff that stops short of any of those creates a dependency the plant discovers 12 months later, when a routine modification suddenly requires a purchase order.

The required handoff deliverables are:

• As-built drawings and P&IDs reflecting the installed system, not the design intent
• PLC and HMI source code with version history, in the form the plant can read and edit
• All license keys and transfer documentation, with licenses issued in the plant’s name
• Network and cybersecurity configuration documentation, including passwords transferred through a secure channel and then rotated by the plant
• Operator and maintenance training records, signed by each trained individual
• Spare parts list and recommended minimum stock, including part numbers and suppliers
• Support and warranty terms in writing, with named response SLAs for defect closure
• A defect log with closure status, including known open items and the agreed disposition for each

Source code ownership is named in the contract, not discovered at handoff. The contract specifies that the plant owns the source code for custom logic developed under the engagement. Without that clause, the plant discovers at sustainment time that a future modification requires re-engaging the original integrator because the integrator holds the only editable copy of the logic.

License assignments follow the same rule. Licenses are purchased in the plant’s name and registered to the plant’s accounts. License transfers after the fact often require fees, vendor approval, and elapsed time the plant does not have when a failure occurs at 2 a.m. on a production night.

The sustainment transition is a 30 to 90 day period during which the integrator is available on a defined response SLA, training is completed, and the plant’s team runs the system with integrator support on standby. After the transition, the plant operates the system without default integrator involvement unless a separate support contract is in place. The transition is negotiated at contract signing, not at handoff. A transition clause added at handoff is a renegotiation the plant rarely wins, because the integrator knows the plant has already accepted the system and the leverage has shifted.

The choice of long-term sustainment model (integrator retainer, internal team capability, or third-party support contract) is made during the scope stage, not at handoff. Deferring the choice is equivalent to choosing the integrator retainer by default, because the integrator is the only party with the knowledge to sustain the system on day one after handoff.

The common failure mode is not malicious. The integrator completes the project, the plant accepts delivery, and 12 months later the plant’s team cannot modify an HMI screen without paying the integrator $180 per hour because the source code was never delivered and the license is registered to the integrator’s account. This is not an integrator failure. It is a handoff-scope failure that the plant’s advisor would have prevented at contract signing. A reader finishing this section and recognizing her own recent handoff should count the deliverables above against what she received. Every missing item is a future dependency.

When to Escalate: Project Recovery Triggers

Not every project that drifts requires formal recovery. Most projects absorb a small amount of slip, a handful of change orders, and an occasional staff substitution without crossing into a different regime. Recovery is what happens when the trajectory of the project no longer closes on a credible completion plan.

Five triggers name the crossover.

Schedule trigger. The project has slipped more than 20% of remaining duration and the integrator’s proposed recovery plan does not name specific causes and specific countermeasures. Instead, the plan offers more hours and more staff. Adding resources to a project whose underlying process is broken accelerates the burn rate without improving the outcome.

Financial trigger. Change orders have crossed 15% to 20% of the original contract value and the trend is still up. The crossover point varies by contract structure, but a project with a disciplined change-order process rarely reaches 20% without a major scope direction from the plant. A 20% change-order run rate with no scope direction is evidence of a scope, estimating, or management problem that will continue unless the underlying cause is named and corrected.

Staffing trigger. The named project manager or lead engineer has been substituted more than once, or the named lead has been moved to an “advisory” role while a junior engineer runs the work. Substitution once is a normal event. Substitution twice on the same named role, or substitution plus silent reassignment, means the integrator has lost control of the staffing plan for the engagement.

Quality trigger. The FAT has more than 20% Category-1 or Category-2 defects, or the SAT is blocked by defect categories the integrator cannot close on a committed schedule. A FAT with a high Category-1 defect rate is not a project that is almost ready; it is a project whose testing maturity is not matching its build maturity. The integrator’s commitment to close the defects on a stated schedule is the pivot: a firm schedule with named resources is recoverable; a vague “we will work on it” is not.

Relationship trigger. The plant’s project team stops believing the integrator’s status reports, or the integrator’s team stops taking the plant’s gate criteria seriously. This trigger is qualitative, and it is nearly always accurate. When both sides privately believe the engagement is broken, the engagement is broken. The trigger is also the last of the five to fire in most projects, which is why recovery usually comes late.

When any one trigger fires, the plant convenes a formal review. When two or more fire, the project has crossed into recovery. Recovery actions follow a consistent sequence:

• Engage an independent advisor if one is not already involved
• Freeze the scope until the rebaseline is complete
• Rebaseline schedule and cost with the plant’s independent estimate, not the integrator’s
• Agree on a realistic path to completion with explicit exit criteria
• Commit to the exit criteria in writing, with either the original integrator or a replacement

Replacing an integrator mid-project is sometimes the right answer. It is also often the most expensive answer. The independent advisor helps the plant decide which. The opening vignette, with $1,800,000 at stake, $420,000 of change orders logged, and a resigned internal engineer, is the archetype of a project that crossed multiple triggers before anyone in authority named the recovery decision. The cost of naming the decision three months earlier is always smaller than the cost of naming it three months later.

Consultant, Integrator, Vendor, Internal: Who Does What

Four actors can be involved in an industrial automation project. Treating them as interchangeable is the most common structural error in plant-side project management, and it is the error that quietly produces most of the outcomes the rest of this post has been discussing.

The four actors compared on the same dimensions:

	Consultant	Systems integrator	Vendor	Internal team
Role	Represents the plant	Executes the scope	Supplies the product (Rockwell, Siemens, Emerson, Inductive Automation, AVEVA and others)	Owns the plant long-term (controls engineers, automation engineers, maintenance technicians)
Accountable for	The plant’s interest across the engagement	Delivery of the contract	The product’s function	Sustainment
Incentive on scope	None tied to scope expansion	Toward a bigger scope	Toward its own product	Lives with the result after handoff
Good for	Scope authorship, RFP issue and evaluation, progress oversight, recovery, technical lead roles	Design, build and commissioning within a well-written scope	Product-level expertise, warranty support, deep questions on one platform	Institutional knowledge, day-to-day operations, small projects, continuous improvement
Wrong for	Executing the build: a consultant is not a production shop and carries no engineering and field crew for a capital project	Defining what the scope should be	System-level decisions that cross products	Carrying peak capital-project load without help: staffed for steady state, not a 12-month, $2,000,000 engagement

The consultant is independent, which is the whole point of the role. The integrator is accountable for the contract it signed, and its incentive is for that contract to be bigger. The vendor’s incentive runs toward its own product, which is why it should not arbitrate between products. The internal team is the only one of the four that lives with the system after everyone else leaves.

The decision rules that follow from the role distinctions:

• Scope authorship and oversight belong to the consultant or an internal senior engineer with capacity. Not the integrator. Not the vendor.
• Build execution belongs to the integrator. Small, well-scoped work can also belong to the internal team when capacity allows.
• Product expertise belongs to the vendor, reached either through the integrator or directly.
• Sustainment belongs to the internal team as the primary owner, with the integrator available on a defined support contract and the vendor available for product-level support.

The most common conflation errors:

• Treating the integrator as the plant’s advisor. Produces scope expansion and silent change-order accumulation.
• Treating the vendor as the integrator. Produces platform lock-in and under-capacity for cross-product system integration.
• Treating the internal team as a substitute for a consultant on a project that exceeds internal capacity. Produces overloaded staff, missed progress reviews, and burnout-driven resignations like the one in the opening vignette.

The systems integrator playbook begins with naming the four roles and assigning each stage of the arc to the right role. A plant that does this consistently rarely repeats the opening vignette. A plant that skips the assignment finds itself asking the integrator to act as advisor, the vendor to act as integrator, or the internal team to act as all three, and then wondering why the project did not close.

Frequently Asked Questions About the Systems Integrator Playbook

What is a systems integrator playbook?

A systems integrator playbook is the set of practices, documents, and oversight disciplines a plant uses to buy, scope, contract, oversee, commission, and hand off work performed by an outside systems integrator. It covers six stages: selection, RFP and scope of work, contract and commercial terms, execution and progress oversight, commissioning (FAT and SAT), and handoff. The playbook is owned by the plant, not by the integrator.

What should be in a systems integrator scope of work?

A clean scope of work names four components: business-level objectives, deliverables that name the system and the proof of completion, exclusions that list what the plant might assume is included, and measurable acceptance criteria. Above $1,000,000, the scope should be modular, so a module that clears acceptance is not held hostage when an adjacent module slips. For packaging scopes, ISA-TR88.00.02 gives each module a common state model to specify against.

What is the difference between a consultant and a systems integrator?

A consultant represents the plant. A consultant is independent, has no commercial incentive tied to scope expansion, and is accountable for the plant’s interest across the engagement. A systems integrator executes the scope in the contract and is accountable for delivery of that scope. The incentives differ on scope expansion, which is why the roles are distinct and why most plants benefit from engaging both.

What are red flags in a systems integrator proposal?

Thin or absent assumptions section, a proposal that restates the RFP as the scope of work, a schedule without milestones, a team section that names titles rather than specific people, time-and-materials pricing without a cap as the primary commercial structure, a vague or one-sided change-order process, and references only from engagements in the last six months. Each is a caution on its own; two or more in combination is a disqualification.

When should you escalate a systems integrator project to recovery?

Escalate when schedule slip exceeds 20% of remaining duration and the recovery plan offers only more hours and staff, when change orders pass 15% to 20% of contract value and are still rising, when named staff have been substituted more than once, when over 20% of FAT defects are Category-1 or Category-2, or when both sides privately believe the engagement is broken. One trigger warrants a formal review; two or more mean formal recovery.

The Integrator Is Not the Plant’s Advisor

The thesis of the systems integrator playbook is a single sentence. The integrator is not the plant’s advisor. Every stage of the arc, every red flag, every scope clause, every gate review, and every escalation trigger is an answer to the question of what the plant does with or without a formal advisor because the integrator will not. The integrator is accountable for delivery of the contract, and the integrator delivers the contract competently and honestly. The plant is accountable for whether the contract was the right contract, whether the scope was the right scope, and whether the capital plan was the right plan.

The VP of Engineering in the opening vignette did not lose the project because the integrator was incompetent. She lost it because the plant did not run the playbook. The $1,800,000 contract, the $420,000 change-order log, the resigned controls engineer, and the request for another $350,000 are the symptoms of a project that never had independent oversight, never had a modular scope, never had disciplined gate reviews, and never named the role that belongs to a consultant or to a senior internal engineer acting with that mandate.

For plants that want the scope authored and the engagement run on their behalf, Joltek acts as the plant’s owner’s engineer on integrator projects, and as the technical lead when an engagement needs recovery. When we are hired as the integrator rather than the advisor, our systems integration work is held to the same scope, gate and handoff discipline described above. For plants that want to build the discipline internally, the six stages above are the starting point. Either way, the playbook belongs to the plant.