What Custom Software Development for Manufacturers Really Looks Like: Phases, Risks and Success Metrics

Only 29% of software projects are delivered on time, within budget and with the agreed functionality, according to the CHAOS Report by the Standish Group (2024). In industrial environments — where 2003-era PLCs, proprietary protocols and OT teams that prioritise plant availability above everything else coexist — the odds of failure are even higher. This article walks through the real phases of a custom software development project for manufacturers, the seven decision points where projects die, and the hidden costs that destroy ROI before the system ever reaches production.

Why More Industrial Software Projects Fail Than the Industry Admits

Technology is rarely the root cause of failure: industrial software projects die from people and process problems, not technical complexity.

The Standish Group (2024) data is unambiguous: across a sample of more than 50,000 projects, only 29% are considered successful. 52% are delivered late, over budget or with reduced functionality, and 19% are cancelled before completion.

What stands out is that technology failure ranks last among identified causes. A study by J.L. Partners (2024) with 481 software engineers found that projects with documented requirements before development began were 97% more likely to succeed than those without.

Here the first relevant tension emerges: the same J.L. Partners study found that projects with upfront specification were 50% more likely to succeed, which contradicts the Agile orthodoxy of “iterate first, define later”. The Standish Group, meanwhile, reports a 64% success rate for Agile projects versus 49% for Waterfall. The sources disagree, and in an OT environment where an unplanned patch can halt a production line, the tension between agility and upfront specification has physical consequences, not just methodological ones.

Sector data adds context: scope creep causes 52% of custom projects to exceed their deadlines; legacy system integration issues affect 55% of projects; and 45% of projects exceed their budget by 50% or more.

The most precise diagnosis of where the problem lives in industrial contexts comes from Globental (2026): “A factory with an ERP and a digitised plant still has the same gap: between what the administrative system records and what actually happens on the line, bridged by paper forms, spreadsheets and someone typing at the end of a shift. That gap is where custom industrial software lives. It doesn’t replace the ERP or the machine controller. It connects them.”

The Root Problem: Capturing Requirements When Process Engineering and IT Speak Different Languages

The biggest risk in the requirements phase is not missing features — it is that the process engineer, the IT manager and the plant manager describe the same problem with three incompatible vocabularies, and nobody notices until the system is half-built.

ISC2 (2024) describes this precisely: IT professionals are “unfamiliar with OT realities such as PLCs, safety systems, vendor maintenance models and downtime constraints”, while OT engineers have “limited exposure to identity risks, threat modelling or modern governance expectations”. This cultural gap is the most underestimated brake on capturing the real value of IT/OT convergence, which BCG (2024) estimates at approximately $60 billion globally.

How to Structure the Requirements Workshop So It Doesn’t Fail

What we have found to work in practice is separating the requirements-capture sessions before bringing everyone together:

Session 1 (OT/process only): The output is a process flow diagram with the required data points, their tolerances, alarm conditions and non-negotiable quality criteria. The language is P&ID, ladder logic and OEE — not APIs.

Session 2 (IT/systems only): The output is the data model, the API surface, security requirements and the integration architecture with existing systems. The language is endpoints, latency and user roles — not process pressures.

Joint session: Both outputs are presented and an explicit conflict register is built — with its resolution documented and signed by both parties. This register is the living document that prevents scope disputes six months later.

Note: this three-session format is engineering judgement based on IT/OT convergence practice; no primary source validates it specifically as a standard.

In an inspection project we built — Mapper, our cloud inspection platform — the critical moment was not the development itself, but reconciling the metrological accuracy requirements of the inspection engineer with the IT team’s preference for an API-first architecture that prioritised ingestion speed over timestamp precision. Resolving that on paper, before writing a single line of code, avoided at least two full iterations of the data layer.

Integrating with PLCs, SCADA and Sensors: The Protocol Archaeology Nobody Budgets For

Before writing a line of code, you need to know exactly which protocols your machines speak — because discovering this mid-development is the most frequent cause of cost overruns in custom software development for industrial environments.

FlowFuse (March 2026) documents that Modbus continues to dominate at the field-device level, even on new equipment installed as a deliberate first choice. OPC UA is growing, but its adoption is concentrated in SCADA systems, MES integrations and IT/OT gateways — not in field-level PLCs. A typical industrial installation simultaneously speaks Modbus RTU, Modbus TCP, Profibus DP, HART, EtherNet/IP, classic OPC DA and proprietary dialects. PLC Construction (2026) confirms that Modbus RTU, DH+, Profibus and DF1 are the most common protocols in SCADA integration projects, and all require translation to OPC-UA to feed modern data layers.

