How a Controls Project Gets Scoped | PLC & Machine Retrofits

Many retrofit projects go sideways before the first wire is touched.

The estimate looked reasonable. The timeline seemed achievable. Then the panel showed up at the plant, and the actual system didn't match the drawings, or there weren't any drawings at all. The scope that looked clean in the quote turned into something much larger in the field.

This isn't a rare situation. It's what happens when a project gets priced from a description instead of from a verified picture of what actually exists.

Scoping a controls project the right way takes time upfront. But that time is what separates a project that runs on schedule from one that blows past the budget somewhere around week three.

Here's how we approach it.

What Scoping Actually Is

Scoping isn't just writing down what the customer wants. It's building a reliable enough picture of the existing system that you can make real commitments about what it takes to change it.

That means walking the machine. It means looking at the panel, not just the drawings. It means understanding what documentation exists, what's been modified since it was built, and where the gaps are before any estimate goes out the door.

For a machine retrofit or PLC upgrade, scoping typically involves:

• A physical review of the existing panel and field wiring
• An I/O count — how many inputs and outputs the system actually has, versus what's in the drawings
• A review of any available documentation (schematics, PLC programs, HMI project files, BOM)
• Understanding the machine's operating modes, startup sequences, and fault conditions
• Identifying obsolete or end-of-life components that affect the scope
• Clarifying what success looks like — production rate, operator interface expectations, integration with surrounding equipment

This isn't busywork. Each of these items either changes the estimate or removes a risk that would have shown up later as a change order.

Why Documentation Is Never Taken at Face Value

The most common phrase in controls work is "the drawings should be accurate."

They rarely are — especially on equipment that's more than ten years old and has been modified in the field by maintenance crews who didn't update the schematics.

When we walk a panel, we’re looking for:

Added field devices that never made it onto the drawings. A sensor someone bolted on three years ago. A relay that was added to solve a signal problem. A junction box that routes wiring in a way the schematic doesn't reflect.

Changed I/O addressing. A spare input that got pressed into service. An output that now drives something different than what the label says. These are the things that don't show up until you're trying to test the program and something doesn't respond the way the documentation suggests it should.

Logic that's drifted from the program backup. If the only backup is from the last time someone saved it before a modification was made, the current running program might be different from what's on file. Running from a stale backup is one of the most common ways a retrofit startup turns into a debugging session.

Missing or incomplete schematics. On machines where the original builder is no longer involved, the electrical drawings are often incomplete, hand-marked, or missing entirely. Reverse engineering that baseline is part of the scope — not something to discover mid-project.

The goal of the scoping visit isn't to find problems. It's to build a realistic picture so the estimate reflects what the project actually requires.

The I/O Count and Why It Matters

For any project that involves replacing or reprogramming a PLC, the I/O count drives most of the hardware cost and a significant portion of the programming estimate.

I/O count means the number of physical inputs and outputs the system uses — every sensor, pushbutton, solenoid, motor starter, and signal connection that the controller monitors or drives.

Getting this right requires physically counting from the field side, not just from the existing I/O list. The existing list is a starting point. The panel tells the real story.

A few things that regularly change the count:

• Spare I/O that's now in use. The original system was designed with headroom. Over time, that headroom got used. The documentation often doesn't reflect it.
• Safety I/O. E-stop chains, light curtains, and safety relays need to be mapped explicitly. Skipping this during scoping is how safety architecture gets under-built.
• Communication-dependent devices. Devices that communicate over a network (DeviceNet, Profibus, EtherNet/IP) aren't always visible in a point-to-point I/O count. They need to be identified separately because they drive both hardware selection and programming scope.

A verified I/O count — done from the panel and field, not from a document — is one of the things that keeps an estimate from having a "we found 40 more points than expected" conversation halfway through the project.

What Determines Whether Discovery Is Its Own Phase

For straightforward work — a single-machine retrofit where the documentation is reasonably accurate and the scope is well-defined — scoping can be done in a single site visit. The customer gets an estimate based on what was found, and the project moves forward from there.

For more complex work — especially large systems with multiple machines, unclear documentation, or integration across several pieces of equipment — scoping becomes its own formal phase of the project. Discovery work gets scoped, priced, and completed before the retrofit estimate is written.

This isn't adding unnecessary process. It's the practical way to remove guesswork from the estimate.

A thorough discovery phase on a complex system will typically produce:

• An as-found I/O list and a verified schematic baseline
• Identification of obsolete components and their current availability
• A clear picture of what needs to be replaced versus what can stay
• A realistic assessment of what the system can support during the startup period
• A prioritized scope — what needs to happen first, what can be phased, and why

That output is worth more than a quote written from a description. It's the foundation that makes the actual project predictable.

What a Good Scope Produces

A scope done right isn't just a list of line items. It answers the questions that actually drive decision-making:

What's the minimum viable scope? Not every system needs to be fully replaced in one project. A good scope identifies what has to happen first — usually the obsolete hardware that can't be sourced anymore or the failed logic that's creating production risk — and separates that from work that can be phased.

What's the realistic startup window? A startup plan that doesn't account for the actual complexity of the machine is a plan that's going to slip. Understanding the machine's operating modes and edge cases during scoping is what makes a startup timeline credible.

What does the customer need to do before work starts? Successful projects require things from the customer too — production windows, machine access, clear contacts for operations and maintenance, and someone who can walk the engineer through how the machine actually runs. Scoping is when those expectations get established.

What are the risks, and which ones are in scope? Every project has unknowns. The goal isn't to eliminate them — it's to identify which ones are likely, estimate their impact, and be honest about them upfront rather than surfacing them as change orders later.

The Alternative

The alternative to a proper scope is a quote built on assumptions.

Some of those assumptions will be right. Some won't. And when they're not, the customer absorbs it — either through change orders, or through a project that was estimated low enough to win the work but doesn't have the budget to actually do it right.

That's not a vendor problem or a customer problem. It's a scoping problem.

The projects that run well are the ones where both sides had an accurate picture before work started. Not a perfect picture — there are always field surprises — but accurate enough that the surprises are manageable rather than budget-defining.

If you're evaluating a controls upgrade, a machine retrofit, or a PLC replacement and you're not sure whether the scope you've been given reflects what the project actually involves, it's worth getting a second look before committing. The time to find scope gaps is before work starts — not during startup.

Reach out if you want to talk through what a project like yours typically involves. We scope projects before committing to them, and we’re glad to give you an honest take on what to expect.