M4.1 — Risk Identification & Assessment

M4.1 — Risk Identification & Assessment

1. Practical outcome

By the end of this section, the learner should be able to establish a disciplined risk-identification process that finds, frames and records uncertainty before it is scored or modelled. They should be able to distinguish risks from issues, assumptions, dependencies, decisions and actions; write clear cause–event–consequence statements; identify both threats and opportunities; use several complementary identification techniques; connect each material uncertainty to project objectives and control data; assign accountable ownership; recognise triggers and early-warning indicators; and create a risk record that is sufficiently clear and traceable for the next stage of analysis and response.

The objective is not to create the longest possible risk register. It is to make important uncertainty visible early enough that the project can understand it, act on it and learn from it. A risk register containing 200 vague statements is weaker than a smaller set of well-framed uncertainties that are connected to scope, schedule, cost, interfaces, assumptions and decisions.

M4.1 deliberately stops short of the probability-and-impact scoring taught in M4.2. M4.1 answers: What uncertainty exists? Why does it exist? What could happen? What would it affect? Who needs to own it? What evidence or trigger would tell us that the situation is changing? M4.2 then asks how significant those identified risks are relative to one another and how management attention should be prioritised.

A useful question throughout this Knowledge Area is: “If this uncertainty became important tomorrow, would the project already understand its cause, possible event, consequence, ownership, evidence and connection to the plan?”

2. Core concepts

Risk identification is a search for uncertainty, not a search for problems

Risk concerns how uncertainty can affect objectives. An uncertain event or condition is one useful expression of risk; variability, incomplete knowledge and connected effects also need attention. An event that has occurred is a fact or issue, but its future consequences may remain uncertain. Reflect known consequences in the plan and manage the remaining uncertainty explicitly.

This distinction protects the integrity of the risk process. If known problems are labelled as risks, teams can postpone decisions by repeatedly “monitoring” events that already require action. Conversely, if genuine future uncertainty is treated as an issue too early, the project may commit to one outcome before enough evidence exists.

A practical classification test is:

·       Risk — uncertainty that could affect objectives, including uncertain events, conditions and variability.

·       Issue — a condition or event that has already occurred or is now certain and requires management action.

·       Assumption — something treated as true for planning purposes even though evidence may be incomplete.

·       Dependency — an input, output, decision or deliverable on which another part of the project relies.

·       Action — work someone has agreed to perform; an action is not itself a risk.

·       Decision — a choice that must be made by an authorised party; delay or uncertainty around the decision may create a risk.

·       Opportunity — uncertainty that could improve an objective if deliberately exploited or enabled.

These categories can interact. An assumption can generate a risk if it may prove false. A dependency can create a risk if its delivery is uncertain. A risk becomes an issue when the uncertain event occurs. An issue can create new secondary risks. The practitioner therefore needs to understand relationships rather than force every observation into one label.

Good risk statements separate cause, event and consequence

A strong risk statement explains the chain of uncertainty. A useful structure is:

Because of [CAUSE / current condition], there is a possibility that [UNCERTAIN EVENT], which could result in [CONSEQUENCE TO OBJECTIVES].

The cause is normally something that exists now and helps explain why the event is possible. The event is the uncertain occurrence. The consequence is the effect on an objective if the event happens. Keeping these elements separate improves ownership, analysis and response planning because different responses may address the cause, reduce the likelihood of the event or reduce the consequence.

Compare the following statements:

·       Weak: “Risk of supplier delay.” This does not explain why delay is possible, what delivery is uncertain or what objective would be affected.

·       Better: “Because only two approved suppliers can manufacture the specialist equipment during the required window, there is a possibility that the selected supplier cannot meet the required delivery date, which could delay installation and reduce the time available for integrated testing before the fixed opening.”

·       Weak: “Risk that costs increase.” This is a consequence without a useful event or cause.

·       Better: “Because final room layouts remain incomplete, there is a possibility that equipment quantities and installation requirements increase after procurement, which could increase package cost and create rework.”

A cause–event–consequence structure should not become a grammar exercise. The test is whether a competent person can understand what is uncertain and use the statement to decide what evidence to seek and what action might be useful.

Threats and opportunities belong in the same uncertainty conversation

Risk management is often treated as a threat-only process. That can make the project blind to uncertainty that could improve schedule, cost, performance or benefits. Opportunities should therefore be identified deliberately rather than waiting for them to appear by chance.