Reference Table: OPC-UA Gateway Compatibility with Common PLCs

Estimates based on project experience; no verifiable primary source for 2025–2026 market rates. Treat as indicative.

The risk pattern we have seen materialise most often is the 10,000-tag problem: a protocol driver that works perfectly in the lab with 50 tags degrades or fails under real production load with 10,000 active tags, especially when the field network has electrical noise or unplanned jitter. The practical rule is always to load-test the driver against the real tag count before approving the integration.

Our work on the radiation inspection software for Enusa Industrias illustrates the additional dimension that appears in regulated OT environments: beyond protocol complexity, the software must meet traceability and functional safety requirements that affect the integration architecture from day one — not as an afterthought.

The 7-Gate Decision Framework for Industrial Custom Software Development

What does not exist in the available literature is a decision framework calibrated specifically for industrial environments — one that names the exact points where a project should pause, be validated or be cancelled before the next phase consumes budget on an unstable foundation. This is the central contribution of this article.

Each gate has entry criteria, exit criteria and the specific failure mode it prevents.

Gate 0 — Process Maturity Verification (before any requirements work)

Exit criteria: The current process is documented, stable and measurable. Not “we’ll fix it in the software”.

Failure mode prevented: Automating an immature process. If the process is underdeveloped, the software implements the wrong processes — and after deployment, the team blames the software for a problem that belonged to the process.

Gate 1 — Asset and Protocol Inventory (before locking requirements)

Exit criteria: Every data source inventoried with: make/model, firmware version, protocol, data update rate and confirmation of whether the manufacturer permits third-party read access.

Failure mode prevented: Discovering mid-project that a 2003 PLC speaks a proprietary dialect over a serial link. Budgeting for at least one unexpected protocol is a reasonable rule of thumb — sector data indicates that legacy system integration challenges 55% of projects.

Gate 2 — Trilateral Requirements Sign-Off (before architecture design)

Exit criteria: Requirements document signed by (a) the process/OT engineer, (b) the IT/systems manager, AND (c) the plant/operations manager — with an explicit conflict register showing how discrepancies were resolved.

Failure mode prevented: Unclear requirements and poor communication, which the Standish Group (2024) identifies as the primary causes of failure. A document signed by all three profiles is the most effective prevention mechanism and the most frequently omitted one.

Gate 3 — Integration Proof of Concept (before full development sprints)

Exit criteria: At least one live data reading from the most complex or legacy protocol, delivered to the target data layer, with latency and data-quality metrics documented. Load-test against the real tag count.

Failure mode prevented: The 10,000-tag problem. Discovering protocol incompatibility after three months of development. Reference cost: gateway hardware €500–€3,000/unit; integration engineering 40–120 hours per protocol family (engineering judgement).

Gate 4 — Scope Freeze and Change Control Activation (at the start of the first sprint)

Exit criteria: Formal change control process active. Any new requirement after this gate requires a written impact assessment (time + cost + risk) before being accepted.

Failure mode prevented: Scope creep, which according to available data causes 52% of custom projects to exceed their deadlines. In industrial environments, the specific driver is that process engineers discover new data points they “need” as soon as they see the system working — which is understandable, but must be channelled through a formal process.

Gate 5 — Staged Validation in the OT Environment (before production deployment)

Exit criteria: Parallel-run period completed (the new system runs simultaneously with the existing process, outputs are compared) with a documented delta below the agreed threshold. Cutover window scheduled during a planned maintenance shutdown.

Failure mode prevented: The cost of post-launch correction, which according to CISQ (cited by Capgemini, 2025) can be up to 30 times greater than in the design phase. The IEC 62443-2-1:2024 revision updates OT asset-owner security programme requirements for the first time since 2010; any validation plan must reflect this hierarchy: safety first, availability second, integrity third — the inverse of most IT frameworks.

Gate 6 — Change Management and Adoption Readiness (before go-live sign-off)

Exit criteria: All shift operators trained and assessed; SOPs updated; a designated “system owner” on the client side for ongoing governance; a support plan for the first 30 days agreed.

Failure mode prevented: Software that becomes shelfware. Implementing new tools “must be accompanied by change management and process adjustments — without adequate training and willingness from operational teams, new products become ineffective” (Artefact, 2025). For a 40-operator-per-shift operation, training and SOP rewriting can add 15–25% to the total project cost. Engineering estimate; no verifiable primary source.

