Skip to content

Reliability Engineering in Practice

Chapter 29: Reliability Engineering in Practice — Project Management

Section titled “Chapter 29: Reliability Engineering in Practice — Project Management”

There is a persistent confusion in industry about what a reliability engineer actually does. A reliability engineer is not a vibration analyst, though they must understand vibration. They are not a maintenance planner, though they shape what gets planned. They are not a process engineer, though they must understand process impact. A reliability engineer is a systems thinker who connects diagnosis to strategy, translating machine-level evidence into plant-level decisions.

The core responsibilities break down into four domains:

Failure Analysis: Understanding why machines fail, not just that they failed. This means root cause analysis, failure mode mapping, and pattern recognition across fleets and time periods. A reliability engineer who sees the same bearing failure on the same pump model across three plants does not simply order three new bearings. They investigate whether it is a design deficiency, an installation error repeated across sites, or an operating condition that exceeds the bearing’s design envelope.

Maintenance Strategy: Determining the right maintenance approach for each asset. Not every machine deserves predictive maintenance. Not every machine should run to failure. The reliability engineer applies RCM (Reliability-Centered Maintenance) logic to assign the optimal strategy: condition-based, time-based, failure-finding, or run-to-failure.

Asset Management: The long view. Which assets should be replaced versus repaired? When does a machine’s increasing maintenance cost justify capital replacement? How do design modifications eliminate chronic failure modes? This is Track 3 thinking — not fixing the problem, but eliminating the problem.

Continuous Improvement: Measuring, trending, and improving. The reliability engineer owns the KPIs, identifies the gaps, and drives the improvement initiatives.

Where does RAPID AI fit? It amplifies the reliability engineer’s diagnostic capability by orders of magnitude. A skilled vibration analyst can review perhaps 30-50 machines per day, producing quality diagnoses for each. RAPID AI processes thousands of machines per hour, each with consistent, repeatable diagnostic logic. This does not replace the reliability engineer — it frees them from the diagnostic grind so they can focus on strategy, analysis, and improvement. The engineer stops being a data interpreter and becomes a decision maker.

Reliability programs fail when they try to do everything at once. They succeed when they follow a phased approach that builds capability incrementally and demonstrates value early.

The first phase is about understanding the current state. No changes. No new systems. Just a clear-eyed assessment of where things stand.

Equipment criticality ranking. Every rotating and reciprocating asset in the plant gets a criticality score using the matrix from Chapter 27. This is not a six-month study. It is a series of structured workshops with operations, maintenance, and engineering, producing a ranked list in 2-3 weeks. The top 20 critical assets become the initial focus.

Current maintenance strategy audit. For each of the top 20 assets, document the current maintenance approach. What preventive tasks are performed? At what intervals? What condition monitoring exists? What is the failure history from the CMMS? The goal is to identify gaps between what the asset needs and what it currently receives.

Sensor infrastructure audit. What instrumentation exists? Permanent vibration sensors? Temperature RTDs? Pressure transmitters? Online oil analysis? For each critical asset, map the available data streams. Identify gaps where additional sensors are needed for RAPID AI to function effectively.

Baseline data collection. Collect at least 30 days of operating data from all available sensors on critical assets. This becomes the reference baseline against which RAPID AI will detect deviations. Good baseline data, collected when the machine is known to be in acceptable condition, is essential for accurate diagnostics.

RAPID AI deployment and configuration. Install the system, configure Module 0 with machine train topology, import equipment data, connect sensor feeds, and set criticality factors. Run RAPID AI in parallel with existing practices — it produces diagnostics, but no one acts on them yet. This shadow period builds confidence and identifies calibration needs.

Deliverable: Criticality-ranked asset list, gap analysis, sensor upgrade plan, RAPID AI configured and producing shadow diagnostics.

With the assessment complete, Phase 2 builds the operational foundation.

RCM analysis for top 20 critical assets. For each critical asset, perform a structured RCM analysis: identify functions, functional failures, failure modes, failure effects, and failure consequences. Then assign the optimal maintenance task for each failure mode. RAPID AI’s diagnostic blocks map directly to RCM failure modes, making this analysis faster than traditional approaches.