For example, early acceptance of completed areas in the Community & Learning Centre could create an opportunity to begin configuration, training or operational readiness earlier than the full-building handover. The project should frame the opportunity with the same discipline used for threats: what condition makes it possible, what uncertain event could occur, what benefit would follow, and what action is required to increase the chance of realising it?

Risk identification starts from objectives and the control model

A risk only has meaning relative to an objective. The identification process should therefore begin with what the project is trying to achieve and how delivery is represented in the control system. Useful anchors include authorised scope, WBS, key milestones, schedule logic, cost baseline, procurement strategy, resource plan, quality/acceptance criteria, benefits, operational-readiness requirements and governance commitments.

Starting from objectives also reduces generic risk statements. “Supplier failure” becomes more useful when connected to the specific work package, required-by date, downstream milestone, cost exposure and available alternatives. The WBS and schedule provide places to look; the risk process adds uncertainty to those places.

Assumptions, dependencies and interfaces are major sources of risk

Many important risks are hidden inside statements that the project has quietly treated as facts. Examples include assumed approval durations, assumed productivity, assumed access dates, assumed supplier capacity, assumed design maturity, assumed resource availability or assumed client decisions. A disciplined identification process asks: What are we assuming? What evidence supports it? What happens if it is wrong? When will we know?

Dependencies and interfaces deserve similar attention because they often sit between organisational boundaries. A schedule may show that a utility connection, authority approval, supplier deliverable or client decision is needed, but the existence of a date does not make delivery certain. The practitioner should ask what must be true for the dependency to arrive as planned and who can influence that outcome.

Risk sources should be diverse because no single identification technique is complete

Workshops are useful, but workshops mainly reveal what the people in the room remember and feel able to say. A robust process combines facilitated discussion with evidence review. Different sources reveal different classes of uncertainty:

The aim is triangulation. A risk found independently through schedule logic, supplier evidence and lessons learned deserves different confidence from a risk raised only as a vague concern in a workshop.

Initial assessment in M4.1 is screening and framing, not scoring

The word assessment in M4.1 means deciding whether the uncertainty is valid, material enough to record, sufficiently well framed, connected to an objective, assigned to the right owner and ready for deeper analysis. It does not mean applying the probability-and-impact matrix; that is the explicit focus of M4.2.

Useful initial-assessment questions include: What is uncertain? Which objective or control element could be affected, including through an external dependency or cause outside the project’s control? Is it already represented elsewhere? Is it a duplicate symptom of a common cause? How soon could it matter? What evidence exists? What trigger would show movement? Who can manage the exposure or escalate it? Does it need specialist analysis or immediate action before the next formal risk review?

Ownership is accountability for understanding and managing exposure

The risk owner is accountable for ensuring the risk is understood, monitored and managed. The owner does not need to perform every response action personally. Action owners can be different people. Good ownership therefore depends on authority and influence, not simply proximity to the risk register.

Assigning every supplier risk to the project risk manager is poor practice. Assigning a procurement-capacity risk to the person accountable for the package, with specific response actions owned by procurement and technical leads, is more useful. Where a risk is largely controlled by an external party, the project still needs an internal owner accountable for the project’s exposure and response.

Triggers and early-warning indicators make risks observable

A trigger is evidence that changes the understanding or status of a risk. It may show that likelihood is increasing, that the event has occurred, that a response must start, or that the risk can be retired. Examples include a supplier missing a design-release date, an approval not being acknowledged within an agreed period, productivity remaining below a threshold for two consecutive weeks, or a key decision passing its latest safe date.

Triggers matter because “monitor the risk” is otherwise vague. A good risk record says what will be watched, where the evidence comes from, who watches it and what happens when the threshold is reached.

Common-cause and correlated risks should not be hidden by register structure

Several risk entries may be symptoms of the same underlying cause. For example, incomplete design can create procurement quantity uncertainty, installation rework, testing delay and commercial change. Recording four separate consequences without recognising the shared design-maturity cause can lead to duplicated responses and an exaggerated sense of independence.

The opposite problem also occurs: a single broad risk such as “design risk” may hide several materially different events with different owners and responses. The practitioner must choose a level of decomposition that supports action. Parent–child links or common-cause fields can help where multiple exposures genuinely share a source.

A risk register is a controlled data set, not the risk-management process

The register should preserve enough structured information to support analysis, response, reporting and audit. Typical fields include unique ID, date identified, source, status, WBS/control-account link, schedule milestone/activity link, cause, event, consequence, affected objective, threat/opportunity classification, owner, existing controls, trigger/indicator, evidence source, related assumption/dependency, related risks/issues, next review and closure rationale.

