How to Scope a Manufacturing Digitalization Project: A Six-Stage Delivery Model

Why scope definition decides more than platform selection

Most of the evaluation period goes into comparing platforms: which SCADA, which MES, which database, which protocol stack. That comparison matters, but it is seldom the reason a project fails. Projects fail because no document states where phase one ends.

Scope is not a paragraph in a proposal. It is a set of specific answers — which line, which stations, which data items, which reports, and which conditions mean the work is complete. Until those answers exist, effort estimates are guesses, and later change requests have no baseline to be measured against.

• Every meeting adds stations and reports, and no document records what was taken out in exchange
• An improvement target was agreed before any baseline was measured, so afterwards neither side can demonstrate whether it was met
• The word "integration" appears in the contract without naming the counterpart system, the data direction, or who owns master data
• Screens are discussed in detail while the source address of each data item is still unassigned
• Acceptance is described as "the system operates normally", with no measurable condition attached

All five signals appear before a single line of code is written, which is also why all five are still inexpensive to correct at that point.

Six stages, and what each one is expected to produce

The model below splits a digitalization project into six stages. Naming them is not process formality — the point is that each stage gets an exit condition, so both sides can tell whether it has actually finished.

• Diagnosis — produces a pain-point assessment and a measured data baseline. The working rule is measure first, calculate later: collect baseline data before agreeing improvement targets and scope. It does not produce a firm price for a whole-plant rollout.
• Pilot — when the scope can be fenced off, a small area runs first, with acceptance criteria agreed in advance; periods and indicators that have no confirmed value are surveyed and confirmed by both sides. It does not produce a plant-wide rollout.
• Implementation and commissioning — starts from standardized engineering templates: I/O allocation, tag lists, network topology and screen specifications come before the build. For retrofit work it also produces a construction plan that keeps production running. It does not produce new requirements; those belong to a change process.
• Acceptance documentation — the documents are themselves deliverables: operation manuals, database table descriptions, interface specifications, tag list drawings and other materials agreed against the contract and project scope, so the plant can manage, query and extend the system later. It does not produce whatever documents someone remembers to ask for after handover; the list is fixed in the technical agreement.
• Annual maintenance — produces a standardized maintenance contract, a maintenance checklist that rolls forward year by year, and an annual maintenance report, so support becomes measurable and reviewable. It does not produce unlimited new development.
• Expansion — advances a second phase based on project scope and an on-site assessment, giving priority to compatibility with the existing investment. It does not produce a replacement for phase one.

The "does not produce" half carries as much weight as the first half. Most handover disputes trace back to work that one side assumed sat inside a stage where it was never agreed.

Stage by stage: deliverables and buyer decisions

The table below is written to be used as a checklist during supplier discussions. If the third column cannot be filled in for a stage, that stage is not scoped yet, whatever the proposal says.

The numbering is a sequence, not a schedule. Diagnosis may take days, a single-line pilot four to eight weeks, a plant-wide implementation considerably longer. Fixing the exit condition of each stage matters more than fixing its duration.

Documents are deliverables, not paperwork

A familiar pattern: the system works, the supplier's engineer knows how it works, and nothing else does. Two years later the line is modified, that engineer has moved on, and the plant cannot change a report because nobody wrote down which tables it reads.

A complete industrial project document set runs to fourteen types. Grouping them by the point at which they are produced makes it easier to check a supplier's list against the contract.

The recommended approach is to attach this list to the technical agreement rather than rely on goodwill. A document set agreed in writing costs nothing extra at signing, and is expensive to reconstruct once the project team has dispersed.

Which indicators belong in the technical agreement

"The system operates normally" cannot be tested. An acceptance clause is only useful if a third person with no project history can read it, run a test, and arrive at a yes or a no.

The indicators below are measurable on site, and are the ones worth negotiating before signing. The values should be filled in jointly against the actual process rather than copied from a template.

• Data backfill after an outage: once communication is restored, whether process curves covering the interrupted period are recovered automatically, and how completeness is verified
• Alarm accuracy: how false alarms and missed alarms are counted, over which observation window, and what threshold is acceptable
• Data latency: the interval from a change at the device to its appearance on screen and in the database, stated as a figure rather than as "real time"
• Report definitions: for each report, the aggregation rule, the shift boundary, the time zone and the rounding method — so production and quality read the same number
• Recovery and response: restart time after a server fault, the retention period before data moves to a history archive, and the response time committed under maintenance

Indicators such as data backfill after an outage and alarm accuracy can be written into a technical agreement as acceptance conditions, and asking a supplier to accept them is a reasonable request rather than an unusual one.