The Automation Gap
What Gets Quoted, What Gets Built, and What Gets Validated
After years of working on automation projects in regulated and validation-heavy environments, a few things have become clear to me: the system that gets quoted, the system that gets built, and the system that gets validated are rarely the same thing.
This is a look at why that gap exists, and what it actually takes to close it.
Part 1: The Communication Breakdown
Most automation projects don't fail during commissioning. They fail before they ever start.
Not because of bad engineers. Not because of bad intentions. Because of incomplete definition, and a breakdown in communicating not just what needs to happen, but why and how.
I saw this play out on a regulated project where the client brought in a specialized validation documentation contractor alongside the integrator. Smart idea in theory — divide the work, bring in expertise. But the integrator didn't fully understand the intent and value of the validation deliverables, and the validation team didn't understand the systems they were documenting. Both groups ended up having to learn each other's world while simultaneously trying to finish their own work.
The schedule slipped. The budget was blown. The client was unhappy. The plan looked good on paper, but the communication didn't hold it together.
That pattern — where the what is defined but the why and how aren't — shows up constantly in validation-heavy environments: a URS that defines outcomes but not behavior, a sequence of operation left at a high level or missing entirely, no shared understanding between process, controls, and validation teams, and the ever-present "we'll finalize it during FAT" (which rarely ends well).
At that point, you're not executing a project. You're discovering requirements in real time. And the downstream effects are predictable: design documents don't align and FS/DS gaps appear, test protocols become hard to write and harder to defend, IQ/OQ slows down due to ambiguity, and change control starts earlier than anyone planned.
Good projects start with clarity: defined system states and transitions, agreed-upon sequence of operation before programming starts, and aligned expectations across engineering and validation before anything gets built.
The details that aren't locked in early don't go away. They just show up later, when changes are more expensive and more controlled.
Part 2: The Hidden Cost Drivers
The line item that blows automation budgets is almost never the PLC. It's the things that don't show up cleanly in a proposal or a URS.
Here's something I've come to believe strongly: validation should be part of every project, even outside of GMP environments. But validation requires something to validate against — a document that states how the system is supposed to work. Most of the time, that document doesn't exist. And when an integrator suggests creating one just to have a baseline, it's often declined as a budget line item.
That's a mistake. It's cheap insurance against long, painful commissioning. Without it, the costs show up anyway, just later, when they're harder to control.
A few of the hidden drivers that consistently impact project cost:
Integration complexity. It's not just I/O count. It's system interaction — PLCs, HMIs, skids, upstream and downstream equipment, sometimes MES or historians. Each interface adds test cases, failure modes, and documentation overhead that rarely makes it into the original proposal.
Controls ambiguity. When sequence of operation isn't locked in the FS/DS, logic decisions get made during programming. That creates rework and validation risk. A single unresolved permissive condition can ripple into design document updates, revised test scripts, and partial re-execution of OQ.
Mid-project changes under change control. A small logic change isn't just an engineering hour. In a regulated environment, it can mean updated documentation, revised protocols, and partial re-testing. The cost isn't just time, it's compliance overhead.
Data integrity and traceability requirements. Audit trails, alarm history, user actions, recipe parameters — these aren't add-ons. They need to be designed in from the start. Retrofitting them is expensive and sometimes structurally difficult.
The pattern is consistent: the less defined the system is upfront, the more expensive, and harder to validate, it becomes.
Part 3: Quoted vs. Validated
There's almost always a gap between the system that gets quoted and the system that gets validated. And it's not because anyone is cutting corners.
It's structural. Without front-end engineering, a quote can only be based on major hardware and a high-level overview of how the system works. That's not a vendor failure; it's a timing problem. The details that define a validated system don't exist yet when the proposal is written.
As a result, proposals typically cover major hardware, high-level functionality, and basic scope boundaries. But what actually gets tested and approved includes state transitions and edge conditions, alarm behavior and acknowledgement logic, operator actions and access levels, and data handling, audit trails, and event logging.
These details don't stay theoretical. They surface during FAT, SAT, and especially OQ. And when they do, one of two things happens: they get formally incorporated, which means updates to FS/DS and test protocols, or they get informally handled, which creates long-term risk.
It's also partly an ownership problem. Engineering scopes to functionality. Validation scopes to defensibility. Those aren't always the same conversation, and they don't always happen at the same time.
The best projects reduce this gap early by treating controls logic as a defined design deliverable, aligning engineering and validation expectations before build, and building traceability from requirements through design through testing. Because once you're executing protocols, it's the most expensive time to realize something wasn't defined.
Part 4: Two Different Languages
Here's something worth saying plainly: integrators are not GMP validation documentation experts. And GMP validation documentation experts are not typically integrators.
They speak different languages. They have different objectives. They think differently. And when both are engaged on the same project, that distinction matters enormously, because if no one accounts for it, the gap between them becomes a project risk.
Most automation project problems don't come from bad engineering. They come from partners who avoid the uncomfortable conversations early — about scope gaps, validation implications, documentation debt — because it's easier to start the project than to slow it down and get aligned.
Strong partners operate differently:
They force definition early, even when it slows the front end, because they know undefined scope doesn't disappear. It shows up later as design churn and protocol revisions.
They align engineering with validation. URS, FS/DS, and test protocols aren't separate tracks. Gaps between them get closed before build, not during execution.
They design with traceability in mind. Every major function ties back to a requirement, and every requirement has a clear path to verification.
They communicate in terms of risk and impact, not just progress — especially when a change affects validation scope or triggers re-testing.
They treat documentation as part of the deliverable, not something to reconstruct the week before IQ/OQ.
Weaker execution pushes ambiguity forward: design gets finalized during programming, documentation lags behind implementation, and validation becomes reactive. In regulated environments, that's where timelines slip, and where the relationship between integrator and client starts to erode.
The best projects happen when both sides understand what the other needs, and someone is making sure the two stay connected.
Part 5: What Proper Scoping Actually Delivers
Here's something clients won't tell you directly, but it's true: they don't care how clean your enclosures look. They don't care how accurate your drawings are, or how organized your program is. They care whether the system works as intended, and whether they can prove it.
That's what proper scoping actually delivers. Not just a functional system, but a predictable, testable, and defensible one. If you want a project to go smoothly and pass validation, it comes down to how well it's defined upfront — not just functionally, but behaviorally and traceably.
A few areas that make a measurable difference:
Define system states and transitions. This becomes the backbone of both the control logic and the test cases. If you can't describe the states clearly before programming starts, you can't write a meaningful OQ.
Write the sequence of operation as if your validation team will build OQ scripts from it. Because they will. Vague language at this stage creates ambiguity that compounds through every downstream document.
Identify interlocks, permissives, and fault responses explicitly, including what gets alarmed, logged, and requires operator acknowledgement. These aren't details to sort out during FAT.
Clarify user roles and access levels. Who can do what, and how it's recorded. In regulated environments, this feeds directly into data integrity requirements.
Ask what the audit needs to show, then design backward from that answer. Don't add data integrity as an afterthought. Build the trail from the start.
Map requirements to design to test cases before build. Traceability isn't a documentation exercise. It's a project management tool that tells you, in real time, what's covered and what isn't.
Every undefined detail has to go somewhere. It either gets resolved during scoping, or it surfaces during programming, FAT, or OQ, when resolving it costs significantly more.
Good projects aren't just functional. They're predictable, testable, and defensible. That's what it looks like when automation is done right.
Comments