Predictive Maintenance and Failure Prediction: A Practitioner Guide

Every vendor pitch deck on predictive maintenance shows the same slide: a gauge, a trend line curving toward a red zone, and a confident claim that artificial intelligence will now tell you exactly when your equipment is going to fail. Sit through enough of those decks, as I have across CMMS, EAM and asset-management implementations, and you learn to separate the parts that are real from the parts that are aspiration dressed up as capability. Predictive maintenance is real. Failure prediction is real. Remaining useful life estimation is real. But all three are far more conditional, far more data-hungry, and far more selective about where they pay off than the marketing suggests. This guide is the honest version.

The message up front: predictive maintenance is not a product you buy, it is a capability you build on top of good asset data, sound condition monitoring, and years of clean maintenance history. On the right critical assets it pays back many times over. On the wrong assets it is an expensive way to generate charts nobody acts on. Knowing the difference is the entire skill.

1. Reactive, preventive, predictive: the three strategies and where each belongs

Maintenance strategy sits on a well-established maturity ladder, and every serious conversation about predictive maintenance has to start by placing it correctly on that ladder. There are three primary strategies, plus condition-based maintenance as the bridge between the last two, and reliability-centered maintenance as the discipline that decides which strategy each asset should get.

• Reactive maintenance (run to failure): you operate the asset until it breaks, then you fix it. This has a terrible reputation it does not always deserve. For low-consequence, low-cost, easily-replaced assets, run to failure with a fast corrective response is the rational economic choice. The failure of a cheap exhaust fan in a car park is not worth a monitoring program. The problem is not reactive maintenance itself, it is reactive maintenance applied by accident to assets that should never have been left unmanaged.
• Preventive maintenance (time or meter-based): you inspect, service or replace on a fixed schedule regardless of actual condition. Monthly pump inspection, annual statutory testing, oil change every 500 running hours. It is predictable, plannable and easy to audit. Its weakness is that it is blind to actual condition, so you over-maintain healthy assets and can still be surprised by an asset that fails between intervals.
• Predictive maintenance (condition and data-driven): you monitor the actual condition of the asset, detect the early signature of a developing failure, and intervene only when the evidence says intervention is needed. Done well, it catches failures before they happen while avoiding the waste of fixed-interval work on healthy equipment.

The honest framing I use with clients: these are not ranked from bad to good, they are matched to consequence. The goal is not to make every asset predictive. The goal is to put each asset on the strategy that gives the best reliability for the least total cost, and predictive is simply the most sophisticated and most expensive option, reserved for the assets whose failure genuinely hurts. For the broader time-versus-meter-versus-condition framework, see the preventive maintenance strategies pillar, and for the design discipline that keeps a PM program from bloating, the PM program design pillar.

2. What predictive maintenance actually is (and is not)

There is real confusion between condition-based maintenance and predictive maintenance, and vendors are happy to keep the confusion alive because it lets them sell the cheaper thing as the more valuable thing. The distinction matters.

Condition-based maintenance reacts to a current condition crossing a threshold. Bearing temperature exceeds 80 degrees, generate a work order. Vibration amplitude passes an alarm limit, dispatch a technician. It answers the question: is this asset unhealthy right now? That is genuinely useful and it is the foundation of everything above it, but it is not prediction. It is a smarter alarm.

Predictive maintenance goes one step further and answers a harder question: given the trajectory of this asset's condition, when is it likely to fail, and how much useful life does it have left? It is the difference between a smoke detector that beeps when there is already smoke, and a system that watches the wiring warming up over weeks and tells you the fault is developing before anything ignites. The first is condition-based. The second is predictive.

In practice most organisations that claim to be doing predictive maintenance are doing condition-based maintenance with trend charts, and that is fine as a starting point. The prediction layer, the part that estimates time-to-failure and remaining useful life with any rigour, is where the real difficulty and the real value both live. Be honest with yourself about which one you are actually operating, because the investment, the data requirements and the skills are very different.

3. Condition monitoring: the techniques that feed prediction

Prediction is only as good as the condition data underneath it, and condition monitoring is the set of techniques that produce that data. None of this is new or exotic. Reliability engineers have used most of these methods for decades. What has changed is that sensors got cheap, storage got cheap, and analytics got accessible, so techniques that used to require a specialist with a handheld device on a monthly round can now run continuously. The core techniques worth knowing:

