The Mantua Group

Simple Black and White Asset Management, Reliability Expertise, and Maintenance Execution Perfection.

Reliability Engineering

So, You Have an Environmental Test Chamber. So What?

Aligning Test Methodology with Failure Modes, Service Environments, and the Decisions the Tests are Meant to Inform

Environmental test chambers are among the most visible capital investments in a reliability laboratory. They occupy floor space, draw power, and confer a tangible sense of analytical readiness on their owners. The persistent failure mode in their use is not technical. It is cognitive. The presence of a chamber subtly biases the test programme toward the questions the chamber can answer rather than the questions the product’s service environment actually poses.

Designing for Robustness

Beyond Quality Products That Tolerate the Variability, Abuse, and Unforeseen Stress of Real-World Use

Most reliability engineering literature and practice focus on two of the three failure domains a product encounters across its service life: the early-life domain, governed by quality control, and the wear-out domain, governed by reliability analysis. The third domain, the long flat middle of the bathtub curve, where the product is supposed to operate routinely for the bulk of its useful life, is governed by neither. It is governed by robustness: the engineered capacity of the product to absorb the variability, abuse, and unforeseen stress that the real-world operating environment will impose on it, beyond what the laboratory specification captures. This white paper sets out the engineering disciplines that produce robustness, the analytical frameworks that quantify it, and the business case that justifies the investment.

Quality Statistics, Reliability Statistics

Two Statistical Disciplines, Two Different Questions: How They Differ, How They Combine, and Why an Engineer Should Master Both

The two statistical traditions that reliability engineering inherits, the quality-statistics tradition descending from Shewhart and Deming and the reliability-statistics tradition descending from Weibull, Fisher, and the post-war life-testing community, are often spoken of as interchangeable extensions of a single discipline. They are not interchangeable. They were built for different questions, they make different assumptions about the data, they use different mathematics, and they support different decisions. An engineer comfortable in both moves fluently between the shop-floor control chart and the field-fleet survival analysis. An engineer who knows only one will, sooner or later, apply the wrong tradition to the wrong problem, and the analysis will produce results that are mathematically correct and engineering nonsense.

Competing Risks, Or Not?

Disciplined Failure-Mode Decomposition for Reliability Data Analysis: When the Risks Framework Applies, When it Misleads, and the Practical Questions That Tell the Difference

The decision to model failure mechanisms as competing risks or to treat them as independent processes requiring separate analyses is among the most consequential a reliability engineer makes. The choice cannot be settled by software, by professional habit, or by the convenience of an aggregated dataset. It can be settled only by a clear understanding of the physics of failure, the timing of risks exposure, and the empirical evidence that two or more mechanisms genuinely overlap on the timeline of an asset’s service life. This white paper sets out the discipline that distinguishes legitimate failure mode competing-risks modelling from analytically convenient over-aggregation, the framework that follows from each choice, and the practical questions a practitioner should pose before adopting either approach.

Asset Management Systems, Asset Performance

Why Certification Does Not Produce Excellence: How High-Performing Organisations Bridge the System-Performance Disconnect

The disconnect is real and widespread. An organisation that has invested in ISO 55000 certification, has populated its asset register, has documented its procedures, and has passed its third-party audit may, in the same calendar year, miss its uptime targets, exceed its maintenance budget, and report no measurable improvement in asset reliability. The organisation has a system. It does not, despite the system, have performance. The certifying body has not erred. The auditor has not erred. The system genuinely is what the certification claims it to be. The error, if there is one, lies in the conflation of the existence of a system with the production of an outcome.

The recognition is uncomfortable because it implicates years of organisational investment. The consultants engaged to support the certification, the internal staff who drafted the procedure library, the senior leaders who sponsored the programme, and the auditors who confirmed its compliance have all, in their respective ways, done what they were engaged to do. The standard has been met. The certificate has been issued. What has not happened in the operational data is the improvement that the organisation expected the certification to produce. The improvement was the goal; the certification, in the organisation’s working assumptions, was the path to it. The assumption was wrong, and the wrongness was structural rather than incidental.