Your operations team has a problem. A real one, a manual process that costs time, introduces errors, or creates blind spots in your production data. They find a partner, scope a custom solution, and come back with something that actually fits how your operation works.
Then IT reviews it. And the project stalls.
Sound familiar? This scenario plays out constantly in industrial and hybrid organizations and it rarely comes down to the quality of the solution. It comes down to a gap that most organizations haven't properly addressed: the structural tension between OT and IT.
Two teams, two completely different definitions of ‘working’
OT lives in the operational reality. Uptime, throughput, responsiveness. When a process breaks down or creates risk, they need it fixed and they need a solution that actually reflects how their environment works, not a generic tool that was designed for someone else's operation. Custom software is often the only real answer, because their processes are specific, their systems are often legacy, and off-the-shelf platforms frequently don't survive contact with the floor.
IT lives in a different reality. Security, compliance, maintainability, governance. They've inherited the technical debt from every "quick fix" that was deployed without proper review. They know what happens when custom code sits in production for ten years and the person who wrote it has left the company. Their caution isn’t obstruction, it's institutional memory.
The problem is that both teams are responding rationally to legitimate pressures. But when those pressures collide on a specific project, OT experiences IT as a blocker, and IT experiences OT as a risk they have to manage.
Where it breaks down
The friction points are predictable. Understanding them is the first step to getting past them.
Ownership after go-live. Custom software needs to be maintained. IT will ask: who owns this when the vendor relationship ends? Who applies security patches? Who fixes it when something upstream changes? These are fair questions but if they're raised for the first time during the review process, they feel like obstacles rather than conditions.
Security review cycles vs. operational urgency. OT's problem is live. The cost of waiting, in errors, inefficiency, or risk is real and ongoing. IT's review process has its own timeline, shaped by compliance requirements and change management policy. Neither timeline is arbitrary, but they rarely align without deliberate coordination.
Code standards and handover. IT is responsible for the integrity of the systems landscape. When custom software arrives from an outside party, they need to understand it, trust it, and eventually support it. If documentation, architecture, and code quality don't meet their standards, the review doesn't just slow down, it can stop entirely.
Control and visibility. IT wants to know what's running in their environment. OT wants to move fast and solve the problem. When a custom solution is scoped and built without IT's early involvement, it can arrive fully formed at the review stage, which is the worst possible moment to raise fundamental concerns.
The real cost of this gap
Delayed projects are the visible cost. But the deeper cost is what happens to the relationship between OT and IT over time.
OT learns to work around IT, scoping projects smaller, framing them differently, or finding ways to deploy without triggering a full review. IT becomes more defensive, because they keep discovering things in production that they weren't consulted on. Both teams dig in. And the organization loses the ability to move on digital and operational improvements at the pace the business needs.
For C-level leadership, this is the real problem. Not a single stalled project but a dynamic that systematically slows down your ability to improve operations.
What needs to change
The answer isn't to route around IT or to give IT veto power over every operational improvement. It's to build a model where both teams are involved from the start and where their concerns are addressed as part of the solution, not after it.
That means bringing IT into the problem definition phase, not the approval phase. When IT understands why OT needs a solution, and what the operational cost of inaction is, the conversation changes. They stop being a gatekeeper and start being a co-owner of the outcome.
It also means that custom software partners need to treat IT as a stakeholder, not just OT. Handover documentation, security architecture, maintenance models, these aren't afterthoughts. They're part of what makes a solution deployable in a real organization.
And it means leadership needs to make the decision framework clear. What level of IT involvement is required, at what stage, for what type of solution? Without that clarity, every project negotiates the rules from scratch, which is where the friction lives.
The deeper structural problem
IT is usually a cost centre, which means it's chronically under-resourced relative to the demands placed on it. Business units that want fast innovation rarely advocate for the IT budget increases that would actually make that possible.
There's also a knowledge gap that cuts both ways: business teams underestimate the complexity of what they're asking for, and IT teams often fail to communicate why something takes time, which breeds mutual frustration and distrust.
What actually helps
Organisations that navigate this well tend to: establish a lightweight "fast lane" approval process for lower-risk tools, embed IT or security people within business teams (DevSecOps, product squads), shift IT's mandate explicitly toward enablement, and treat shadow IT as a signal of unmet need rather than just a compliance problem.
The tension is real and probably unavoidable to some degree, but how it's managed is very much a leadership and culture choice.
The bottom line
Custom software exists because standard platforms don't solve every problem. OT teams are right to seek solutions that fit their operational reality. And IT teams are right to ask hard questions about security, ownership, and long-term maintainability.
The gap between them isn't a technology problem. It's a governance and collaboration problem and it needs to be solved at the leadership level, before the next project hits the review stage.
Because the real waste isn't a blocked project. It's an organization that keeps building the capability to improve and then blocks itself from doing it.
