How To Scope Manufacturing IT Consulting Around Your Team

Key Highlights

• Anything a plant adjusts more than twice a year, including sampling rates, alert thresholds, and report schedules, should be delivered as configuration that the internal team can change without a developer.
• Multi-site data rollouts complete more reliably when phased one site at a time, because each plant runs a different equipment mix and absorbs change at a different rate.
• Time and materials covers 99% of Accedia's application development engagements, because older plant equipment is rarely known well enough to price a fixed scope.

What Manufacturing IT Consulting Looks Like In a Small Team

A 600-employee automotive supplier has signed a manufacturing IT consulting partner. Its entire IT function is three people. The Head of IT owns enterprise resource planning (ERP), plant systems, and security, and runs all of it with two direct reports. Eighteen months later, the engagement closes, and everything it delivered carries on under that team.

Manufacturing IT consulting covers advisory and delivery work across the gap between operational technology (OT) on the plant floor and enterprise IT, connecting machine data, plant systems, and business software for industrial companies. In a company staffed like that one, five scoping decisions carry more weight than the rest:

• How much you automate
• How you sequence the rollout
• Which integrations you allow to be custom
• What the handover contains
• Which systems your own team keeps running

Every one of them comes back to how much a team that size can realistically carry after the partner has gone.

Fixed Price Or Time And Materials For Plant Systems

Plant systems are hard to price accurately until someone has profiled the environment. The machines come from different vendors and production generations, and their data output varies just as much. One line reports clean values, another sends counters that reset without warning, and a third has documentation that no longer matches the hardware on the floor.

A partner quoting a fixed price against equipment it has not yet assessed has to either build a large uncertainty buffer into the number or accept the risk of finding work nobody scoped. Either way, the uncertainty reaches the client team later, as a higher upfront cost or as change requests during delivery.

According to Accedia's AI Delivery Report 2026, time and materials covers 99% of our application development engagements. Clients choose that structure for scope control and for the room to shift priorities as the team learns how the machines, the data, and the existing systems behave.

Choosing Between Configuration And Custom Code

Every component you commission has to be maintained by someone, so scope each one against whoever will be changing it after go-live.

Deloitte's 2025 Smart Manufacturing and Operations Survey asked manufacturers about hiring. Between 69% and 72% reported moderate to significant difficulty filling IT, OT, data, and cybersecurity roles. That survey covers manufacturers with $500 million or more in revenue and over 1,000 employees. An IT function of two or three has less room than any of them. If nobody on your team could maintain a component, do not commission it in a form that only a developer can change.

Configuration Your Own Team Can Change Without A Developer

When we consolidated machine data for a European industrial bearings manufacturer between 2020 and 2022, the equipment spanned several generations, types, and makers. What mattered most over the long run was letting the client's own team adjust collection settings remotely and in real time. They could change which machines report, how often, and which values to capture, without raising a development ticket.

Anything a plant adjusts more than twice a year belongs in configuration, including sampling rates, thresholds, alert recipients, report schedules, and unit mappings. The extra development cost is real, and it is usually small next to two years of change requests.

Changes That Belong Under Version Control

Some work belongs in code, because making everything configurable produces a settings screen nobody understands. Anything touching a machine's control logic, safety interlocks, or certified process parameters should stay under version control with a documented review step. The same applies to integrations with financial consequences, including anything that writes to your ERP, where you want changes to be slow and visible. A European rail engineering group asked us to build a scheduled interface between its product data system and the ERP between 2021 and 2023, including the field mapping that populated ERP dropdown values. That work sits under version control because a wrong mapping shows up as bad data inside the ERP, where nobody notices it for weeks.

Write the split into the statement of work. For each component, name who changes it, how often, and what happens if they get it wrong.

How To Phase A Multi-Site Rollout One Site At A Time

System-by-system rollouts are the default in enterprise software. They suit organizations with a central IT function large enough to run several projects in parallel, which most manufacturing groups do not have.

