• Skip to primary navigation
  • Skip to main content
The Mantua Group

The Mantua Group

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

  • About Us
    • Meet Our Founder
    • Meet Our Team
    • Scientific Legacy – A Century of Innovation
  • Services
    • Availability Simulation
    • Reliability Centered Maintenance
    • Fault Tree Analysis
    • Reliability Engineering
    • Asset Management
    • Asset Reliability
    • Asset Management and Reliability Consulting
    • Root Cause Analysis
    • Reliability Program Assessment
    • Maintenance Planning, Scheduling Uplift and Assessment
    • FMEA/FMECA
    • Condition Monitoring Assessment
    • Vulnerability Assessment and Analysis
    • Weibull Analysis/Failure Data Analysis / Survival Analysis
    • Other Services
      • Transportation
      • Temporary Fencing
      • Photography
      • Carpet Cleaning
  • Software
    • Isograph Software
      • Availability Workbench
        • Accelerated Life Testing (ALT)
        • Availability Simulation
        • AWB’s Maximo Portal
        • AWB’s SAP Portal
        • RCMCost
        • Weibull Module
        • Process Reliability
        • AWB API
        • AWB Enterprise
      • Reliability Workbench
        • Event Tree Analysis Software
        • Fault Tree Analysis (FTA)
        • FMEA – FMECA
        • Markov Analysis
        • Reliability Block Diagrams (RBD)
        • Reliability Growth Modeling
        • Reliability Prediction
        • RWB Weibull Module
        • RWB – System Safety Analysis (SSA)
        • RWB API
        • RWB Enterprise
        • Reliability Parts Libraries
      • Network Availability Prediction (NAP)
      • Hazardous Operations Analysis – HAZOP
      • Attack Tree Software
      • Life Cycle Cost Software
      • Data Link Manager External Systems
    • PeakAvenue Software
      • eQMS Platform
      • FMEA Software
      • Quality Management Systems
      • System Function Analysis
      • Supply Chain Management
    • Sologic Software
      • Causelink® Software
      • Causelink® RCA Software & Training
  • Industries
    • Mining
    • Rail
    • Automotive
    • Medical Technology
    • Aerospace
    • Electronics
    • Manufacturing
    • IT Security
    • Networks
    • Food and Beverage
    • Agriculture
    • Pharmaceutical
    • Defense
    • Steel
    • Super Alloy
    • Rubber
    • Transportation
  • Utilities
  • Training
  • Resources
    • Insights & News
    • White Papers
    • Case Studies
    • Podcasts
  • Contact Us
  • Show Search
Hide Search

Reliability

Dealing with Data

Fitness for Purpose, Censoring, and the Discipline of Turning Reliability Data into Reliability Decisions

A reliability engineer who has worked in this field for any length of time has been handed a stack of data and asked to make sense of it. The stack is rarely fit for the question that motivates the engagement. The collection system was usually designed for a different purpose by people in a different function; the records are incomplete in ways that distort the underlying distribution, and the volume of data is sometimes large enough to disguise the absence of useful information. This paper sets out ten principles for working with reliability data well: starting from fitness for purpose, working through the structural problems of censoring and missing renewals, addressing the volume problem with reliability performance indexing, and ending with the most important and most neglected of the ten, talking to the people who collect the data so that the next dataset is better than the last one. The principles are drawn from a Speaking of Reliability conversation between Philip Sage and Fred Schenkelberg and have been translated here into a structured engineering doctrine in the TMG voice.

Cataloguing Failure Mechanisms

Why the Universal Catalogue of Acceleration Models is Elusive, and What to Do Instead

The reliability engineer is regularly asked the same question. Is there a catalogue of failure mechanisms and their acceleration models? The questioner is typically planning an accelerated life test, an ongoing reliability monitoring programme, or a regulatory submission, and would like to look up the relevant model and its parameters in a single authoritative source. The answer, after a century of reliability engineering practice, is that no such catalogue exists in a usable form. Existing resources, the OREDA and RAC databases, the IEEE Gold Book, the NPRD and NSWC compendia, the Rome Laboratory’s WARP project, and the Physics of Failure literature, provide partial coverage of either the models or the data, but not both, and not in combinations that allow plug-and-chug application to the practitioner’s specific situation. This paper sets out why the catalogue is elusive, what the existing resources actually offer, where the boundaries of legitimate use lie, and what the practitioner should do instead. The principles are drawn from a Speaking of Reliability conversation between Philip Sage and Fred Schenkelberg and have been translated here into a structured engineering doctrine in the TMG voice.

Setting Expectations

What Reliability Engineers Are Asked to Do, What They Are Hired to Do, and the Gap Between

Reliability engineering, as a profession, is unusual in the breadth of activities that can legitimately fall within its role. The same job title in two different organisations can mean root cause analysis with a microscope and no laboratory, or cross-functional leadership across design, finance, marketing, and supply chain. The asymmetry between what the job title says and what the role requires is a recurring source of organisational friction, hiring failures, and engineer dissatisfaction. This paper sets out eight principles for setting and managing reliability engineering expectations: recognising the limits of generic job descriptions, calibrating the role to the organisation’s reliability maturity, securing the cross-functional access the role requires, communicating about expectations as an ongoing discipline rather than a one-time conversation, evolving the role as the business evolves, and building mentorship and learning environments that allow newly anointed reliability engineers to find their feet. The principles are drawn from a Speaking of Reliability conversation between Philip Sage and Fred Schenkelberg and have been translated here into a structured engineering doctrine in the TMG voice.

Backward Blueprinting

Designing Reliability Plans by Working Backward from the Decision You’ll Need to Make

The reliability plan that begins with today’s tasks and works forward toward an undefined future state is the plan that produces the parallel information economy described elsewhere in TMG’s writing: the CMMS that contains everything except the data the organisation actually needs, the ERP whose blueprints are beautiful and whose data outputs are unusable, and the project life cycle that delivers a product that the warranty subsequently absorbs the cost of. The reliability plan that begins with the future-state decisions the organisation will need to make and works backward through the data, processes, and systems that must be in place to support those decisions is the plan that produces usable outcomes. The technique that distinguishes the two is what the source conversation calls backward blueprinting. This paper sets out the principle, the failure modes it is designed to prevent, the working questions that operationalise it, and the organisational disciplines required to apply it consistently across new product development, asset management software implementation, and operational reliability programmes.

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.

  • « Go to Previous Page
  • Page 1
  • Page 2
  • Page 3
  • Page 4
  • Page 5
  • Go to Next Page »

Software Expertise

Reliability Workbench (RWB)
Availability WorkBench (AWB)
Network Availability Prediction (NAP)
Sologic Root Cause Analysis (RCA)
HAZOP

Terms & Policies

Terms of Service
Privacy Policy
Support Terms
Cookie Policy

Useful Links

FAQ
Training
Latest News
Support

Follow Us

  • LinkedIn

The Mantua Group

Copyright © 2026 The Mantua Group · Site Designed by The Red Checker · Log in