Preventive Maintenance Interval Planner
Compare a current and proposed PM interval on total annual cost, PM visits plus failure cost, not failure count alone.
Sensitivity to PM cost per visit
| Scenario | Current total | Proposed total | Policy |
|---|---|---|---|
| PM cost -20% | $28,248.89 | $11,146.67 | Adopt proposed interval |
| PM cost -10% | $28,330 | $11,390 | Adopt proposed interval |
| Base case | $28,411.11 | $11,633.33 | Adopt proposed interval |
| PM cost +10% | $28,492.22 | $11,876.67 | Adopt proposed interval |
| PM cost +20% | $28,573.33 | $12,120 | Adopt proposed interval |
Continue Analysis
Based on your results, these related decisions are available.
Resources
How this works
A tighter PM interval means more scheduled visits, which cost money on their own, but usually fewer unscheduled failures, which cost downtime and repair. A looser interval is the opposite trade. Neither direction is automatically the right call, so this engine adds up both cost lines, current interval against proposed interval, and compares the totals rather than judging the change by failure count alone.
Fewer failures is not the same as lower cost. A much tighter interval can drive failures down while the added visit cost eats most or all of the savings, a real over-maintenance pattern this engine is built to surface rather than hide behind a reliability-improvement percentage that looks good on its own.
Assumptions
- Failure rate at each interval is a single point estimate, not a hazard-rate curve
- PM visit cost is constant regardless of how often visits happen
- Only two named intervals, current and proposed, are compared at a time
Limitations
- Does not solve for an optimal interval, only screens one proposed change
- Does not model Weibull or age-based failure distributions
- Does not account for PM-induced failures (maintenance that itself causes downtime)
Sources
PM and failure-cost tradeoff structure follows standard reliability-centered-maintenance cost framing, consistent with NIST Handbook 135, the same capital and cost-screening source used elsewhere on this platform.
Worked example
A 90-day PM interval runs 12 failures a year at $2,300 each in downtime and repair, for $27,600 in failure cost plus $811 in PM visits, a $28,411 total. Tightening to a 30-day interval cuts failures to 4 a year ($9,200) but roughly triples PM visits to $2,433, for an $11,633 total, a clear 59% win. Tightening much further, to 15 days, only takes failures from 12 to 10, since most of the achievable reliability gain is already captured by 30 days, while visit cost quintuples to $4,867. Net savings shrinks to about $544, just 1.9%, the over-maintenance case this engine is designed to catch.
Common use cases
- Deciding whether to shorten a PM schedule after a run of failures
- Checking whether a maintenance team's proposed interval change actually pays for itself
- Testing whether an existing PM program is over-maintaining a low-failure-cost asset
- Feeding a reliability-improvement figure into a larger reliability investment case
Frequently asked
- Why compare total annual cost instead of just failure count?
- A shorter PM interval reduces failures but increases maintenance labor and planned downtime; a longer interval does the opposite. Total annual cost is the only number that nets both sides against each other.
- What if the proposed interval only slightly reduces failure rate?
- A small reliability gain can still be worth it if failure cost (unplanned downtime) is high relative to the added maintenance cost; the comparison is dollar for dollar, not a percentage-improvement threshold.
- Does this account for the cost of the PM work itself?
- Yes, both the current and proposed interval's maintenance cost are counted, not just the downtime side, so a proposed interval that adds substantial labor cost has to earn that back in reduced failures.
- Can this replace a full reliability-centered maintenance program?
- No, it is a two-scenario cost comparison for one asset or asset class, not a criticality-ranked RCM program covering an entire facility.