• Vibration analysis: the workhorse of rotating equipment monitoring. Bearing wear, imbalance, misalignment, looseness and gear defects each produce a characteristic vibration signature at predictable frequencies. Vibration is the single richest early indicator for pumps, motors, fans, compressors and gearboxes, which is exactly why rotating equipment is where predictive maintenance delivers most of its value.
• Infrared thermography: heat is the universal symptom of a developing electrical or mechanical fault. Loose electrical connections, overloaded circuits, failing bearings, blocked cooling and refractory breakdown all show up as thermal anomalies long before failure. Thermography is cheap to deploy and broadly applicable across electrical distribution, mechanical plant and building envelope.
• Oil and lubricant analysis: the oil in a gearbox or engine carries a chemical and particle record of what is wearing inside it. Metal particles indicate specific wear surfaces, viscosity change indicates degradation, contamination indicates seal or filtration failure. Oil analysis often gives the longest lead time of any technique, catching developing wear weeks or months out.
• Ultrasonic analysis: high-frequency sound reveals things the human ear and even vibration sometimes miss: compressed air and steam leaks, early bearing lubrication problems, electrical partial discharge and arcing, and valve pass-through. Ultrasound is particularly strong for leak detection and early-stage bearing faults.
• Motor current signature analysis: the electrical current drawn by a motor encodes mechanical information about the load it is driving, so broken rotor bars, air-gap eccentricity and certain driven-equipment faults can be detected from the electrical supply without touching the machine.
• Process parameter monitoring: the operating data you already have, flow, pressure, temperature, speed, power draw, is condition data in disguise. A pump whose discharge pressure is slowly dropping at constant speed is telling you something is wearing. You do not always need new sensors; sometimes the SCADA or BMS historian already holds the signal.

The practitioner's point: you do not deploy all of these on all assets. You choose the technique that matches the dominant failure modes of the specific asset class. Vibration and oil analysis for rotating equipment. Thermography for electrical distribution. Ultrasound for compressed air systems and switchgear. Matching technique to failure mode is where reliability engineering earns its keep.

4. Sensor-based maintenance and the IoT layer

The shift that made predictive maintenance a mainstream conversation rather than a specialist discipline is the collapse in the cost of continuous sensing. A vibration route that used to mean a technician visiting each machine monthly with a handheld analyser can now be a permanently mounted wireless sensor streaming data every few minutes. That changes two things: you get continuous coverage instead of monthly snapshots, and you catch fast-developing faults that a monthly round would miss entirely.

A sensor-based maintenance architecture has a few layers, and understanding them keeps you from being sold a black box:

The layer that organisations consistently underinvest in is the last one, the integration back into the CMMS or EAM. A predictive insight that lands as an email or a dashboard alert, disconnected from the maintenance system of record, will be ignored within weeks. The value is only realised when a prediction becomes a work order in the same system where the technician already works, gets scheduled, executed and closed out, and the outcome feeds back to improve the model. I have seen more predictive maintenance programs fail on this integration gap than on any sensor or algorithm problem. The technology worked; the workflow did not close the loop. For the underlying operational-technology-to-enterprise-IT bridge, this is the same OT/IT integration challenge that shows up across BMS, SCADA and IoT projects.

The honest limitation: sensors generate data continuously, but data is a cost until it becomes a decision. Many programs end up with terabytes of vibration data, a wall of dashboards, and no measurable change in failure rate, because nobody built the discipline to act on the signal. More sensing without more acting just moves the waste from over-maintenance to over-monitoring.

5. Historical maintenance analysis: mining the data you already own

Before you buy a single sensor, there is a source of predictive insight most organisations already own and rarely exploit: the failure history sitting in the CMMS or EAM. Every completed work order, every failure code, every part consumed, every hour of downtime recorded over the last several years is a record of how your assets actually fail. This is the cheapest predictive input available, and it is free because you already paid to collect it.

Historical maintenance analysis answers questions that shape the entire strategy:

• Which assets fail most, and how? A Pareto analysis of failures by asset and by failure mode almost always shows that a small number of asset classes generate most of the unplanned work. Those are your predictive maintenance candidates.
• What are the dominant failure modes? If bearing failure is the most common cause on your pumps, vibration monitoring is indicated. If it is seal failure, the sensor strategy is different. The failure history tells you what to monitor for.
• What is the mean time between failures per asset class? MTBF from historical data is the baseline you measure any predictive program against. If you cannot show MTBF improving, the program is not working.
• Are there patterns in timing? Failures clustering after a certain running-hours threshold, or a certain season, or a certain operating regime, are predictive signals hiding in plain sight.
• What did previous failures cost? Downtime hours, emergency labour, expedited parts, and consequential losses. This is the number that justifies (or fails to justify) the predictive investment.

The uncomfortable truth I raise in most audits: this analysis is only as good as the data quality, and most CMMS failure data is poor. Failure codes applied inconsistently, downtime not captured, root causes left blank, work orders closed with a comment of "fixed". If your maintenance history is unreliable, fix that first, because no amount of machine learning rescues bad input data. Clean, disciplined failure coding is the unglamorous foundation of everything predictive. See the failure codes pillar for the Problem-Cause-Action structure that makes this history usable.

6. Failure prediction and the P-F curve

The single most useful mental model in predictive maintenance is the P-F curve. It describes the interval between the point where a failure first becomes detectable (P, the potential failure point) and the point where the asset actually fails functionally (F). Everything predictive is about detecting P as early as possible and using the P-F interval to intervene on your terms rather than the failure's.

Two things determine whether prediction is even possible for a given failure mode. First, does a detectable warning exist at all? Some failures are gradual and give weeks of warning (bearing wear, insulation degradation, corrosion). Others are effectively instantaneous (a control board frying, a sudden fracture) and no monitoring will predict them because there is no P-F interval to detect. Second, is your monitoring frequent enough to catch the P point within the interval? A failure mode with a two-week P-F interval monitored monthly will still surprise you. The monitoring interval must be shorter than the P-F interval, ideally by a comfortable margin.

This is why I push back when someone wants to make an asset predictive without first asking whether its failure modes even have detectable warning. Predictive maintenance works brilliantly on failure modes with long, detectable P-F intervals, and not at all on sudden failures. Choosing the right assets is choosing the right failure modes. Get that wrong and you can install every sensor on the market and still get surprised.

7. Remaining Useful Life: what it is and how far to trust it

Remaining useful life (RUL) is the headline output everyone wants: not just "this asset is unhealthy" but "this asset has approximately N days of useful life left under current operating conditions." It converts a condition signal into a planning horizon, which is what maintenance planners and operations managers actually need to schedule intervention, order parts and coordinate downtime.

RUL is estimated a few different ways, and it is worth understanding the spread because the confidence you can place in the number varies enormously:

• Physics-based (model-driven): an engineering model of the degradation mechanism, for example a crack-growth or wear model, projected forward. Accurate when the physics is well understood and the operating conditions are stable, but expensive to build per asset type and brittle when reality diverges from the model.
• Trend extrapolation (condition-driven): take the measured degradation trend, vibration climbing, oil metal content rising, and extrapolate to the known failure threshold. Simple, transparent, and often good enough. Its weakness is that degradation rarely follows a straight line all the way to failure; it tends to accelerate near the end.
• Data-driven (statistical / machine learning): train a model on the histories of many similar assets that ran to failure, and use it to estimate RUL for a running asset from its current condition pattern. Powerful when you have a large fleet of identical assets and plenty of run-to-failure examples. Weak, and this is the common case, when you have a handful of unique assets and almost no clean failure histories to learn from.

The honest caveat on RUL: a single RUL number with no confidence interval is close to dishonest. Real degradation is variable, operating conditions change, and the estimate should always come with a range and a confidence level. "Approximately 30 to 45 days at current duty, moderate confidence" is a usable engineering statement. "23 days" presented as certainty is a false precision that will eventually burn the person who trusted it. Treat RUL as a planning aid that sharpens over time as the asset approaches failure, not as a countdown clock.

In the operations I have been close to, RUL is most valuable not as a precise number but as a re-planning trigger: it tells you an asset has moved from "monitor" to "plan an intervention in the next maintenance window" to "act now." That coarser use of RUL is robust and actionable even when the exact day count is uncertain.

8. Machine learning models: where they help and where they are oversold

Machine learning is the part of predictive maintenance that generates the most excitement and the most disappointment, usually in the same organisation, about eighteen months apart. Used well and in the right context, ML genuinely finds failure signatures that simple thresholds miss. Sold as a magic box that learns your plant on its own, it wastes money and credibility. Here is the practitioner's map of what actually works.