The Hidden Costs That Destroy ROI Before the First Shift

Custom software development projects for manufacturers have a hidden cost structure that rarely appears in initial quotes.

Legacy protocol support: Each additional proprietary protocol adds 40–120 hours of engineering and €500–€3,000 in gateway hardware. Projects routinely discover 2–3 unexpected protocols during Gate 1.

Integration technical debt: Developers spend on average 22% of their time resolving issues related to bugs and technical debt. In industrial software, this debt manifests as fragile protocol adapters that break with PLC firmware updates — updates the manufacturer performs without consulting the software team.

Regulatory compliance: 28% of custom development projects experience delays due to regulatory compliance. In industrial contexts, this includes IEC 62443, NIS2 (which names IEC 62443 as a recognised standard for OT security), and ISO 13849/IEC 62061 for machinery with safety functions. These requirements must enter the architecture at Gate 2, not as an add-on during the validation phase.

Indicative Cost Ranges and Annual Maintenance

All figures are engineering judgement based on market observation; no verifiable primary source for current market rates.

Conventional software maintenance is typically estimated at 15–20% of initial development cost per year. With legacy protocol support, that figure rises to 20–30% (engineering judgement) because maintenance includes protocol adapters that can break with PLC firmware updates — and that specialised knowledge carries a high market cost. Ignoring this line item in the initial business case is the most frequent error that turns a profitable project on paper into an unplanned recurring cost.

Success Metrics That Actually Matter in Industrial Environments

A custom software development project in a manufacturing environment is not evaluated by classic software metrics alone. The metrics that actually matter to the plant manager are:

• OEE before/after: If the software connects machine data with operational decisions, OEE should move within the first 90 days of real use. If it doesn’t move, the project is not delivering operational value.
• Report cycle time: How long did it take to generate the shift report before? How long does it take now? This metric is easy to measure and directly visible to operators.
• Per-shift adoption rate: What percentage of operators actively use the system on each shift? A rate below 70% at 60 days post-go-live is a warning sign of failed change management.
• Integration incidents per month: Tracks the stability of protocol adapters. A rising number indicates accumulating technical debt.
• Post-launch correction cost vs. maintenance budget: If correction costs exceed 30% of the annual maintenance budget in year one, there are quality issues that Gate 5 failed to catch.

62% of Spanish manufacturing companies have at least a basic level of digitalisation, below the European average of 68.3% (Eurostat, 2024). 34.8% of Spanish industrial companies were innovative in 2022–2024, compared to a national average of 27.3% (INE, 2024) — suggesting that the industrial sector leads in intent but still has significant room to grow in execution. Measuring real ROI with concrete operational metrics is what turns that intent into a sustainable competitive advantage.

Related reading

• Custom Software for Manufacturing — the five-filter decision: build, buy, or leave it alone.
• Industrial Process Automation — how to pick the first process to automate — and which ones to leave manual.
• Radiation Inspection Software for Enusa Industrias — Maedcore
• Maedcore — Digital Solutions — what we build in this area.

Sources

• CHAOS Report on IT Project Outcomes — OpenCommons (Standish Group data synthesis), 2025
• 268% Higher Failure Rates for Agile Software Projects, Study Finds — Engprax / J.L. Partners, 2024
• Custom Software Development Industry Statistics: Market Data Report 2026 — Gitnux, 2026
• Custom Software Development Statistics 2026: 40+ Data Points — Raftlabs (citing Standish Group CHAOS Report 2024), 2026
• Next-Generation Industrial Software Development: Applied AI — Capgemini Spain (citing CISQ data), 2025
• Custom Software for Industry: 2026 Guide — Globental, 2026
• Why OPC UA Is Not Replacing Modbus (Yet) — FlowFuse, March 2026
• Common SCADA Integration Challenges and How to Solve Them — PLC Construction, 2026
• Converging IT and OT Will Boost Industrial Tech Value — Boston Consulting Group, 2024
• IT/OT Convergence — ISC2, August 2024
• IT/OT Convergence: The Path to Industrial Excellence — Artefact, 2025
• IEC 62443 Compliance Guide (ICS/OT) — Breach Craft (citing IEC 62443-2-1:2024), 2026
• SME Digitalisation in Spain 2026: Statistics by Sector and Size — 10Code / ONTSI, INE, Eurostat, 2026
• Industrial Digitalisation: Tax Incentives and Support Programmes — Tecnocim Innova (citing INE 2024, Eurostat 2024), 2026
• Radiation Inspection Software for Enusa Industrias — Maedcore