Condition monitoring program establishment. Based on the RCM analysis and sensor audit, establish monitoring routes (for periodic monitoring) and configure alarm thresholds (for continuous monitoring). Define alert escalation procedures: who gets notified, at what severity, with what expected response time.

RAPID AI rule calibration. Compare RAPID AI’s shadow diagnostics from Phase 1 against known machine conditions and any failures that occurred during the baseline period. Calibrate severity thresholds, adjust for site-specific conditions (ambient temperature, typical loading patterns, foundation characteristics), and tune false-positive filters.

Maintenance task optimization. Using the RCM results, eliminate unnecessary preventive tasks (tasks that add cost without reducing risk) and add condition-based tasks driven by RAPID AI. A common finding: 20-30% of existing preventive tasks can be eliminated or extended in interval, while 10-15% of failure modes lack any proactive task.

Deliverable: RCM workbooks for top 20 assets, calibrated monitoring program, optimized maintenance task plans, RAPID AI producing live diagnostics with actions taken.

Phase 3 expands the program beyond the initial critical assets and begins measuring results.

Expand to all monitored assets. Roll RAPID AI coverage from 20 to all assets with condition monitoring capability. Apply the same RCM logic, calibration, and task optimization at scale. Prioritize by criticality — high-criticality assets first, medium-criticality next.

Track KPIs. Begin formal KPI tracking (see Section 29.5). Establish monthly reliability reviews with maintenance, operations, and engineering leadership. Report trend directions, not just absolute values.

Root cause analysis program. For every failure that occurs on a critical asset, conduct a formal root cause analysis using RAPID AI’s Module G (CDE — Causal Diagnostic Engine) output as a starting point. Module G provides the initiating fault, the cascade path, and the contributing factors. The reliability engineer adds organizational and human factors that Module G cannot see: training gaps, procedure deficiencies, design shortcomings.

Spare parts optimization. Apply Chapter 28’s condition-based sparing strategy to all monitored assets. Reduce insurance spares where RAPID AI provides adequate warning. Increase strategic spares for long-lead items identified by RCM analysis.

Deliverable: Full-scope reliability program, monthly KPI dashboards, root cause analysis reports, optimized spare inventory.

Phase 4 transitions from establishing a reliability program to sustaining and advancing it.

Design-out chronic failures (Track 3). Identify the top 10 chronic failure modes — those that repeat despite good diagnostics and timely intervention. These are candidates for design modification: upgraded materials, improved sealing arrangements, enhanced cooling, derating, or equipment replacement.

Cross-plant benchmarking. For organizations with multiple sites, compare reliability performance across plants. Identify best practices at one site and transfer them to others. RAPID AI’s standardized diagnostic framework makes cross-plant comparison meaningful.

Knowledge transfer and training. Ensure the reliability program is not dependent on one or two experts. Document procedures, train new analysts, build competency across the maintenance and engineering teams.

Continuous improvement cycle. Reliability is not a project. It is a permanent discipline. The cycle repeats: assess, plan, execute, measure, improve.

A turnaround (also called a shutdown, outage, or TAR) is a planned event where a plant or unit is taken offline for major maintenance, inspection, and repair work that cannot be performed while running. Turnarounds are the most expensive maintenance events a plant undertakes — costing $5-100 million and lasting 2-8 weeks.

Traditionally, turnaround scope is defined by time-based rules: inspect every heat exchanger every 4 years, overhaul every pump every 6 years, replace every catalyst bed every 3 years. This produces enormous work lists, many of which turn out to be unnecessary when the equipment is opened and found in good condition.

Industry data consistently shows that 30-50% of turnaround work orders find “no defect found” or “within acceptable limits” when the equipment is opened. This is wasted money — not just the direct cost of the unnecessary work, but the downtime extension that results from an oversized turnaround scope.

RAPID AI transforms turnaround planning by answering the question: “Which assets actually need intervention, based on their current condition?”

Pre-turnaround assessment (6-3 months before): RAPID AI provides a fleet-wide condition report for all assets in the turnaround scope. Each asset gets a condition-based recommendation:

  • Intervene: Condition data shows active degradation that will reach failure before the next turnaround window. Include in scope.
  • Inspect: Condition data shows early-stage degradation that may or may not progress. Include visual/NDE inspection in scope, but do not plan a full overhaul unless inspection confirms need.
  • Defer: Condition data shows no significant degradation. Remove from scope. Monitor through the next operating cycle.

