MoR Foundation common mistakes
MoR Foundation · Understand the traps and how to avoid them.
Treating MoR as a project-level risk log technique and answering questions as if it only applies to a single project, missing that MoR is a scalable framework of principles, approach, process and embedded practices usable at strategic, programme and operational levels.
Candidates skim the introduction and map MoR onto familiar PMBOK-style risk registers from prior project experience, so they default to project vocabulary whenever a question mentions 'risk management'.
What to do instead
Before answering, classify the question's level (strategic, portfolio/programme, project, operational) and recall that MoR describes principles and an adaptable process rather than a fixed project procedure. Learn the framework's structure explicitly: principles, approach, process, embedding and review, perspectives, roles, health checks.
Reciting the principles as a memorised list without being able to apply them to a scenario, for example failing to identify which principle is being breached when an organisation creates a risk register but never assigns owners or reviews it.
Principles are short and feel easy, so candidates memorise labels and skip the meaning of each, then cannot match a described behaviour to the principle it violates.
What to do instead
For each principle write one sentence on what it demands in practice and one counter-example of a breach. Practise scenario questions by asking 'what behaviour is described, and which principle does it uphold or violate?' rather than recalling the list in order.
Confusing the 'approach' (how the organisation chooses to implement risk management: scope, objectives, tailoring, governance and alignment with other management frameworks) with the 'process' (the sequence of steps that produces risk outputs).
The words 'approach' and 'process' are used loosely in everyday speech, and the exam's terminology is precise, so candidates answer process questions with approach concepts and vice versa.
What to do instead
Build a two-column comparison: approach = decisions about scope, objectives, tailoring, integration and governance before the work begins; process = identify, assess, plan, implement, communicate and embed activities. Tag every practice question with which of the two it is really testing.
Getting the order and purpose of process steps wrong, for example jumping from identification straight to response planning without assessing probability and impact, or treating 'identify risks' and 'assess risks' as one step.
Candidates rely on a vague memory of a five-step cycle and answer by intuition about what 'feels' next, rather than knowing each step's inputs, outputs and exit criteria.
What to do instead
Learn the process as a sequence with a distinct output per step (risk identification produces a risk context and risk descriptions; assessment produces evaluated and prioritised risks; planning produces responses; implementation produces actions and owners). For sequencing questions, ask what output the next step needs as input.
Treating embedding as a one-off launch activity (a workshop, a policy document, a training session) instead of recognising embedding as sustained integration into decision-making, culture, performance management and review cycles.
Candidates conflate 'implementing' with 'embedding' and pick the option that describes a single visible event, which feels like decisive action in a scenario.
What to do instead
Memorise the distinction: implementation puts the process in place; embedding makes it stick through leadership behaviour, incentives, integration with other frameworks and regular review. In scenario questions, reject options that are one-off events and prefer options describing ongoing reinforcement and review.
Ignoring risk perspectives and answering every question from a single generic viewpoint, so questions asking how a strategic, programme or operational perspective changes the treatment of a risk are answered with the same response.
Perspectives are often studied last and briefly, so candidates lack the habit of asking 'from whose viewpoint, and at what level, is this risk being considered?'
What to do instead
For each perspective, note what it emphasises (for example strategic: alignment to objectives and external context; operational: day-to-day delivery and controls; programme/project: delivery uncertainty). Practise re-describing the same risk from three perspectives and note how the owner, timeframe and response differ.
Misassigning roles, for example naming the risk owner as the person who performs the mitigating action, or confusing risk owner, action owner, risk manager and the governing body's accountability.
In real organisations these roles blur, and candidates answer from workplace habit rather than from the framework's defined accountabilities.
What to do instead
Learn each role by its accountability, not its activity: the risk owner is accountable for managing the risk overall and for its response, while action owners deliver specific tasks. The governing body provides direction and oversight. For each scenario, ask 'who is accountable if this risk materialises?' to identify the owner.
Treating a risk health check as a pass/fail audit or a compliance tick-box, and failing to recognise that health checks and maturity models are diagnostic and developmental, producing findings that feed improvement.
Candidates associate 'check' with audit and 'maturity' with a score to be maximised, so they choose answers that describe grading or blaming rather than diagnosing and improving.
What to do instead
Frame health checks as structured assessments of whether risk management is working in practice, and maturity models as staged descriptions of capability used to plan improvement. In questions, prefer answers that describe evidence gathering, findings and improvement actions over answers that describe scoring, ranking or punishment.
Choosing tooling answers that assume a sophisticated software platform is required, or that a risk register alone constitutes a risk management framework, ignoring that tools must fit the approach and maturity of the organisation.
Vendors and workplace practice emphasise systems, so candidates equate tooling with software and overlook simple tools (workshops, checklists, registers, reporting formats) suited to lower maturity.
What to do instead
Learn tooling as a spectrum matched to purpose and maturity: simple tools for early maturity, integrated systems for higher maturity. When a question describes a low-maturity organisation, prefer proportionate, low-cost tools; when it describes complex, multi-level risk, prefer integrated reporting and analysis tools.
Answering definitional questions with loose everyday language, for example defining risk as 'anything bad that might happen' rather than as uncertainty of outcome that matters to objectives, and so failing questions that test whether risk includes opportunity as well as threat.
Everyday usage frames risk as pure downside, and candidates carry that framing into an exam that treats risk as uncertainty affecting objectives, including potential upside.
What to do instead
Learn the framework's definitions word for word and test yourself on the implications: if risk is uncertainty of outcome relative to objectives, then opportunities are risks too, and responses can exploit as well as avoid. On any definitional question, check whether the option keeps the link to objectives and to both threat and opportunity.