However, the presence of these fields does not prove that risk is being managed. Quality comes from the conversation, evidence, challenge and decisions behind the data. A perfectly formatted register with stale, generic entries is still poor control.

Digital tools and AI can support discovery, but accountable judgement remains human

Search, analytics and AI can help scan historical lessons, cluster similar risk statements, identify missing links, highlight overdue reviews or compare current project data with known patterns. They can widen the search space and reduce administrative effort. They should not silently invent risks, assign ownership or change risk status without accountable review. Generated suggestions should be treated as prompts requiring evidence, context and professional judgement.

3. Step-by-step method

1. Establish the purpose, boundary and timing of the identification exercise. Define whether the review covers the whole project, a programme interface, a work package, a phase, a procurement, a major change or a specific decision. State the time horizon and reporting cut-off so participants know what uncertainty is in scope.

2. Confirm the objectives and tolerances that matter. Review the outcomes the project is trying to protect or improve: scope, key dates, cost, quality, performance, safety, benefits, reputation, operational readiness or other authorised objectives. Use these objectives as the test for whether an uncertainty matters.

3. Assemble the current control evidence. Bring the WBS, schedule, milestone list, cost/estimate basis, assumptions, dependencies, procurement information, interface registers, technical status, changes, issues, lessons learned and relevant performance trends. Identification should be grounded in the current project model rather than memory alone.

4. Map the work and lifecycle to create a search structure. Review work packages, phases, major decisions, approvals, procurements, interfaces, testing and handover. Ask where uncertainty could enter, propagate or accumulate. Pay particular attention to hand-offs between organisations and disciplines.

5. Review assumptions, constraints and dependencies explicitly. For each material assumption ask what evidence supports it, when it will be confirmed and what happens if it proves false. For each dependency ask who controls it, the latest safe date, the quality required and what contingency exists.

6. Use more than one identification technique. Combine workshops/interviews with documentary review, checklists, prompt lists, lessons learned, schedule-path review, estimate challenge, interface analysis, site observations, scenario thinking and specialist input. Record the source of each candidate risk so traceability is retained.

7. Capture raw observations before forcing them into risk language. Allow participants to record concerns, opportunities, uncertain assumptions and weak signals in ordinary language. Premature editing can suppress useful information. Classification and refinement come next.

8. Classify the observation correctly. Decide whether it is a risk, issue, assumption, dependency, action, decision or opportunity. Move known issues to the issue/action process; keep assumptions and dependencies linked where they create genuine uncertainty.

9. Write the cause–event–consequence chain. State the current condition, the uncertain event and the possible effect on an objective. Avoid vague “risk of delay/cost increase” wording. Check that the event is truly uncertain and not merely a restatement of the consequence.

10. Identify both downside and upside pathways. Ask not only what could go wrong but what uncertainty could allow earlier completion, lower cost, higher performance or better use of resources. Opportunities normally require enabling action; do not record them as passive wish lists.

11. Test for duplicates, symptoms and common causes. Compare new entries with existing risks, issues and assumptions. Merge true duplicates, separate materially different events, and link related entries that share a parent cause. Preserve the level of detail needed for ownership and response.

12. Link the risk to the project control model. Attach the relevant WBS/CBS/control account, schedule activity or milestone, contract/package, requirement, interface, decision or assumption. The link should allow later analysis to show where exposure could affect the plan.

13. Identify existing controls and current evidence. Record what is already reducing or detecting the uncertainty, what evidence supports the concern, and what evidence is missing. Do not confuse a planned response with a control that is already operating.

14. Define observable triggers and time conditions. State what event, threshold or date would indicate that the risk is increasing, decreasing, materialising or becoming irrelevant. Include latest safe decision dates where they matter.

15. Assign an accountable risk owner and, where useful, separate action owners. Check that the owner has sufficient authority and influence to coordinate the response and escalate when necessary. Avoid assigning risks by administrative convenience.

16. Perform initial screening for relevance, proximity and readiness for analysis. Confirm that the risk is material enough to manage, that it affects a defined objective, and that it has enough clarity for M4.2 or specialist quantitative analysis. Escalate urgent exposures immediately rather than waiting for the next routine review.

17. Challenge completeness and bias. Ask what may have been missed because of optimism, familiarity, hierarchy, commercial sensitivity or group conformity. Invite independent challenge and voices from delivery, operations, suppliers and interfaces. Look for absence as well as presence: which major WBS areas or milestones have no uncertainty recorded, and is that credible?

