The Mantua Group

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

Reliability Engineering

How Much Do You Need to Know?

The Reliability Engineer’s Toolbox, the Sniff Test, and the Discipline of Knowing Enough Plus One

The reliability engineer’s most consequential question, after several years in the role, is rarely a technical one. The question is whether the engineer knows enough. The discipline is broad, advancing, and impossible to master completely; the practitioner who waits to know everything before acting will never act, and the practitioner who acts on superficial knowledge will produce results that do not survive scrutiny. The middle position, knowing enough to do the work in front of you and to recognise when the result is wrong, is the position that produces effective long-term practice. This paper sets out the principles that govern this middle position: the journey framing for a career in reliability, the toolbox metaphor for skill acquisition, the sniff-test discipline that catches the meat-grinder error, the role of the mentor in developing judgement, the role of the professional network in addressing niche questions, and the generational responsibility for transmitting foundational knowledge to the engineers who follow. 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.

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.