ASP Fellowship II common mistakes
ASP Fellowship II · Understand the traps and how to avoid them.
Treating risk as a single number and declaring a hazard 'acceptable' as soon as the computed index falls below a threshold, without documenting the acceptance rationale, the criteria source, or who holds the authority to accept.
Candidates memorize matrix arithmetic and MIL-STD-882-style index tables but never internalize that acceptance is a decision with an accountable owner, not an arithmetic outcome. The exam's scenario items reward the reasoning, and candidates default to the calculation they drilled.
What to do instead
For every risk-acceptance item, write four things before choosing: the severity and probability basis, the criterion being applied and its source, the residual risk after controls, and the named authority plus documentation trail. Practice phrasing acceptance as 'accepted by [role] against [criterion] with [residual risk]' so the habit transfers to scenario questions.
Listing hazard controls in the order they come to mind instead of applying the preferred order of elimination, substitution, engineering controls, administrative controls, then PPE, and failing to justify why higher-order controls were rejected.
Candidates know the hierarchy exists but treat it as vocabulary rather than a decision rule. Under time pressure they pick the control that is easiest to describe, usually training or procedure, which is exactly the distractor the exam builds.
What to do instead
For each hazard, draft at least one candidate control at each hierarchy level, then state explicitly why each higher level is infeasible before settling lower. If your answer lands on training or PPE, the explanation must say what engineering option was evaluated and why it was not selected.
Confusing hazard, mishap, risk, and failure in definitions and in causal chains, so a question asking for a hazard ends up answered with an event, or a root cause is given as the consequence.
Everyday language blends these terms, and candidates read quickly past the distinction. The exam deliberately uses scenarios where the same sentence contains a condition, an event, and an outcome.
What to do instead
Drill the canonical definitions until automatic: hazard is a potential condition, mishap is the realized event with harm, risk is the combination of severity and likelihood, failure is loss of function. Before answering, label each noun in the stem as condition, event, or outcome, then answer the label the question actually asks for.
Stopping causal analysis at the immediate technical failure or the last person in the chain, producing a single-line root cause that ignores organizational, supervisory, and design influences.
Candidates equate root cause with 'the thing that broke' or 'the operator who erred.' Investigative frameworks that separate proximate causes from contributing and systemic causes are less familiar, so the analysis terminates early.
What to do instead
Use a structured method every time: build a timeline, then a causal map separating immediate technical, human, supervisory, and organizational factors, and classify each as cause, contributing factor, or finding. Require at least one organizational-level factor before declaring the analysis complete.
Writing human error as a conclusion ('operator failed to follow procedure') rather than analyzing the error type, its mechanisms, and the performance-shaping conditions that made it likely.
Candidates lack fluency with error classification schemes and human reliability methods, so they default to blame framing. The exam tests whether the candidate can distinguish slips, lapses, mistakes, and violations and connect them to design and task factors.
What to do instead
For any human error item, classify the error, identify the psychological mechanism, list at least three performance-shaping factors (workload, interface design, time pressure, training, fatigue, procedures), and propose a design-level fix. Practice converting 'operator error' into a statement about the task and interface that produced it.
Treating software as exempt from system safety analysis, or claiming software 'cannot fail' because it does not wear out, and therefore omitting software from hazard analysis and risk assessment.
Candidates carry a hardware intuition in which failure means physical degradation. Software failures are specification, requirement, and design defects, which do not map onto failure-rate thinking, so the analysis is skipped.
What to do instead
In every system-level hazard analysis, explicitly trace hazards to software functions and identify the software safety requirements derived from them. Frame software failure as incorrect output or behavior arising from requirements, design, or implementation defects, and require verification evidence for each software safety requirement.
Producing a safety program plan that lists activities without owners, schedules, deliverables, review gates, or interfaces to other program functions, and without tailoring to the specific system's risk profile.
Candidates write plans as generic outlines copied from templates. They miss that the exam scores planning as a management artifact with accountable roles, milestones, and tailoring rationale.
What to do instead
Structure every plan answer around who, what, when, and evidence: task, responsible role, milestone or phase gate, output artifact, and acceptance criterion. Add an explicit tailoring section stating which standard tasks were modified or omitted and why, tied to the system's hazard profile.
Citing a standard by number as the justification for an answer without stating what the standard actually requires or how it applies to the scenario.
Candidates memorize standard identifiers and clause numbers as shortcuts and assume naming the document earns credit. Scenario questions require application, and the identifier alone demonstrates recall, not competence.
What to do instead
For each standard you rely on, be able to state in one sentence what it mandates, its scope and applicability, and one limit or exception. In answers, lead with the requirement and its application, then cite the standard as support rather than as the argument.
Assuming a hazard is closed once a control is implemented, without verifying effectiveness, tracking residual risk, or checking for new hazards introduced by the control itself.
Candidates treat hazard tracking as a checklist to be cleared. The exam tests lifecycle thinking: controls create new failure modes, and closure requires evidence and re-assessment.
What to do instead
For each hazard closure, state the verification evidence, the residual risk after the control, and any new hazards the control introduces. Maintain the hazard log as a living record with status, owner, verification reference, and re-assessment trigger, and mention the feedback loop explicitly in tracking questions.
Answering design, operations, and maintenance questions with generic good practice instead of addressing the specific lifecycle phase, the maintenance-induced hazards, and the configuration control needed to keep safety assumptions valid.
Candidates blur the phases and give the same answer regardless of whether the question concerns design, operation, or maintenance. They also overlook that maintenance actions themselves introduce hazards and configuration drift.
What to do instead
Identify the lifecycle phase in the stem before answering, then apply phase-specific tools: design hazard analysis and safety requirements for design, operating procedures and training for operations, task-based hazard analysis and lockout/tagout for maintenance. Always address configuration control and how changes re-enter the hazard analysis process.