The model types that show up in real predictive maintenance:

• Anomaly detection: the most broadly useful and the least demanding on labelled data. The model learns what "normal" looks like for an asset from healthy operating data, then flags deviations. You do not need failure examples, only a good picture of normal, which makes this the realistic starting point for most sites.
• Classification: given a labelled history of faults, the model learns to recognise specific failure types from their signatures (this vibration pattern means bearing wear, this one means misalignment). Powerful, but it needs a labelled fault history, which most organisations do not have in usable quantity.
• Regression / RUL estimation: models that output a remaining-useful-life number from condition inputs. The most valuable and the most data-hungry, needing many run-to-failure examples of similar assets to be trustworthy.
• Survival and reliability models: statistical models of failure probability over time, blending condition data with age and duty. Well suited to fleets of similar assets where you care about population reliability as much as individual prediction.

The reality check I give every client considering an ML-heavy program: machine learning is not a substitute for data, it is a consumer of it. The models are only as good as the volume and quality of the history they learn from. An organisation with three unique large assets and two years of patchy CMMS records is not a candidate for sophisticated failure-prediction models, no matter what the vendor promises. An organisation with two hundred identical pumps across a fleet, streaming condition data, with clean failure histories, is a genuine candidate. Fleet size, data quality and failure-mode consistency decide whether ML earns its place, not enthusiasm.

My advice in practice is to start simple and earn the right to complexity. Physics-based thresholds and trend extrapolation deliver most of the achievable value on most assets, are transparent enough that engineers trust them, and do not require a data-science team to maintain. Reserve machine learning for the specific, high-value assets where simpler methods have proven insufficient and where you genuinely have the data to support it. That is the opposite of the usual sequence, where the ML platform is bought first and the use case is hunted for afterwards. For how AI is starting to accelerate these workflows in practice, see the AI copilot for utilities CMMS pillar and the computer-vision inspection pillar.

9. The ROI of predictive maintenance: judging the return honestly

This is the section that should come before the sensor purchase order, not after. Predictive maintenance has a real and well-documented return, but it is highly asset-specific, and averaging it across a whole plant is how organisations end up disappointed. The return comes from a few distinct sources:

• Avoided unplanned downtime: catching a failure before it becomes a functional failure converts an expensive emergency into a planned intervention. On a critical production or utility asset, a single avoided unplanned outage can pay for the entire monitoring program.
• Avoided secondary damage: a bearing caught early is a cheap replacement; the same bearing run to destruction can take out the shaft, the seal and the coupling. Predictive intervention often prevents a small failure from cascading into a large one.
• Reduced unnecessary preventive work: moving healthy assets off fixed-interval intrusive maintenance onto condition-based intervention saves labour and reduces the maintenance-induced failures that intrusive work sometimes causes.
• Extended asset life: intervening on developing faults before they damage the wider machine extends useful life and defers capital replacement.
• Optimised spare parts and labour: knowing which assets are developing faults lets you stage parts and schedule crews efficiently, reducing both expedited-parts cost and idle technician time.

Against those benefits sit real costs that vendors are quieter about: the sensors and installation, the data platform and integration, the analytics licensing, the reliability-engineering skill to interpret results, and the ongoing effort to keep models and thresholds tuned. The honest ROI question is not "does predictive maintenance pay off in general", it is "does it pay off on this specific asset, given its failure consequence, its failure modes, and the cost of monitoring it."

The simple framing I use to triage a portfolio:

Run that triage across the asset register and predictive maintenance usually earns its place on ten to twenty percent of assets, the critical rotating equipment and key electrical infrastructure, and does not earn its place on the rest. That concentration is not a failure of the technology; it is the technology being applied where it actually returns. A program that targets the right ten percent and leaves the rest on appropriate preventive or reactive strategies will outperform a program that tries to monitor everything, and it will cost a fraction as much. For the criticality ranking that drives this triage, see the asset criticality classification pillar, and for the KPI frame that proves the program is working, the FM KPI framework pillar.

10. How to actually start: a practical roadmap

If predictive maintenance is on your agenda, the sequence matters more than the software choice. The roadmap I would advise any operation to follow:

• Step 1: mine your history first. Before buying anything, analyse the failure data you already have. Identify the assets and failure modes generating the most unplanned work and cost. This is free and it tells you where any investment should go.
• Step 2: fix the failure coding. If the historical analysis reveals unreliable data, that is the first project. Clean, consistent failure codes and downtime capture are the foundation. There is no shortcut around this.
• Step 3: triage by consequence and detectability. Rank assets by failure consequence, then screen for whether their dominant failure modes are detectable with a usable P-F interval. The intersection is your candidate list.
• Step 4: pilot on a handful of critical assets. Pick a small number of high-value candidates, deploy the matching condition-monitoring technique, and integrate the output into the CMMS as real work orders. Prove the loop closes before scaling.
• Step 5: measure against baseline. Track MTBF, unplanned downtime and emergency-work percentage on the pilot assets against their pre-program baseline. If the numbers do not move, diagnose why before expanding.
• Step 6: scale deliberately. Extend only to assets where the triage justifies it and the pilot pattern applies. Resist the pull to monitor everything. Deliberate concentration beats broad coverage.

Notice that steps one through three cost almost nothing and can be done with the systems you already run. Most of the value discovery in predictive maintenance happens before any sensor is bought. Organisations that reverse this sequence, buying the platform first and looking for the use case afterwards, are the ones that end up with the disappointed-eighteen-months-later story.

11. The mistakes I see repeatedly

Across implementations and advisory work, the failure patterns in predictive maintenance programs are remarkably consistent:

• Buying the platform before defining the use case. The technology arrives looking for a problem to solve, and the program never recovers the initiative.
• Monitoring assets whose failures are not predictable. Sensors on assets with sudden, undetectable failure modes generate data and no value.
• Ignoring the CMMS integration. Predictions that live in a separate dashboard, disconnected from where technicians actually work, get ignored within weeks.
• Building on unreliable failure history. Machine learning on bad data produces confident nonsense. Clean data first.
• Presenting RUL as false precision. A day-count with no confidence range will eventually be wrong in a way that destroys trust in the whole program.
• Trying to monitor everything. Spreading a fixed budget across the whole register instead of concentrating it on the critical minority produces thin coverage and weak returns everywhere.
• Measuring activity instead of outcomes. Number of alerts generated is not a success metric. Reduced unplanned downtime and improved MTBF are.

Every one of these is avoidable, and none of them is a technology problem. They are strategy and discipline problems, which is good news, because it means the fix is within the control of the maintenance leadership rather than dependent on a vendor roadmap.

The idea to walk away with

Predictive maintenance is not a level of maturity you graduate the whole plant to. It is a targeted capability you deploy on the specific assets whose failures are both consequential and detectable, built on a foundation of clean maintenance history, sound condition monitoring, and a workflow that turns predictions into closed-out work orders. On those assets it is genuinely transformative. On the rest, simpler strategies are not a compromise, they are the correct answer.

The reason so many predictive maintenance programs disappoint is not that the technology does not work. It is that the technology was pointed at the wrong assets, fed with poor data, disconnected from the maintenance system, and measured by activity rather than reliability. Fix the targeting, fix the data, close the loop, and measure the right thing, and predictive maintenance delivers exactly what it promises, on the ten to twenty percent of assets where it belongs.

Final thoughts

The maturity ladder from reactive to preventive to predictive is real, but climbing it is not the goal. Matching each asset to the strategy that gives the best reliability for the least total cost is the goal, and for most assets that is not predictive. Where predictive does belong, the discipline that makes it work is unglamorous: understand the failure modes, verify a detectable warning exists, monitor faster than the P-F interval, integrate into the CMMS, and prove the reliability numbers move. Do that and the return follows. Skip it and you join the long list of organisations with impressive dashboards and unchanged failure rates.

If you are weighing a predictive maintenance investment, the most valuable thing you can do first costs nothing: analyse the failure history you already own and let it tell you where prediction would actually pay. The sensors, the models and the platforms are the easy part. Knowing which assets deserve them is the practitioner's judgement that makes the difference between a program that transforms reliability and one that just spends the budget.

Related reading: Preventive maintenance strategies (time vs meter vs condition), PM program design: quality over quantity, Asset criticality classification, Failure codes: Problem, Cause, Action, FM KPI framework, AI copilot for utilities CMMS.