Typical results: 20-40% of traditionally scoped work orders are deferred or downgraded from overhaul to inspection. This reduces turnaround duration by 15-25% and direct cost by 10-20%.

RAPID AI’s RCM workbook integrates directly with turnaround planning:

  1. Module F provides RUL estimates for each asset’s active failure modes
  2. RUL is compared against the next turnaround window (e.g., 18 months away)
  3. Assets with RUL < next turnaround window are flagged for inclusion
  4. The specific failure mode determines the work scope: bearing replacement, seal overhaul, rotor balancing, alignment correction
  5. Required spares are identified by failure mode and pre-ordered (Chapter 28)

This is a closed loop: diagnosis drives scope, scope drives work packages, work packages drive spares procurement, and execution feeds back into the diagnostic database for future calibration.

Diagnostics without action is academic exercise. The connection between RAPID AI’s diagnostic output and the plant’s work execution system (CMMS) is the bridge between knowing and doing.

RAPID AI integrates with standard CMMS platforms (SAP PM, IBM Maximo, Fiix, eMaint) through defined interfaces:

  • Automatic notification generation: When RAPID AI identifies a fault at actionable severity (Stage 2+), it generates a maintenance notification in the CMMS with: asset ID, fault description, severity, recommended action, estimated urgency (from RUL), and required spares.
  • Priority scoring: RAPID AI’s risk index maps to CMMS priority codes. A Stage 3 bearing defect on a critical pump (Risk Index = 0.85) maps to Priority 1 (emergency). A Stage 2 misalignment on a medium-criticality fan (Risk Index = 0.35) maps to Priority 3 (planned within 30 days).
  • Work order templates: Each RAPID AI failure mode links to a predefined work order template with: task steps, required skills, estimated labor hours, required parts, required tools, and safety permits.

The most critical and most often neglected element of CMMS integration is the feedback loop. When a work order is executed and closed:

  • Was the diagnosed fault confirmed? (Yes/No)
  • What was the actual condition found?
  • What work was actually performed?
  • Was the Root Cause Analysis consistent with RAPID AI’s assessment?

This feedback calibrates RAPID AI’s confidence scores. If Module C diagnosed “inner race bearing defect, Stage 2” and the maintenance technician confirms “inner race spalling, moderate” the confidence score for that diagnostic pathway increases. If the technician finds “no defect,” the pathway is reviewed for false-positive causes and thresholds are adjusted.

Over time, this feedback loop makes RAPID AI increasingly accurate for the specific machines, conditions, and operating practices of each plant.

What gets measured gets managed. A reliability program must track both leading indicators (predicting future performance) and lagging indicators (confirming past performance).

Leading indicators are the early warning system for the reliability program itself. If these degrade, problems are coming.

Percentage of critical assets under condition monitoring. Target: 100% of critical assets, 80% of high-criticality assets. If this number drops (sensors fail, routes are skipped), diagnostic coverage is lost.

P-F interval utilization. The P-F interval is the time between when a fault is first detectable (P) and when it causes functional failure (F). If RAPID AI detects a fault at 80% of the P-F interval remaining, there is ample time to plan and execute a repair. If detection occurs at 20% remaining, it is a scramble. Track the average detection point as a percentage of P-F interval. Target: >60%.

Diagnostic accuracy rate. Of all faults diagnosed by RAPID AI, what percentage were confirmed by maintenance findings? Target: >85%. Below 70% indicates calibration problems.

Mean Time to Diagnosis (MTTD). From the onset of a detectable fault to the issuance of a diagnostic report. For continuous monitoring with RAPID AI, this should be hours to days. For periodic monitoring, it depends on route frequency. Target: MTTD < 10% of P-F interval.

Spare parts service level. When a spare is needed, is it available? Target: >95% for critical assets, >90% for high-criticality. Track stockout events monthly.

Lagging indicators confirm that the program is delivering results.

MTBF trend. Mean Time Between Failures should be increasing for critical assets. If MTBF is flat or declining, the program is not preventing failures. Track by asset class (pumps, motors, compressors) and by criticality level.