18. Record, review and refresh the controlled risk position. Enter the agreed risk with its traceable data, preserve the identification date/source, confirm next review, and feed it into M4.2 qualitative analysis. Revisit identification when scope, schedule, commercial strategy, assumptions, interfaces or external conditions change; identification is continuous, not a one-off workshop.

4. Worked Reference Project example — Community & Learning Centre

Context — Month 9 integrated risk-identification review

The Community & Learning Centre is approaching a major procurement and delivery transition. The fixed public opening remains non-negotiable. The project team has an approved scope/baseline, key procurements are moving into commitment, detailed design is still maturing in several areas, and interfaces between building works, digital systems, fire-system acceptance, operational readiness and external utilities are becoming more important.

The project manager asks the controls team to run an integrated risk-identification review before the next governance checkpoint. The purpose is not yet to score risks. The purpose is to make the uncertainty explicit, improve the quality of the risk statements and ensure the subsequent M4.2 assessment is based on credible evidence.

Step A — define the search frame

The team uses the Level-1 WBS, key milestones and major interfaces as the primary search structure. They focus on the period from detailed design through procurement, delivery, testing, handover and opening. They also review assumptions that underpin the schedule and cost forecast. The fixed opening date is treated as an objective, not as proof that preceding dates will be achieved.

The workshop is supported by evidence from the schedule, procurement log, design-status report, current estimate/forecast, interface register, operational-readiness plan and lessons from two comparable projects. Representatives attend from design, construction, technology, procurement/commercial, operations, finance and project controls. The facilitator asks each discipline to bring at least one piece of evidence rather than only opinions.

Step B — turn raw observations into valid uncertainty

Several raw observations are raised:

·       “The specialist-equipment supplier is slow.”

·       “Eighteen rooms still do not have final technology layouts.”

·       “The eastern service route may contain an undocumented duct.”

·       “The fire authority sometimes asks for additional witness testing.”

·       “Operations only has two trainers available in the planned readiness window.”

·       “The library wing may be capable of staged acceptance before the rest of the building.”

·       “One room layout was rejected yesterday.”

The team does not simply copy these sentences into the register. The rejected room layout has already occurred, so it is treated as an issue requiring action and any resulting change assessed separately. The remaining observations are tested for uncertainty, evidence and objective impact.

Step C — construct cause–event–consequence statements

Notice that the entries do not contain probability or impact scores. The purpose of M4.1 is to create enough clarity and traceability that those assessments in M4.2 will mean something.

Step D — link risks to the control model

R-041 is linked to WBS 1.3 Furniture & Specialist Equipment, the supplier award and required-delivery milestones, and the installation/commissioning path. R-042 is linked to WBS 1.4 Digital & Technology Systems, the room-layout design packages, procurement-release decision and equipment quantity basis. R-044 is linked to the integrated-testing and operational-readiness milestones. These links allow the later risk review to use real schedule and cost evidence rather than treating the register as a separate document.

The team also records related assumptions. For example, the schedule assumes the fire authority will accept the planned witness-testing sequence. That assumption is linked to R-044 rather than left hidden in narrative notes. The technology estimate assumes quantities derived from the current room layouts; that assumption is linked to R-042.

Step E — identify common causes and avoid duplication

During challenge, the team finds three separate draft risks about late room layouts, equipment changes and installation rework. Rather than retain three near-duplicates, they recognise that incomplete room definition is the common cause. R-042 is written broadly enough to capture the uncertain quantity/design event and its cost/schedule effects, while specific response actions can address design freeze, procurement flexibility and installation sequencing.

By contrast, supplier capacity and fire-authority testing remain separate risks because they have different causes, owners, evidence and response options even though both could affect the opening date.

Step F — define triggers and ownership

For R-041, the owner agrees that a confirmed manufacturing slot is the key near-term evidence. If the slot is not confirmed by the procurement milestone, the escalation action is to seek executive supplier commitment and assess alternative/staged supply. For R-044, acceptance of the integrated-test plan is the trigger. If the authority requests additional witness points, the risk may increase or partially materialise and the schedule forecast must be updated accordingly.

This turns “monitor supplier risk” and “monitor approvals” into observable control. Each risk now has a person accountable for the project exposure and evidence that can change the assessment.

Step G — decide what moves forward to M4.2

