01 / UNDERSTAND
What is failure modes and effects analysis?
Failure modes and effects analysis, or FMEA, is a proactive method for examining how a process, product or service could fail. It connects each failure mode to its effect, possible causes and existing controls so a team can decide where action is needed. A failure mode describes what goes wrong; an effect describes what follows.
Traditional forms may rate severity, occurrence and detection, sometimes multiplying them into a risk priority number. Rating conventions need an explicit definition. Such numbers organise discussion; they are not measured probabilities or a universal rule for deciding which failure matters most.
Why use Failure Modes and Effects Analysis (FMEA)?
A service can appear coherent in its intended flow while leaving consequential failures unowned. Looking at failure mechanisms exposes the difference between a reassuring message and a delivery system that can honour it. FMEA helps teams act before implementation or as they review an existing process. It complements user research and operational evidence rather than replacing either.
When to use it
USE IT WHEN
A proposed process has several handoffs or consequential failure conditions.
A team needs to review prevention, detection and recovery before launch.
Repeated incidents suggest that current controls are incomplete.
When to choose another method
Use Service Blueprint to understand the delivery process first.
Use Usability Testing for direct evidence of interaction problems.
Use Research Plan when the likely causes are still unsupported assumptions.
What you’ll need
Define the scope and process boundaries. Include people who perform the work and people who understand its consequences. Bring incident evidence, process knowledge and known control limitations. Agree how ratings, if used, will be interpreted. Name a route for escalating severe consequences independently of a composite score, and assign ownership of proposed actions.
What a failure analysis records
Keep the elements that help answer your question and support a decision.
The bounded activity being examined.
How the intended activity can fail.
Consequences for people and subsequent work.
A mechanism or condition that could produce failure.
Prevention, detection and recovery already present.
An owner, intervention and way to check its effect.
02 / PUT IT INTO PRACTICE
How to run a service FMEA
Keep evidence and assumptions distinct. Revisit your work when new information changes your understanding.
01
Bound the process
Choose a scope small enough to examine meaningful failure mechanisms.
Review appointment changes from request to confirmed delivery.
02
Map the work
Make the intended handoffs and responsibility visible.
Identify when scheduling and contractor records diverge.
03
Name failure modes
Describe a specific failure without jumping straight to a solution.
A changed visit remains in the contractor’s old schedule.
04
Trace effects and causes
Keep consequences separate from possible mechanisms and mark uncertainty.
A resident waits for a visit that no one plans to attend.
05
Review controls
Check what prevents, detects and recovers from the failure.
A mismatch alert may detect a problem without assigning recovery.
06
Prioritise action
Use consequence and control gaps, retaining severe cases outside score shortcuts.
An unowned recovery deserves review even when its frequency is uncertain.
07
Verify the intervention
Assign an owner and test the changed process, including exception cases.
Reconcile schedules and confirm who contacts an affected resident.
Example: an appointment change that never reaches the contractor
Fictional scenario: a resident changes a repair appointment. The booking record updates, but the contractor’s schedule retains the old time. The failure mode is the inconsistent schedule; the effect is a missed visit and wasted waiting. A possible cause is an incomplete update handoff. No incident frequency is claimed.
The team records an existing mismatch alert, then finds that nobody is clearly responsible for contacting the resident or resolving the disagreement. It proposes reconciliation with explicit recovery ownership and verifies the exception path.
The visual separates failure, consequence, control gap and action. Detection is not recovery. The example uses qualitative consequence and control descriptions rather than inventing a numerical risk ranking.
03 / BELOW THE SURFACE
Below the surface: a detected failure can still have no route to recovery
A control may expose a problem without reducing its consequence.
MECHANISM
What exactly fails and why might it happen?
Separate failure, cause and effect.
RESPONSE
Who can act after detection, and how soon?
Verify recovery ownership.
PRIORITY
Which consequence remains serious despite an uncertain score?
Keep severity visible.
A team might rate detection as strong because a monitoring system raises an alert. Yet an alert arriving after the resident has waited, or one with no owner authorised to intervene, offers little practical protection. The detection score can look reassuring while the service consequence remains unchanged.
Record detection timing, responsibility and the action it enables. A visible failure needs a viable response. Ask whether prevention, timely detection or recovery would meaningfully change the effect, and verify the chosen mechanism under exception conditions.
This is an editorial interpretation check for service use of FMEA. It does not prescribe a new rating scale. Where severity is high, do not let a low occurrence estimate or a composite score make the case disappear. Preserve the consequence and use the organisation’s appropriate escalation process.
Failure Modes and Effects Analysis (FMEA) companion worksheet
The original companion records process step, failure, effect, cause, controls and action. Its review page examines response timing, responsibility and verification. It is a qualitative planning companion, not a standards compliant FMEA form or a prescribed rating scale.
Practical tips
Describe one failure mechanism per entry.
Keep uncertain causes labelled.
Verify that a control enables a useful response.
Common mistakes
Combining failure, cause and effect into one vague statement.
Treating a composite score as a measured probability.
Assuming that an alert resolves the service consequence.
What you’ll get
A clear failure mechanism, its consequences and a credible action to reduce them. Verify prevention or recovery in the actual process, then update the analysis as evidence and controls change.