Unplanned downtime hours. Total hours of unplanned production loss due to equipment failure. This is the single most important lagging indicator. Track monthly, trend quarterly. Target: year-over-year reduction of 15-25% in years 1-3.

Maintenance cost per unit of production. Total maintenance spend (labor, materials, contractors) divided by production output. This normalizes for production rate changes. Target: declining trend, not a specific number.

Safety incident rate. Equipment-related safety incidents (releases, fires, injuries). Target: zero. Any non-zero number triggers immediate investigation.

Emergency work order percentage. Percentage of total work orders classified as emergency or urgent. Target: <5%. A plant running 30% emergency work orders has no reliability program — it has a fire-fighting operation.

The technical implementation of a reliability program is the easy part. The hard part is changing the behavior and culture of an organization that has done maintenance a certain way for decades.

Expect resistance from every level:

Operators: “We’ve always run this pump until it vibrates so bad you can feel it from the control room. Now you want me to shut it down because a computer says there’s a problem? I can’t see or hear any problem.”

Maintenance technicians: “I’ve been fixing pumps for 25 years. I don’t need a computer to tell me what’s wrong. I can tell by the sound.” (Often true — but the computer can tell 6 months earlier and does not take vacations or call in sick.)

Maintenance planners: “You want me to change all our PM schedules based on a new system we’ve had for 3 months? What if it’s wrong?”

Management: “How much does this cost, and when do I see payback? Show me the numbers.”

Each concern is legitimate. Each requires a different response.

Start with one critical asset. Do not attempt plant-wide transformation. Pick one highly visible, historically problematic critical asset. Install monitoring, configure RAPID AI, and demonstrate value. When RAPID AI catches a developing fault 60 days before it would have caused an unplanned shutdown, that single event becomes the proof point.

Involve the skeptics. The most experienced maintenance technician who is most skeptical of the new system is your most important ally — once converted. Involve them in the calibration process. Ask them to verify RAPID AI’s diagnoses against their own assessment. When the system agrees with their expert judgment, they become advocates. When it disagrees, their feedback improves the system.

Provide role-specific training.

  • Operators: What the monitoring system watches, what alerts mean, what action to take (usually: report it, do not ignore it)
  • Maintenance technicians: How to interpret RAPID AI reports, how to confirm diagnoses during repair, how to provide feedback
  • Planners: How RAPID AI notifications map to work orders, how RUL affects scheduling
  • Engineers: How to use Module G for root cause analysis, how to track KPIs, how to identify design-out candidates
  • Management: How to read the monthly reliability dashboard, what the KPIs mean, what good looks like

Demonstrate quick wins. Within the first 30 days, RAPID AI should identify at least one actionable finding on the pilot asset. Within 90 days, it should demonstrate at least one avoided unplanned event. Document these wins in simple, concrete terms: “RAPID AI detected bearing degradation on Compressor K-101 45 days before projected failure. Planned replacement during scheduled maintenance window. Avoided estimated $340,000 unplanned shutdown.”

Be patient with the cultural shift. Moving from reactive to predictive maintenance is not a technology change — it is a cultural change. It takes 18-24 months for the new way of working to become “how we do things.” Support the change through that transition with consistent leadership attention, regular communication of results, and recognition of early adopters.

Every reliability program must justify its cost. The good news: the economics of condition-based maintenance are overwhelmingly favorable. The challenge is quantifying them credibly.

Total maintenance cost has three components:

Total_Cost = Preventive_Cost + Corrective_Cost + Consequential_Cost

Preventive cost: Planned maintenance activities performed on schedule regardless of condition. This includes time-based overhauls, oil changes, filter replacements, and inspections. Predictable and budgetable, but often excessive.

Corrective cost: Unplanned repairs after failure. Includes emergency labor (overtime, call-outs), expedited parts, and repair of secondary damage caused by the primary failure. Typically 3-5× the cost of the same repair performed on a planned basis.

Consequential cost: The production loss, safety consequences, and environmental impact resulting from the failure. This is the dominant cost for critical assets. A $2,000 bearing failure that causes a 72-hour unplanned shutdown of a unit producing $50,000/hour in margin costs $3,602,000 in total — the bearing is 0.06% of the total cost.

