The characteristic failure of a maintainability prediction is that it is optimistic, internally consistent and never checked, and it stays that way until the first demonstration.
| Pitfall | What it looks like | The guard |
|---|---|---|
| The unweighted average | Seven task times averaged, no failure rates in sight | Mct = Σλt ÷ Σλ; the rates come from the reliability prediction |
| Only the mean reported | One MTTR number, no percentile | Both, with the percentile's confidence level named |
| The total estimated directly | "About an hour" written in one cell | Seven activities estimated separately; a total is a guess, seven parts are an argument |
| No maintenance concept | Times that assume a workshop, on a system maintained on a mast | Level of repair, who, where and what counts as complete, all recorded first |
| Isolation time invented | A comfortable five minutes on an item in a three-way ambiguity group | Isolation from the testability model, including the swap-and-retry the group implies |
| Access assumed | Disassembly timed as though nothing is in the way | Timed against the actual layout, or flagged as an assumption pending one |
| The ideal technician | Trained, equipped, unhurried, in daylight, first attempt | State the assumption; the demonstration will price it |
| Mct quoted as downtime | A 1-hour MTTR presented as one hour of lost service | MDT adds logistics and administration and is usually the larger number |
| Preventive work folded in | Corrective and scheduled tasks averaged together | Separate lists, separate means, combined only with their frequencies |
| Procedures mixed across a system | One subsystem apportioned, another synthesised, results added | One procedure per prediction, named in the report |
| No demonstration planned | A prediction that is never compared with a measurement | MIL-STD-471 sample designed while the prediction is being written |
| The library never corrected | The same task-time library after three demonstrations | Feed measured times back; the library is the asset, not the report |
| Sold as an availability fix | MTTR halved to rescue an availability requirement | Check the arithmetic first: on a long-MTBF system it moves the fifth decimal |
Two of these deserve a closing sentence each. Inventing the isolation time is the one that makes two analyses disagree silently: the testability report says a three-way ambiguity group costs two removals to find one fault, and the maintainability report quietly assumes the technician goes straight to the failed item. Both numbers then appear in the same document set, and the one that is wrong is the one the maintenance plan was built on.
And the prediction that is never demonstrated is the norm rather than the exception. Every task time is a judgement about hardware that does not exist, and the only thing that converts the set of judgements into a capability is measuring a sample and correcting the library. A programme that predicts twice and never measures has an estimate that is exactly as good as its first guess, arrived at more expensively.