Both of our multi-site data programs were sequenced by site. With the same bearings manufacturer, we extracted and processed data locally at each site before moving anything to the cloud, bringing factories online one at a time between 2021 and 2022. The same rail engineering group asked us to normalize telemetry from sensors supplied by several vendors. Between 2021 and 2023, we started with a single national branch and built the expansion to the wider group into the architecture from the outset. Both were sequenced that way because a small internal team can absorb one location at a time. That same constraint shapes how we scope IoT application development work for manufacturers.

Why Site-By-Site Sequencing Works For A Small Team

The first site takes the longest and produces the runbook, because the questions your team asks during that deployment become the instructions for every site after it. By site three, the internal team is usually running the deployment while the partner answers questions.

Equipment mix, network topology, maintenance culture, and tolerance for downtime vary from one plant to the next. A system-by-system rollout meets all of those variations at once, with the same internal team handling every escalation.

How To Split The Work With Your Manufacturing IT Consulting Partner

Most manufacturers outsource heavily and are right to. Between 65% and 70% of those same large manufacturers outsource technology, data, and cybersecurity roles, according to Deloitte, while only 32.5% bring in outside help to manage the organizational change those projects create. The change work stays inside, which means digital transformation in manufacturing lands on the same small internal team that will own the result.

A partner can carry almost all of the delivery work. Two things belong on the client side, and they are the two that make everything else safe to hand over.

Decision Rights Over The Data Model

A machine, a batch, a downtime event, and a defect are business definitions, and they set the limits of what every future system can answer. Once a partner owns them, every later project starts by asking that partner what the data means, and the dependency gets expensive quickly.

Ownership Of The Integration Inventory

Keep a live list of every connection between your systems. Record what each one moves, how often it runs, who owns each end, and what happens when it breaks. Maintaining it is unglamorous work, and it decides whether your next project takes three months or nine.

What a Partner Can Take On

Code is only part of what a partner can carry. A manufacturing software provider can hold the repository, run the deployment pipeline, own the cloud environment the system runs on, take the on-call rotation, and handle upgrades and dependency management for as long as the engagement runs. For an IT function of three, that is usually the right arrangement, and trying to pull any of it back in-house is how small teams end up firefighting instead of running the plant. What matters is that you can describe what the system does, why it works that way, and what would have to change to make it do something else.

Handover Documents, Workshops, And The Runbook

Contracts usually define handover as a document delivery, which does not help when a data pipeline stops overnight, and nobody has opened the documents.

In 2020, we consolidated ERP and CRM data into a single internal portal for an industrial safety components supplier serving the petrochemical, steel, and pharmaceutical sectors. The engagement also included internal technology workshops for the client's own team, written into the scope and delivered alongside the work itself.

Handover for a small internal team has to include architecture documentation, working sessions, and a runbook.

• Architecture documentation that captures the reasoning behind each decision. These records keep their value for years after the diagrams have gone stale, explaining why one integration runs overnight instead of in real time, or why one data source outranks the others.
• Working sessions run by the engineers who wrote the system, booked with months still left on the engagement, so your team can break something and repair it while those engineers are still on the account.
• A runbook covering every incident that came up during delivery. That record is the most useful document your team will own, and it usually lives only in someone's memory unless you ask for it in writing.

Scoping The Engagement Around The Team You Have

All of these decisions reduce to what two or three people can carry on their own. Working that out during scoping is what sizes the engagement correctly, because by handover the expensive choices have already been made.

Engagements last when the client's own team can operate what was delivered. Accedia's AI Delivery Report 2026 records documented engagements averaging five years or more, with 91% client retention. One US dairy processing business has worked with us since 2019, across inventory, reporting, and warehouse systems, including a warehouse platform running inside one of its production plants.

Before the statement of work is signed, our Manufacturing and Automotive team will work through what your team keeps, what gets automated, and what the handover has to contain.