Technical proposals for industrial pilots: write a scope you can accept

01

State a testable problem

Describe the decision that is slow or unreliable, its owner, frequency, cost of the current process and available data. Avoid opening with a product name. For example, a reliability team may spend hours joining work-order and historian data before validating one alert.

02

Bound the use case

Name the site, asset class, equipment count, data sources, time period, users and exclusions. State whether integrations only read or may write. A read-only pilot differs materially from one that creates work orders in production.

03

Tie deliverables to responsibility

Each deliverable needs a format, input provider, author, reviewer and handover condition. Data mapping, solution design, test report, training material and runbook should not hide under one line called “documentation”.

04

Define acceptance and go/no-go

Choose baseline measures that fit the use case: data quality, processing time, false-alarm burden, adoption or mapping accuracy. State measurement method, sample size and limitations. If no baseline exists, the first pilot phase must establish it.

05

Record assumptions and change control

Separate assumptions about access, security, licences, SME time and data availability. Define what changes timeline or scope, how a change request is approved and which data must never enter a public demo.

06

Write scope with countable boundaries

An EAM/APM pilot should specify sites, asset classes, Asset count, data sources, historical period, interfaces, user roles, and deployment environment. State whether each interface is read-only or writes back, batch or near-real-time, and uses production or anonymized data. Exclusions should be concrete: no full PM optimization, CMMS replacement, or automated work-order approval, for example. “Implement an APM solution” is too broad to price or accept.

Include a sample journey: where data originates, how it is checked, who reviews an insight, which EAM action follows, and what evidence proves the result. The journey reveals dependencies such as tag mapping, access rights, engineer confirmation of events, and shutdown schedules. It also provides a way to reduce scope if data proves insufficient.

07

Separate deliverables, acceptance, and outcomes

Deliverables are handed over: data assessment, mapping, configuration, test scripts, training, and runbook. Acceptance defines when each is received: required fields, passed test cases, reviewer sign-off, and an issue log. Outcomes are expected operational changes, such as less time assembling data or more work orders linked to the correct Asset. Mixing these three can create an unjustified ROI commitment before baseline and operating conditions are known.

Use an acceptance matrix with method, sample size, evidence source, tolerance, and signatory for each item. Test mapping on Assets that include duplicate IDs and replacements; compare analysis time on like-for-like cases. For AI, include severe errors, evidence-backed answers, and review effort. Measures should fit the use case rather than a generic pilot benchmark.

08

Manage assumptions through stage gates

An assumption register should identify the confirmer, due date, and effect if wrong: historian access, tag quality, work-order history, SME availability, licences, and security review. Connect each critical assumption to a decision gate. After discovery, the parties may keep scope, revise the approach, extend data preparation, or stop a pilot that can no longer test its objective.

A proposal also needs RACI, a dependency-based timeline, and a change-control route. Reserve time for UAT and data correction; a pilot is not only software configuration. At close, a scale decision should use an evidence package: baseline, test results, limits, operating cost, and technical backlog. A smooth demo proves demonstrability, but not readiness for site-wide deployment.

09

Illustrative example: a maintenance-alert pilot

A proposal scopes 20 Assets at one site, six months of historian and work-order data, and read-only integration. Discovery produces an asset/tag map and validates failure events; if evidence is insufficient, both parties may shift from failure prediction to reviewed anomaly detection. Deliverables include data assessment, architecture, pipeline, case review, test report, and runbook. The acceptance matrix specifies mapped Assets, sampling method, share of alerts with disposition, review time, and severe errors; targets are agreed after baseline. Exclusions state that the pilot will not create work orders automatically, span multiple sites, or promise downtime reduction before evidence exists. The closing gate assesses technical results, operating effort, and running cost before a scale decision.