Predictive maintenance is the most frequently attempted industrial AI use case and one of the most frequently abandoned. The abandonment is rarely because the model was bad. It is because the conditions for the model to be useful were never in place, and nobody checked before the project started.
This checklist is what we would work through before recommending a pilot. It takes about an hour with a maintenance planner and whoever owns the historian. It is designed to produce a clear no as readily as a clear yes, because a cheap no is the more valuable outcome.
Where pilots actually fail
The mental model most organisations bring is that the hard part is the algorithm. In practice the sequence looks like this, and the attrition happens early.
The four preconditions
A predictive maintenance case works when four things are simultaneously true. Miss one and the project produces an interesting dashboard nobody acts on.
- A specific failure mode. Not “pump failures” — bearing wear on a named pump class, with a physical degradation mechanism you can describe.
- Data that could plausibly see it. A sensor measuring a quantity that changes as the mechanism progresses, sampled fast enough to catch it.
- Enough lead time to act. A warning that arrives four hours before failure is only useful if a four-hour intervention exists.
- A named person who acts. Someone whose job changes when the alert fires, with the authority to schedule the work.
Assumptions behind this checklist
- Rotating or reciprocating equipment with a progressive degradation mechanism. Sudden electronic failure and random damage are outside its scope.
- An existing maintenance function with some scheduling capability. This is a checklist for improving maintenance, not for creating it.
- Historian or SCADA data already being recorded, even if nobody currently uses it.
- Scoring weights are our judgement from the failure patterns above, not an empirically validated instrument. Treat the score as structure for a conversation, not a measurement.
The checklist
Score each item 0 (no), 1 (partly), or 2 (yes). Maximum 28.
A. The failure mode (max 6)
| # | Question | Score |
|---|---|---|
| A1 | Can you name one specific failure mode on one specific asset class, and describe physically how it progresses? | 0–2 |
| A2 | Has it happened at least 8–10 times in your recorded history, on comparable assets? | 0–2 |
| A3 | Do you know roughly what each occurrence cost, including lost production? | 0–2 |
A2 is the one that most often scores zero, and it is close to non-negotiable. A model learns to recognise a failure from examples of that failure. If it has occurred twice, you do not have a supervised learning problem — you have an anomaly detection problem, which is a different and harder proposition with a much weaker business case.
B. The data (max 10)
| # | Question | Score |
|---|---|---|
| B1 | Is there a sensor measuring something that physically changes as this mechanism progresses? | 0–2 |
| B2 | Is the sampling rate fast enough for the mechanism’s timescale? | 0–2 |
| B3 | Is history retained long enough to cover several failure cycles? | 0–2 |
| B4 | Can you tell, from records, when past failures occurred to within an hour? | 0–2 |
| B5 | Are maintenance interventions recorded, so you can distinguish a repaired asset from a healthy one? | 0–2 |
B4 and B5 together are the labelling problem, and they are where confident projects quietly collapse. Sensor data is usually abundant; knowing which period was “degrading” and which was “healthy after repair” usually is not. If your work-order system records the date but not the time, and the failure develops over hours, your labels are noise.
C. The decision (max 6)
| # | Question | Score |
|---|---|---|
| C1 | If you had 48 hours’ warning, could you actually do something different? | 0–2 |
| C2 | Are the parts, skills and access window available on that timescale? | 0–2 |
| C3 | Do you know what a false alarm costs, and what an acceptable rate is? | 0–2 |
C3 is the question that determines whether the system survives contact with operations. Every predictor trades missed failures against false alarms. If nobody has decided which error is worse before deployment, the threshold gets set by whoever complains loudest in week three, and the system is switched off by week six.
D. Ownership (max 6)
| # | Question | Score |
|---|---|---|
| D1 | Can you name the individual whose routine changes when an alert fires? | 0–2 |
| D2 | Have they agreed, in advance, on what they will do? | 0–2 |
| D3 | Is someone accountable for the system after the pilot ends? | 0–2 |
Reading your score
| Score | Reading | What we would do |
|---|---|---|
| 22–28 | Ready | Run a bounded pilot with a pre-agreed success criterion and a stop date. |
| 15–21 | Fixable gaps | Close the specific low-scoring items first. Usually cheaper and faster than the pilot itself. |
| 8–14 | Not yet | Improve recording practice and instrumentation. Revisit in six to twelve months. |
| 0–7 | Wrong problem | The value here is in maintenance basics, not prediction. |
One override, regardless of total: if A2 or D1 scores zero, treat the whole assessment as “not yet”. Without failure examples there is nothing to learn from, and without a named actor there is nothing to change. A high score elsewhere does not compensate.
If you are not ready
Not being ready is a normal and useful finding, and the remedies are cheap relative to a failed pilot.
- Fix the work-order record. Timestamp interventions to the hour and record what was actually replaced. This costs nothing and is the highest-value single change.
- Instrument one asset class properly rather than all of them thinly.
- Write down the cost of the failure you care about. Most organisations discover the case is weaker or far stronger than assumed.
- Try condition-based rules first. A threshold on a well-chosen sensor, reviewed weekly, captures a surprising share of the value and tests whether anyone acts on alerts at all — the cheapest possible test of preconditions C and D.
That last point is worth taking seriously. If a simple threshold rule does not change behaviour, a model will not either. The constraint was never predictive accuracy.
Limits of this checklist
The checklist screens; it does not assess. It will not tell you which algorithm to use, what accuracy your data can support, or what a vendor should charge for the work.
It also assumes progressive mechanical degradation. Electronic failure, process quality excursions and safety-instrumented systems fall outside it, and each carries requirements of its own.
Its job is narrower. If you do start, start on a case that can finish.
Found an error? Tell us and show your working — we correct in place and record what changed. Contact us.