The review ends with six new or materially revised uncertainties, one issue transferred to the issue/action process, two duplicate statements merged into R-042 and one minor local concern retained at work-package level rather than escalated to the project register. All six material entries have clear owners, control links, evidence and triggers. They are now ready for the qualitative probability/impact analysis in M4.2.

Management summary from M4.1:

The integrated review identified concentrated uncertainty around specialist-supplier capacity, remaining room-definition maturity, fire-system acceptance and operational-readiness capacity. These exposures are linked to the delivery paths and assumptions they could affect, with observable decision/trigger points in the next two reporting periods. One staged-access opportunity has also been identified that could protect readiness. The risks are now sufficiently framed for M4.2 prioritisation; supplier-slot confirmation and test-plan acceptance require near-term management attention regardless of final matrix score.

5. Interpretation and professional judgement

The quality of identification matters more than the number of entries

A rising risk count can mean the project is becoming more uncertain, but it can also mean identification is improving. A falling count can mean exposure is being retired, or it can mean the team has stopped looking. Counts therefore need interpretation. The useful question is whether the material uncertainties around objectives are visible, owned and actionable.

A register with many trivial entries can dilute management attention and make the serious risks harder to see. Equally, aggressive consolidation into a handful of “strategic risks” can remove the specific cause, timing and ownership required for action. The right level of decomposition is the level at which a different response, owner, trigger or decision would apply.

Risk identification must be psychologically safe enough to surface bad news

Teams identify fewer and weaker risks when people believe raising uncertainty will be treated as pessimism, poor performance or disloyalty. Senior leaders influence the quality of the register through the questions they ask. “Why is this red?” can create defensive scoring. “What are we assuming, what evidence could prove us wrong, and where would we see it first?” is more likely to surface useful uncertainty.

Commercial relationships can add another layer of sensitivity. A contractor may describe a condition differently from the client because contractual position matters. The project-controls practitioner should preserve neutral, evidence-based wording and separate the existence of project exposure from any conclusion about legal liability or entitlement.

The absence of identified risk is itself something to challenge

A complex work package with no recorded uncertainty deserves examination. It may genuinely be stable and well understood, but it may also have weak engagement, poor data or hidden assumptions. Risk-density heat maps by WBS or lifecycle can be useful prompts, but they are not proof that every area should contain the same number of risks.

Unknown unknowns cannot be registered, but the project can still design for uncertainty

Risk identification cannot list events nobody can yet imagine. The response is not to pretend the register is complete. Projects can use contingency, management reserve, schedule headroom, robust design, modularity, staged decisions, sensitivity analysis and scenario planning to create resilience against uncertainty that is not individually identified. M4.1 should therefore be understood as systematic search, not certainty about the future.

A risk can move between categories as evidence changes

An assumption may become a risk when evidence challenges it. A risk becomes an issue when its uncertain event occurs. An issue may create secondary risks. An opportunity can become part of the approved plan after a decision, at which point it should no longer remain indefinitely as an open opportunity. Good governance preserves this history so later reviews can understand what changed and when.

Triggers should drive action, not merely narrative updates

A trigger with no associated decision is only an observation. For important risks, the team should define what will happen if the trigger is reached: escalate, commission analysis, reserve capacity, start a contingency action, change sequencing, seek approval or convert the risk to an issue. The response can be proportionate, but the purpose is to reduce delay between evidence and management action.

Risk ownership should follow influence and accountability

A risk owner cannot guarantee that an external authority, supplier or stakeholder behaves as desired. Ownership means being accountable for understanding the project’s exposure, obtaining evidence, coordinating response and escalating when required. Where ownership is unclear because the risk crosses multiple workstreams, that is itself a governance problem that should be resolved rather than hidden with “Project Team” as the owner.

Risk language should remain neutral enough to support commercial and technical challenge

A statement such as “Contractor incompetence will delay the project” mixes judgement, certainty and blame. A neutral statement such as “Because the current production rate remains below the rate required by the accepted plan, there is a possibility that the package does not achieve the agreed completion window, reducing time available for downstream testing” is easier to evidence, analyse and manage. Contractual rights can be assessed separately by the appropriate commercial/legal process.

The boundary with M4.2 should remain clear

M4.1 identifies and frames uncertainty. M4.2 qualitatively analyses relative significance using defined probability/impact criteria and other decision-relevant factors. If the risk statement is vague, M4.2 scoring becomes pseudo-precision. If M4.1 is strong, M4.2 can challenge real evidence and make credible prioritisation decisions.

A useful discipline is: do not argue about whether a risk is “12” or “16” until everyone agrees what uncertain event is actually being scored.

