SCADA integration plans get built from the engineering. Connectors to build, tags to map, a warehouse to load. The estimate comes from that work, the plan gets approved against it, and then the project runs long for reasons that never appeared in the plan at all.
The constraint is almost never engineering. It is who controls access to each system, and whether they want to help.
The gateway is not yours
Here is the shape of the problem on a typical multi-vendor estate.
An asset runs a SCADA platform with a working publishing path, usually MQTT with a Sparkplug B payload, sometimes an OPC UA server you can subscribe to. The protocol is documented, the connector exists, the receiving end is straightforward. Technically this is a solved problem, and any competent data engineer can describe the whole path in a meeting.
The publishing has to be configured on the gateway. The gateway sits on the asset’s network, and it is administered by the automation firm that built and maintains that system. Not by you. Often not by anyone at your company, because the arrangement predates the acquisition that brought the asset into your portfolio.
So the work is eight to twenty-four hours of configuration on a machine already running the software, performed by a party with no contractual obligation to prioritize your data project, whose actual business is keeping the plant running and who reasonably regards your request as a distraction.
The engineering estimate was correct. It was also irrelevant.
Money does not buy what cooperation supplies
The instinct when a project stalls is to spend against it. Hire a second integrator. Pay for expedited work. Escalate commercially.
None of that works here, and it is worth understanding why, because the failure is not about price.
If the configuration must happen on a counterparty’s gateway, then any vendor you engage to do that work still needs the counterparty’s cooperation to get on the box. You have not routed around the constraint. You have added a party to it. The new vendor now needs an introduction, a scope agreement, network access, and a maintenance window, all granted by the same firm that was slow to begin with.
Cooperation is a precondition of spending, not an alternative to obtaining it.
The projects that move are the ones where somebody with a commercial relationship to the automation firm picks up the phone early, explains what is being asked and why it is small, and gets it into that firm’s schedule as a favor or as a line item. That conversation is worth more than any amount of architecture work, and it usually has to happen weeks before anyone writes a connector.
Two quotes for the same thing, ten times apart
A concrete symptom, because this one wastes real money.
Ask several parties to price “a connection” from one asset and the numbers can differ by an order of magnitude for what sounds like the same request. When we modeled this out, the two ends of the job priced roughly ten times apart.
They are not the same request. The low number prices the publisher: configuration work on a gateway that already runs the software and already holds the license. The high number prices the whole path, including the receiving infrastructure, a broker, a license for a component the asset does not yet own, and integration testing on both ends.
Neither is wrong. They answer different questions, and comparing them as though they were the same will either leave the work underfunded or convince you a vendor is gouging you.
Before you compare a single number, establish which side of the boundary each quote covers: the publishing end, the receiving end, or both. Then compare like for like. It is one question and it is worth asking before any vendor evaluation starts.
Sequence by access, not by architecture
The natural instinct when planning a multi-asset rollout is to sequence by architectural similarity. Do all the assets on the same platform first, because the connector is reusable. Batch the work by technology.
That is the wrong axis on a heterogeneous estate. Sequence by access confirmation instead.
Phase one should be the assets where you already have administrative control or a cooperative provider relationship, regardless of what platform they run. Those give you a working end-to-end pipeline, real data, and the credibility to fund the rest. Phase two is the assets where access is obtainable but needs a commercial conversation. Phase three is the assets where access is genuinely blocked, and the honest thing to do with those is to name them as blocked rather than schedule them optimistically.
That last category deserves its own treatment. An asset where the provider will not cooperate, or where the contract does not entitle you to the data, is not a later phase. It is a different problem, and it gets solved by legal and commercial work rather than by engineering. Putting it in the plan as “phase three” implies a technical path that does not exist.
This is a refinement of the crawl-walk-run sequencing we recommend generally. Prove the pattern on one asset first, yes. But choose that asset by whose cooperation you already have, not by which one is architecturally cleanest.
What “blocked” actually looks like
Blocked is rarely a refusal. Nobody says no.
It looks like a request that gets acknowledged and not scheduled. A quote that takes five weeks to arrive. A maintenance window that keeps moving because the plant has real work. An engineer who is genuinely willing and genuinely booked through the quarter. Every individual delay is reasonable, which is exactly why it does not escalate: there is never a moment where someone can point at bad faith.
The tell is that the request has no owner on the other side. If you cannot name the person at the automation firm who is accountable for delivering it, and the date they committed to, it is not in progress. It is pending, and pending has no end.
Treat it the way you would treat any external dependency. Named owner, committed date, a check-in cadence, and an agreed escalation path to whoever holds the commercial relationship. That sounds heavy for eight hours of configuration work. The weight is not for the work, it is for the queue the work sits in, and the queue is what turns a day of configuration into a quarter.
Map the providers, not just the platforms
Most estate inventories list the SCADA platform per asset. Almost none list who administers it.
Those are different columns, and the second one drives the schedule. One platform across six assets can mean six different service providers, six different relationships, and six different answers about access. Conversely, two different platforms administered by the same cooperative firm are effectively one conversation.
Build the inventory with all four columns from the start:
| Column | What goes in it | Why it matters |
|---|---|---|
| Platform | The software the asset runs and what publishing it supports | Determines the engineering, which is the easy part |
| Administrator | Who holds admin on the gateway, your relationship with them, whether anyone has spoken to them this year | Determines the schedule |
| Entitlement | Whether your contract, or the one you inherited with the asset, actually lets you extract the data | Occasionally the answer is no, and better to know now |
| Status | Confirmed, in progress, or blocked, with a date against it | A status, not a plan |
The entitlement column is the one people skip and the one that produces the worst surprises. It is not always yes, and finding out in month four is considerably more expensive than finding out in week one.
Built this way, the inventory gives you the real sequence in an afternoon. Built on platforms alone, it gives you a sequence that does not survive the first phone call.
What this changes about the plan
If access is the constraint, then the early work in a SCADA program is not architecture. It is discovery and relationship management, and it should be staffed and scheduled that way.
We have written about centralizing a fragmented upstream estate and about the cost of vendor sprawl. Both of those describe real technical work. Neither of them starts until somebody has confirmed you can actually reach the data, and that confirmation is a conversation, not a connector.
The plan that survives contact has an access column on every line, a date against each one, and a phase one chosen because that door is already open.
None of which is a reason for pessimism. Access problems have a property that engineering problems do not: they are frequently solved by one phone call from the right person, made early. The failure is almost never that somebody said no. It is that nobody asked until the connector was already written.