RAPID AI reduces costs in three ways:

  1. Reduced corrective cost. By detecting faults early (Track 1), repairs are planned rather than emergency. The same repair costs 60-80% less when planned.
  2. Reduced consequential cost. By predicting failure timing (Track 2), shutdowns are scheduled during convenient windows rather than forced by failure. Production losses are minimized or eliminated.
  3. Reduced excessive preventive cost. By providing condition evidence, unnecessary time-based maintenance is deferred or eliminated. Only machines that need maintenance receive it.
Annual_Benefit = Avoided_Downtime_Value + Avoided_Secondary_Damage + Reduced_Spare_Inventory +
Reduced_Preventive_Maintenance + Extended_Equipment_Life_Value
Annual_Cost = RAPID_AI_License + Sensor_Infrastructure_Amortization + Training + Program_Management
ROI = (Annual_Benefit - Annual_Cost) / Annual_Cost × 100%
Payback_Period = Annual_Cost / Annual_Benefit × 12 months

Case Study: Refinery Centrifugal Pump Fleet

Section titled “Case Study: Refinery Centrifugal Pump Fleet”

Scope: 20 centrifugal pumps in critical hydrocarbon service

Baseline (before RAPID AI):

  • Annual unplanned downtime: 840 hours across fleet
  • Downtime cost: $2,500/hour average (production loss + emergency repair premium)
  • Annual unplanned maintenance cost: $2,100,000
  • Annual planned maintenance cost: $450,000 (time-based overhauls)
  • Spare parts inventory: $380,000 (insurance stock)
  • Annual spare holding cost: $76,000

After RAPID AI (Year 2 results):

  • Annual unplanned downtime: 336 hours (60% reduction)
  • Annual unplanned maintenance cost: $840,000
  • Annual planned maintenance cost: $520,000 (increased, because work previously done as emergency is now planned — but at lower cost per event)
  • Spare parts inventory: $190,000 (50% reduction)
  • Annual spare holding cost: $38,000

Annual savings:

  • Unplanned maintenance reduction: $2,100,000 - $840,000 = $1,260,000
  • Planned maintenance increase: $520,000 - $450,000 = -$70,000 (this is a cost, not a savings)
  • Spare inventory holding reduction: $76,000 - $38,000 = $38,000
  • Secondary damage avoidance (estimated): $150,000
  • Total annual benefit: $1,378,000

Annual RAPID AI cost:

  • System license and support: $120,000
  • Additional sensors (amortized over 5 years): $40,000
  • Training and program management: $40,000
  • Total annual cost: $200,000

ROI: ($1,378,000 - $200,000) / $200,000 = 589% (approximately 6:1)

Payback period: $200,000 / $1,378,000 × 12 = 1.7 months

These numbers are representative of actual industrial results. The payback period for condition-based maintenance on critical assets is typically 2-6 months. The ROI compounds over time as the system’s diagnostic accuracy improves through feedback and as the reliability program matures through Phases 2-4.

The economic case is not the hard part. The hard part, as Section 29.6 discussed, is the human change required to realize these economics. But the numbers provide the justification to start, and the early wins provide the momentum to continue.

Reliability engineering is not a cost center. It is a profit multiplier. RAPID AI is the tool that makes the multiplication visible, measurable, and sustainable.


StandardRelevance to This Chapter
ISO 55000/55001 — Asset managementThe phased reliability program implementation (Assessment, Pilot, Expansion, Optimization) directly follows ISO 55000’s asset management system maturity development approach, with RAPID AI providing the technology enablement at each phase.
SAE JA1011/JA1012 — RCM evaluation criteriaThe reliability engineer’s role in maintenance strategy development implements SAE JA1011’s requirement for function-first, consequence-driven maintenance task selection as part of the broader reliability program.
ISO 14224 — Reliability and maintenance dataThe equipment criticality ranking and failure history analysis use ISO 14224-compliant data structures and classification methods for systematic reliability assessment.
ISO 17359 — General guidelines for condition monitoringThe condition monitoring program design follows ISO 17359’s guidelines for establishing monitoring scope, frequency, and technology selection based on equipment criticality and failure mode detectability.
VersionDateAuthorChanges
2.1.02026-03-17Rick DAdded standards alignment, living doc metadata, changelog
2.0.02026-03-17Rick DEnriched with production codebase content
1.0.02026-03-17Rick DInitial chapter creation