6. Practice diagnostic

Use this table to challenge the quality of the approach or deliverable. The rows consolidate the most important recurring red flags and checks; they are prompts for professional judgement rather than a substitute for the method above.

Before a risk is accepted into the controlled project register, ask:

·       Is there a genuinely uncertain event or condition?

·       Have we distinguished the cause, uncertain event and consequence?

·       Is the possible consequence linked to a defined project objective?

·       Is this actually an issue, action, decision, assumption or dependency rather than a risk?

·       Have we considered whether the uncertainty is an opportunity as well as or instead of a threat?

·       Is the risk linked to the relevant WBS/control account, milestone/activity, contract/package, interface, assumption or decision?

·       Is the statement specific enough that another competent practitioner would understand what evidence to look for?

·       Is there a clear accountable owner with enough influence to coordinate response and escalation?

·       Are existing controls distinguished from proposed response actions?

·       Is there an observable trigger, threshold, decision date or evidence source?

·       Have duplicates, common causes and related risks/issues been considered?

·       Has the team used more than one identification source or technique for material areas?

·       Have material assumptions and external dependencies been challenged rather than accepted as facts?

·       Has bias been challenged by involving people outside the immediate workstream and by asking what may be missing?

·       Is the risk ready for M4.2 qualitative analysis without first needing its wording or evidence repaired?

·       Is there a clear next review and closure/materialisation rule?

A good M4.1 output should allow M4.2 to spend its time analysing significance, not deciphering what the risk statement means.

7. Try-it-yourself practical exercise

Use the Community & Learning Centre at Month 9. Assume the fixed opening date remains unchanged. The following observations have been collected from recent meetings and control data:

·       The specialist supplier has not yet confirmed the manufacturing slot assumed in the schedule.

·       One technology room layout was rejected by the user yesterday and requires redesign.

·       The remaining 18 technology-enabled rooms are expected to be frozen next month, but that date is not contractually committed.

·       The utility provider has given a connection window rather than a firm connection date.

·       The fire authority has acknowledged the test strategy but has not confirmed witness requirements.

·       Installation productivity averaged 17 points/crew-day on a comparable project, while the current plan assumes 20.

·       The project manager has asked procurement to obtain an alternative supplier quotation.

·       A partial library-wing handover might allow operations training to start four weeks earlier.

·       The external-works survey notes that some historic underground-service records are incomplete.

·       The approved budget includes contingency, but no one has linked it to specific risk events.

·       The client has not yet made the final decision on one specialist-learning-space option.

·       The operations team has confirmed that only two trainers are available during the planned peak readiness month.

Complete the exercise in five parts:

·       Classification — classify each observation as risk, issue, assumption, dependency, decision, action, opportunity or evidence. Some observations may create more than one linked item; explain your reasoning.

·       Risk framing — create at least six well-formed cause–event–consequence statements, including at least one opportunity. Avoid probability/impact scores at this stage.

·       Traceability — for each risk, identify the relevant WBS/work package, milestone or activity, cost/estimate assumption, dependency/interface or decision that it could affect.

·       Ownership and triggers — assign an accountable owner and define at least one observable trigger or latest safe decision date for each material risk. Separate risk owner from action owner where appropriate.

·       Challenge — identify duplicates/common causes, state what additional evidence you would seek, and list at least three identification sources you would use to test whether the current set is complete.

Then prepare a one-page handover for M4.2 containing the six most decision-relevant risks/opportunities, each with a clear statement, owner, control link, evidence source and trigger. Do not score them. Your final check is whether another practitioner could begin qualitative analysis without asking you what the risk actually means.

Stretch exercise: choose one risk and show how it could move through the lifecycle from assumption → identified risk → trigger reached → issue/materialisation → secondary risk or closure. Record what evidence and governance action would be needed at each transition.

8. Bridge to capability

The How-to teaches how material uncertainty is found, framed and recorded. At APPLIED and above, capability assessment should test whether the practitioner can use realistic control evidence to distinguish risks from issues, expose weak assumptions and create actionable records. Clear risk statements, objective links, ownership and triggers should demonstrate the method. Supporting work products are illustrative and should be assessed with the practitioner’s reasoning. Sample learning questions illustrate the judgement at each recognition level; they are discussion prompts rather than validated assessment items.

Learning question: Do you understand how uncertainty becomes a useful risk record?

Capability question for APPLIED and above: Can you demonstrate that material uncertainties are well-framed, traceable, owned and ready for analysis rather than merely listed?