All outcomes
Skills

Technical Risk Assessment (FMEA)

6 weeks · 0 milestones

Conduct a Failure Mode and Effects Analysis (FMEA) for a real engineering system, product, or process. The FMEA must cover: a scope definition specifying the system boundary, the failure modes being analysed, and the applicable life phase (design, manufacturing, or operation), a complete FMEA worksheet with at least 15 failure modes — each with failure mode description, failure effect (on the immediate function and on the end user), severity rating (1–10 scale with documented criteria), occurrence rating (1–10 with documented frequency basis), detection rating (1–10 with documented detection method), Risk Priority Number (RPN = S × O × D), and recommended corrective action for all failure modes with RPN above the threshold, a Pareto analysis of the top 20% of failure modes by RPN demonstrating where corrective action should be prioritised, and a recommended detection method for the highest-RPN failure mode that does not currently have an adequate detection mechanism. Preferred proof: an FMEA conducted as part of a real engineering design or quality review. Accessible alternative: FMEA of a real product or system using publicly available technical documentation — product manuals, service bulletins, and failure databases (FAA Service Difficulty Reporting System, CPSC recall database, FDA MAUDE database) are free public sources that provide real failure mode data. Proof artifacts: the FMEA worksheet (analysis artifact) and the Pareto analysis with corrective action recommendations (documentation artifact). Verification: an engineering manager or quality engineer reviews the detection ratings — 'this failure mode has a detection rating of 9 (almost undetectable); what specific test or monitoring method would bring that to 4 or below?' — requiring you to propose a specific, feasible detection mechanism.

Milestone map

Milestone map

3 milestones

Identify Hazards and Define the Risk Assessment Scope

1–2 weeks (3–4 hrs/week)

Select a real or realistic engineering system or project for technical risk assessment: a manufacturing facility, a construction project, an infrastructure asset, a chemical process, a software system, or an engineering design. Define the scope: what is being assessed, the system boundary, the hazard categories in scope (safety, environmental, financial, schedule, reputational, or combination), and the risk assessment method to be used (FMEA, HAZOP, Bow-Tie, quantitative risk assessment, project risk register, or equivalent). Identify ≥10 hazards using structured elicitation — brainstorming, checklist, SWIFT (Structured What-If Technique), or equivalent — and document each hazard with its source, potential consequence category, and the element of the system it affects.

Proof required

Submit your hazard identification record (≥10 hazards identified using a named structured method, each with source, consequence category, and system element affected) and scope document (system boundary, hazard categories in scope, and risk assessment method selected).

What gets checked

  • Hazard identification uses a named structured method — FMEA, SWIFT, HAZOP, or brainstorming checklist — not an unstructured list
  • ≥10 hazards are identified across ≥3 different consequence categories — not all the same type of hazard
  • System boundary is defined — what elements are included and excluded from the assessment

Common mistakes

  • Hazard identification that lists causes rather than hazards — a hazard is a potential source of harm; a cause is what activates it; confusing the two produces a list of control measures instead of risks
  • All hazards in the same consequence category — a risk assessment that only identifies one type of risk misses the cross-category hazards that often cause the most damage

Resources

Foundationstart here

Depthgo deeper

What a verifier looks for

  • Confirm hazard identification uses a named structured method — flag unstructured lists.
  • Confirm ≥10 hazards span ≥3 consequence categories — flag single-category hazard lists.
  • Confirm system boundary is defined with inclusions and exclusions stated.

Assess Likelihood and Consequence, Build Risk Register

2–3 weeks (3–4 hrs/week)

For each hazard from M1, assess likelihood and consequence severity using a defined scale (e.g. 1–5 probability × 1–5 severity, or the system-specific scale from the chosen assessment method). Calculate the risk rating (likelihood × severity) and plot the risks on a risk matrix. Identify the top 5 highest-rated risks and for each: describe the existing controls in place, assess the residual risk after controls, and determine whether the residual risk is tolerable (ALARP principle for safety risks, or equivalent). A risk register without existing controls is an incomplete assessment — it shows the inherent risk but not the managed risk.

Proof required

Submit your risk register (all ≥10 hazards with likelihood, severity, risk rating, existing controls, and residual risk rating) and a risk matrix showing all risks plotted, with the top 5 highest risks highlighted and their residual risk after controls assessed.

What gets checked

  • Risk register includes both inherent risk rating AND residual risk rating after existing controls — not just one of the two
  • Likelihood and severity scales are defined and applied consistently — not applied differently to different hazards
  • Top 5 highest risks are specifically identified with their existing controls documented

Common mistakes

  • Risk register without residual risk — documenting the inherent risk without assessing existing controls is a hazard list, not a risk assessment; controls must be identified and their effect on risk rating must be assessed
  • Inconsistent scale application — applying 'likelihood = 3 (likely)' differently to two similar hazards undermines the comparative validity of the risk matrix

Resources

Foundationstart here

Depthgo deeper

What a verifier looks for

  • Confirm risk register includes both inherent and residual risk ratings — flag any register missing controls or residual assessment.
  • Confirm likelihood and severity scale is defined and applied consistently across all hazards.
  • Confirm top 5 highest-rated risks are identified with their existing controls documented.

Write the Risk Assessment Report and Propose Treatment Actions

2–3 weeks (2–3 hrs/week)

Write a complete technical risk assessment report (2,000–3,000 words plus risk register appendix) covering: scope and method, hazard identification process, risk rating results, risk matrix, residual risk assessment, and treatment recommendations for the top 5 unacceptable or amber/red risks. Each treatment recommendation names a specific action, the responsible party, a target completion date, and the expected residual risk after treatment. Have the report reviewed by an engineer with risk assessment experience and respond to Q&A on the hazard identification completeness and treatment recommendations.

Proof required

Submit your risk assessment report (2,000–3,000 words plus risk register) and review record: reviewer name, role, ≥3 challenge questions about hazard completeness or treatment recommendations, and your responses.

What gets checked

  • Treatment recommendations name a specific action, responsible party, and target date — not just 'reduce risk'
  • Expected residual risk after treatment is estimated for each top-5 risk — not assumed to become acceptable without evidence
  • Reviewer has risk assessment, health and safety, or project management experience and challenged the hazard completeness or treatment specificity

Common mistakes

  • Treatment recommendations that list 'monitor the risk' without a specific action — monitoring is not a risk treatment; it is a risk escalation mechanism; each unacceptable risk must have a concrete action to reduce likelihood or consequence
  • Expected residual risk estimated without a rationale — 'after treatment, this risk becomes low' requires an explanation of which control reduces likelihood or consequence and by how much

Resources

Foundationstart here

What a verifier looks for

  • Engineering Design Triad check: M1–M3 together produce a design artifact (risk treatment recommendations with owners and dates), an analysis artifact (risk register with inherent and residual ratings + risk matrix), and a documentation artifact (risk assessment report + review record) — confirm all three types are present.
  • Confirm treatment recommendations name a specific action, responsible party, and target date — flag vague 'monitor' recommendations.
  • Confirm expected residual risk after treatment has a rationale for each top-5 risk.
  • Confirm reviewer has risk assessment or engineering experience and challenged hazard completeness or treatment specificity.
  • The Proof Accessibility Rule applies — ISO 31000 free overview, HSE free guidance, APM free resources, IRM free materials, and draw.io (free) are all accessible without commercial licence.

We use analytics to improve Powstik. No ads, ever.