Engineering changes are always a trade-off that adds good behavior at the expense of some bad behavior. The question is, does the good outweight the bad?
For example, the following table identifies a few common metrics and their possible undesirable impacts:
Change | Improves | Potential Impacts |
| Additional Testing | FD / FI | Diagnostic or Maintenance Time |
| Serial Replacement | Fault Group Size | Maintenance Time |
| Add Redundancy | Safety, Critical Behavior | FD/FI, Maintenance, Reliability |
| Add Sensors | FD / FI, Maintenance | Reliability, Maintenance |
| Preventative Maintenance | Reliability, Availability | Support Cost, Maintenance |
Of course, some changes are far more complex. Repartioning, for example, can have any number of good and bad consequences. Often, it is highly efficient to repartition for diagnostic purposes (better detection, isolation, etc.) However, what happens to maintenance? By the same token, the partioning could be done specifically to improve maintenance. But then how is diagnostics changing to accomodate it?
Problems such as these are what some System Engineers live for, and they are also what can make and break a process or tool, and ultimately the entire project. Today, Prognostics often opens Pandora's box for these same reasons.
Prognostics can be used to extend useful life, but that can mean sacrificing reliability. It can also improve reliability through advanced warning, but that can mean losing some availability. Determining the overall benefit of these opposing factors is what triggers most engineers to start thinking about risk. The degree of accuracy to which these factors can be determined is real hurdle in assessing the true risk of producing a supportable design that meets requirements.