Risk Identification and Knowledge Elicitation

Introduction

Risk identification is the systematic discovery, description, and recording of uncertain events or conditions that may affect project objectives. It is not a one-time administrative exercise. Risks emerge as project scope becomes clearer, assumptions are tested, external conditions change, and stakeholders learn more about the work. Effective identification therefore combines structured methods with professional judgement and converts dispersed knowledge into usable project information.

A risk register is the principal operational record produced by this process. However, a register is valuable only when its entries are sufficiently precise to support ownership, analysis, response planning, monitoring, and governance. Vague entries such as “supplier problems” or “the project may be delayed” do not meet this standard. A well-formed risk statement identifies a cause, an uncertain event, and one or more effects on objectives.

This chapter develops a practical and analytical approach to interviews, workshops, checklists, prompt lists, assumptions analysis, SWOT, PESTLE, systems mapping, root-cause analysis, lessons learned, and Delphi techniques. It also explains how to assess the quality of elicited information and construct a complete risk register.

Learning Objectives

By the end of this chapter, the learner should be able to:

1. Distinguish risks from issues, causes, effects, assumptions, and constraints.
2. Select and combine appropriate risk-identification and knowledge-elicitation techniques.
3. Design effective interviews, workshops, checklists, and Delphi studies.
4. Analyse assumptions, internal and external environments, system relationships, and root causes.
5. Write clear cause–event–effect risk statements.
6. Develop a fit-for-purpose risk register and evaluate the quality of its entries.
7. Recognise cognitive, ethical, cultural, and governance challenges in eliciting risk information.

1. The Logic of Risk Identification

1.1 Risk and uncertainty

In project management, a risk is an uncertain event or condition that, if it occurs, can have a positive or negative effect on one or more objectives. Threats may affect cost, time, scope, quality, safety, compliance, reputation, benefits, or stakeholder confidence. Opportunities may improve these outcomes.

An issue is a condition that has already occurred or is currently occurring. For example, a failed inspection is an issue; the possibility that a future inspection may fail is a risk. A cause is a circumstance that could generate a risk event, while an effect is the consequence if the event occurs. A constraint is a limiting condition, such as a statutory deadline or approved budget. An assumption is treated as true for planning purposes but may prove false.

The distinction matters because each category requires different management. Issues require resolution or control; risks require uncertainty analysis and responses; assumptions require validation; constraints shape feasible alternatives.

1.2 The cause–event–effect model

A robust risk statement normally follows this structure:

Because of cause(s), uncertain event may occur, leading to effect(s) on objective(s).

For example:

Because the specialist equipment has a single overseas source, customs clearance may take longer than planned, leading to installation delay and additional expediting cost.

The first clause supports preventive action, the middle clause defines the uncertainty, and the final clause supports impact assessment and response planning. A positive risk can be written similarly: because of an enabling condition, an opportunity may occur, leading to a beneficial effect.

A useful quality test is whether a reader can answer four questions: What might happen? Why might it happen? What would happen if it did? Which objective would be affected?

1.3 Risk categories and taxonomy

A risk breakdown structure (RBS) groups risks into meaningful categories. Typical categories include strategic, commercial, technical, schedule, cost, resource, quality, safety, environmental, legal, security, stakeholder, and organisational risks. An RBS promotes completeness and enables aggregation: a project may discover several individual risks that reflect a common procurement or interface exposure.

The RBS should be adapted to the project. Excessive categories create administrative burden; too few hide important distinctions. Categories should support analysis and ownership rather than merely decorate the register.

2. Preparing for Knowledge Elicitation

Risk identification depends on the quality and diversity of knowledge brought into the process. Before collecting information, the project manager should define the scope, objectives, decision boundaries, stakeholders, lifecycle stage, available evidence, confidentiality requirements, and intended use of the outputs.

A stakeholder map should include the project sponsor, client, users, designers, delivery teams, operations personnel, suppliers, regulators, affected communities, finance and legal specialists, and those who will inherit the asset or service. People with operational or historical knowledge may identify risks that formal project documents do not reveal.

The facilitator should establish ground rules: evidence is welcomed, uncertainty is not blame, dissent is legitimate, confidential information is protected, and risks will not automatically be attributed to individuals. These rules are particularly important where hierarchy, contracting relationships, or organisational politics inhibit candour.

Elicitation should use multiple methods. A workshop may reveal interactions among risks, while a private interview may reveal a concern that a participant would not state publicly. Triangulation—comparing interviews, documents, data, and observations—improves credibility but does not guarantee truth. Conflicting evidence should be recorded and investigated rather than silently averaged.

3. Core Elicitation Techniques

3.1 Interviews

Interviews are useful when expertise is specialised, information is sensitive, participants are geographically dispersed, or the project requires detailed exploration. They may be structured, semi-structured, or open-ended. Semi-structured interviews usually provide the best balance: a common question set supports comparability while probing allows unexpected risks to emerge.

A practical interview sequence is:

1. Explain purpose, confidentiality, and intended outputs.
2. Ask the participant to describe objectives, deliverables, dependencies, and major uncertainties.
3. Explore each phase or work package.
4. Probe causes, early warning signs, consequences, controls, and possible opportunities.
5. Test assumptions and interfaces with other teams.
6. Confirm the interviewer’s interpretation and agree on follow-up evidence.

Questions should avoid leading respondents toward a preferred answer. “What could prevent the acceptance test from succeeding?” is generally better than “Are you worried that the acceptance test will fail?” Useful probes include “What has changed?”, “What must be true for this plan to work?”, “Where does responsibility transfer?”, and “What happened on similar projects?”

Interview outputs should distinguish direct statements from the analyst’s interpretation. The participant’s confidence, evidence, and unresolved disagreement should also be recorded.

3.2 Workshops

Workshops create shared understanding and are especially useful for cross-functional, interface, and dependency risks. A typical workshop includes orientation, objective clarification, individual idea generation, facilitated sharing, clustering, causal refinement, validation, and assignment of follow-up actions.

Silent brainstorming before group discussion reduces conformity and the influence of senior participants. Breakout groups can examine lifecycle stages or RBS categories, after which the full group reviews overlaps and interactions. Voting may prioritise topics for analysis, but a vote is not a substitute for evidence or formal assessment.

The facilitator must manage anchoring, groupthink, dominance, premature evaluation, and scope drift. A separate scribe should capture the exact meaning of contributions. Workshop participants should validate the draft register after the session because rapid discussion often produces compressed or ambiguous wording.

3.3 Checklists and prompt lists

A checklist uses known risk categories, historical risks, standards, audit findings, or organisational controls to prompt consideration. It is efficient and valuable for recurring project types. A prompt list is broader and asks questions such as “What could change?”, “What could fail at an interface?”, “What depends on an external party?”, and “What assumption has not yet been tested?”

Checklists improve consistency but can create false confidence. They tend to reproduce known risks and may suppress novel or project-specific risks. They should therefore be used as prompts, followed by open exploration. The source, date, applicability, and limitations of a checklist should be documented.

3.4 Assumptions and constraints analysis

The assumptions log should be reviewed line by line. For each assumption, ask:

• Is it necessary to the plan?
• What evidence supports it?
• Who can validate it, and by when?
• What event would occur if it were false?
• What objective would be affected?
• Can the plan be changed to reduce dependence on it?

For example, “the regulator will approve the design within six weeks” is an assumption. The related risk is not simply “approval risk”; it might be: “Because the design contains an untested compliance interpretation, approval may take longer than six weeks, delaying procurement and the planned construction start.”

Constraints are not automatically risks. A fixed completion date is a constraint; the risk may be that unresolved design decisions make achievement of that date unlikely. This translation prevents the register from becoming a list of facts rather than uncertainties.

3.5 SWOT analysis

SWOT examines strengths, weaknesses, opportunities, and threats. Strengths and weaknesses are generally internal; opportunities and threats are generally external, although the boundary depends on the organisation and its environment. SWOT is useful at initiation and strategy review, but its categories are not risk statements.

Each material SWOT observation should be converted into a causal statement. For example, a strength such as “experienced commissioning team” may enable an opportunity to shorten testing; a weakness such as “limited cybersecurity expertise” may create a threat of undetected vulnerabilities. SWOT should be combined with evidence and stakeholder analysis rather than used as an isolated brainstorming exercise.

3.6 PESTLE analysis

PESTLE prompts consideration of political, economic, social, technological, legal, and environmental forces. It is particularly useful for programmes exposed to policy, market, community, technology, regulatory, or climate change.

The method should examine both direction and uncertainty. A known new regulation is a planning fact; uncertainty about its final interpretation, timing, or enforcement is a risk. PESTLE findings should be linked to project assumptions, external dependencies, trigger conditions, and monitoring responsibilities.

3.7 Systems mapping and interface analysis

Projects are systems of interdependent people, processes, technologies, contracts, organisations, and external environments. A systems map represents nodes and relationships such as information flow, authority, material movement, payment, approval, and operational feedback. Risk frequently occurs at interfaces where responsibility, timing, data, or expectations are unclear.

A systems-mapping exercise should identify:

• critical inputs and outputs;
• feedback loops and delays;
• single points of failure;
• shared resources and competing priorities;
• handoffs and ownership gaps;
• dependencies outside project control; and
• cascading effects.

For example, a design change may affect procurement, which affects fabrication, which affects installation, which affects testing and revenue commencement. Treating these as isolated risks can understate the system effect. Mapping also helps distinguish a root risk from downstream consequences.

3.8 Root-cause analysis

Root-cause analysis investigates why an undesirable event could occur. The five-whys technique repeatedly asks why, while a fishbone diagram groups possible causes under headings such as people, process, technology, materials, environment, and management. Fault-tree analysis starts with a top event and logically decomposes combinations of causes; it is most useful where technical failure logic is sufficiently understood.

Root-cause analysis should not imply that every event has one definitive cause. Complex project failures often arise from interacting conditions, weak controls, and latent organisational factors. The analysis should therefore record contributing causes, existing controls, evidence, and residual uncertainty. It should also avoid hindsight bias: a cause obvious after failure may not have been reasonably observable beforehand.

3.9 Lessons learned

Lessons learned may be gathered from close-out reports, post-implementation reviews, near misses, audits, incident investigations, operational data, and experienced personnel. High-quality lessons explain context and mechanism, not merely outcomes. “Communication was poor” is weak; “interface decisions were recorded in informal messages without a controlled decision log, so downstream teams acted on different versions” is actionable.

Lessons must be screened for transferability. A risk observed on a small domestic project may not apply to a regulated international programme. The analyst should identify the original conditions, the mechanism of failure or success, the control that would have helped, and whether the lesson is current.

3.10 Delphi technique

The Delphi technique obtains judgements from a panel through multiple rounds of anonymous questioning. After each round, a facilitator aggregates responses and provides a neutral summary for reconsideration. Anonymity reduces authority effects and allows participants to revise views without loss of face.

A sound Delphi design defines the panel and expertise criteria, the question and rating scales, the number and timing of rounds, the treatment of non-response, and the method for reporting disagreement. Consensus should not be confused with correctness. A stable wide disagreement may be more informative than an artificial average, especially where evidence is sparse.

Delphi is valuable for emerging technologies, long-term external risks, and situations where experts cannot meet. It is resource-intensive and vulnerable to panel-selection bias, poorly worded questions, attrition, and facilitator influence. Results should be presented with dispersion and rationale, not only a single “consensus” answer.

4. From Raw Information to a Risk Register

A risk register should be treated as a controlled knowledge product rather than a static spreadsheet. A useful minimum structure is shown below.

A register entry should be concise but not cryptic. “Vendor delay” is inadequate. “Because the vendor’s interface specification is incomplete, integration testing may be postponed, delaying operational acceptance by up to four weeks” is more useful. If evidence does not justify a quantified impact, use a documented qualitative scale rather than invented precision.

Risk owners need authority, access to information, and sufficient control over response actions. A person who merely observes a risk is a risk contact, not necessarily its owner. Owners should confirm the wording, assess the risk, define actions, and report changes.

Qualitative and quantitative prioritisation

Many organisations use ordinal probability and impact scales. If probability is scored from 1 to 5 and impact from 1 to 5, a screening score may be calculated as:

Here, S is the screening score, P is the ordinal probability rating, and I is the ordinal impact rating. This calculation is appropriate only as a prioritisation convention; it does not produce a probability, monetary value, or ratio-scale measurement. The organisation must define the descriptors, thresholds, affected objective, and treatment of different impact dimensions. A score of 12 is not necessarily twice as serious as a score of 6.

For decision analysis under uncertainty, expected monetary value (EMV) may be used:

where pᵢ is the probability of outcome i, Cᵢ is its monetary consequence, and the probabilities across mutually exclusive outcomes sum to 1. Costs are normally represented as negative values and benefits as positive values, or the convention must be stated. EMV is an average over repeated comparable situations, not a prediction of the actual result of one project. It requires credible probabilities, consequences expressed in comparable monetary units, and clearly defined outcomes. It should not replace consideration of safety, legal, ethical, distributional, or strategic consequences.

5. Applied Case: Northbridge Hospital Digital-Records Programme

The following is an illustrative case.

Background and problem

Northbridge Hospital is implementing an integrated electronic health-record system across three sites. The programme has a fixed regulatory transition date, multiple suppliers, legacy interfaces, and clinicians who must continue patient care during migration. Early planning meetings produce a register containing “training risk,” “data risk,” and “supplier risk,” but executives consider it too vague to support decisions.

Analysis and elicitation

The programme manager combines methods. Private interviews are conducted with clinicians, information-security staff, the migration supplier, records managers, and the regulator liaison. A workshop maps the patient-admission, treatment, billing, and reporting systems. An assumptions review identifies the belief that historical patient identifiers are consistent across sites. PESTLE highlights changing privacy guidance and workforce pressures. Lessons from a previous hospital implementation reveal that informal interface decisions were not recorded. A Delphi panel of clinical, technical, and regulatory specialists considers emerging risks associated with automated data matching.

The systems map reveals a critical dependency: data cleansing must be completed before migration rehearsals, while interface testing requires stable identifiers and a reliable test environment. These dependencies were not visible in the original work-package register.

Risk formulation

The vague entry “data risk” is replaced by two distinct statements:

1. “Because patient identifiers differ between two legacy systems, automated matching may incorrectly merge or separate records, leading to patient-safety exposure, rework, and delayed migration approval.”
2. “Because privacy guidance for secondary use of historical data is still under review, the approved migration design may require additional consent controls, leading to redesign and schedule pressure.”

The first risk is assigned to the data migration lead, with information-security and clinical safety as consulted functions. Triggers include a failed matching threshold in rehearsal and unresolved exceptions above the agreed tolerance. Preventive actions include early profiling, independent sample validation, and a controlled exception process. The second risk is owned by the regulatory lead, with a monitoring action tied to guidance publication and a contingency involving staged migration.

Outcome and learning points

The revised register supports targeted decisions: funding is approved for an independent data-quality review, the programme changes the rehearsal sequence, and executives receive an explicit view of regulatory uncertainty. The case illustrates that elicitation methods are complementary. Interviews revealed tacit knowledge, systems mapping exposed dependencies, assumptions analysis identified fragile planning foundations, and lessons learned shaped controls. Most importantly, the final entries connected causes, uncertain events, consequences, owners, and observable triggers.

6. Quality, Bias, Ethics, and Governance

Risk elicitation is a social process and is vulnerable to systematic distortion. Common biases include anchoring on the initial estimate, availability bias from memorable events, optimism bias, normalcy bias, confirmation bias, authority effects, and strategic understatement. Mitigations include independent first-pass estimates, anonymous input, diverse participation, evidence requests, explicit uncertainty statements, and periodic reassessment.

Psychological safety is an ethical requirement as well as a practical one. Staff should be able to report hazards and near misses without retaliation, subject to lawful and necessary accountability. Confidential information, personal data, commercially sensitive information, and security vulnerabilities require appropriate access controls and retention rules. Risk registers should not become repositories of unnecessary personal allegations.

Governance should define who may create, edit, approve, close, and escalate risks; how changes are versioned; how overdue actions are reported; and how risk information is integrated with change control, issue management, assurance, procurement, safety, and benefits governance. A risk may be closed because it no longer applies, because it has become an issue, or because exposure is within accepted tolerance. Closure rationale should be recorded.

AI-supported tools can assist with document scanning, duplicate detection, taxonomy tagging, transcript summarisation, and comparison with historical registers. They can also amplify bias, misclassify context, expose confidential material, or generate plausible but unsupported risks. Human experts must validate source evidence, preserve provenance, protect data, and remain accountable for decisions. AI output is a prompt for professional review, not evidence by itself.

7. Practical Integration and Best Practice

An effective identification cycle is iterative:

1. establish objectives, scope, stakeholders, and governance;
2. review plans, assumptions, contracts, data, and lessons;
3. use broad prompts and structured methods to generate candidates;
4. explore causes, events, effects, controls, interfaces, and triggers;
5. remove duplicates and separate risks from issues and facts;
6. formulate cause–event–effect statements;
7. validate entries with affected stakeholders;
8. assign owners and record actions;
9. analyse and prioritise using defined scales or justified quantitative models; and
10. monitor, refresh, escalate, and capture new learning.

Best practice is not to maximise the number of risks. It is to create a manageable, credible, and decision-relevant representation of uncertainty. A smaller register with clear ownership, evidence, triggers, and actions is more valuable than a long catalogue of generic possibilities.

Chapter Summary

Risk identification is a continuing process of discovering uncertainty and translating knowledge into decisions. The central analytical structure is the cause–event–effect statement, supported by objectives, evidence, ownership, controls, triggers, and responses. Interviews and workshops elicit situated and collective knowledge; checklists and prompt lists improve coverage; assumptions analysis tests planning foundations; SWOT and PESTLE examine internal and external environments; systems mapping reveals dependencies and interfaces; root-cause analysis investigates mechanisms; lessons learned provide contextual evidence; and Delphi supports structured expert judgement under uncertainty.

A risk register should distinguish risks from issues, assumptions, constraints, causes, and effects. Qualitative scores are conventions for prioritisation, while EMV is an expected average requiring credible probabilities and comparable consequences. Bias, power relationships, confidentiality, data protection, and governance must be addressed explicitly. Technology and AI may support analysis, but accountability and validation remain human responsibilities. The quality of risk management depends less on producing many entries than on producing well-formed, traceable, actionable knowledge.

Key Terms

Risk: An uncertain event or condition that may affect an objective.

Issue: A current or realised condition requiring management.

Cause: A circumstance that may generate a risk event.

Effect: A consequence of a risk event.

Assumption: A proposition treated as true for planning but subject to uncertainty.

Constraint: A limiting condition imposed on the project.

Risk statement: A structured description of cause, uncertain event, effect, and objective.

Risk register: A controlled record of risks and their management information.

Risk owner: The person accountable for managing a risk.

Risk breakdown structure: A hierarchical classification of risk sources.

Trigger: An observable sign that a risk is occurring or changing.

Checklist: A structured list used to prompt consideration of known risks.

SWOT: Analysis of strengths, weaknesses, opportunities, and threats.

PESTLE: Analysis of political, economic, social, technological, legal, and environmental influences.

Systems mapping: Representation of elements, relationships, dependencies, and feedback in a project system.

Root-cause analysis: Investigation of underlying and contributing causes.

Lessons learned: Contextual knowledge derived from prior experience or performance.

Delphi technique: Anonymous, iterative elicitation of expert judgement.

Expected monetary value: Probability-weighted average monetary consequence across defined outcomes.

Triangulation: Comparison of multiple sources or methods to strengthen interpretation.

Review Questions

Short Answer Questions

1. Distinguish a risk from an issue, assumption, and constraint.
2. What are the three essential components of a cause–event–effect risk statement?
3. State two advantages and two limitations of checklists.
4. Why are interfaces important in systems-based risk identification?
5. What is the purpose of anonymity in a Delphi study?

Long Answer Questions

1. Explain how interviews and workshops can be designed and combined to elicit project risk knowledge.
2. Compare SWOT, PESTLE, assumptions analysis, and lessons learned as risk-identification methods.
3. Discuss the role of root-cause analysis in constructing preventive risk responses.
4. Explain the fields that should be included in a professionally governed risk register.
5. Critically evaluate the use of ordinal probability–impact scores and EMV in project risk prioritisation.

Analytical / Application Questions

1. Rewrite the entry “supplier may cause delays” as a complete cause–event–effect statement, and propose an owner, trigger, and preventive action.
2. A project assumes that a regulator will approve a design in six weeks. Develop an assumptions analysis and identify at least two related risks and their controls.
3. Design a mixed-method identification plan for a complex digital transformation involving legacy systems, external suppliers, sensitive personal data, and a fixed regulatory deadline.

Multiple Choice Questions with Answers

Question 1

Which statement best represents a well-formed project risk?

A. The supplier is unreliable.

B. The project may be delayed.

C. Because interface specifications are incomplete, integration testing may be postponed, delaying operational acceptance.

D. There is a supplier issue.

Correct Answer: C. Because interface specifications are incomplete, integration testing may be postponed, delaying operational acceptance.

Question 2

What primarily distinguishes an issue from a risk?

A. An issue is always more costly than a risk.

B. An issue has occurred or is occurring, while a risk is uncertain.

C. An issue belongs in the risk register, while a risk does not.

D. An issue can only affect schedule.

Correct Answer: B. An issue has occurred or is occurring, while a risk is uncertain.

Question 3

Which technique uses repeated anonymous rounds of expert judgement?

A. SWOT analysis

B. Delphi technique

C. Fishbone analysis

D. Checklist review

Correct Answer: B. Delphi technique

Question 4

What is a principal limitation of a checklist?

A. It cannot be used for recurring projects.

B. It prevents any form of stakeholder participation.

C. It may encourage attention to known risks while overlooking novel risks.

D. It cannot support consistent identification.

Correct Answer: C. It may encourage attention to known risks while overlooking novel risks.

Question 5

In an assumptions review, what should happen when an assumption proves fragile?

A. It should be deleted to avoid unnecessary concern.

B. It should be converted into a validated fact immediately.

C. Its evidence, validation owner, and consequences of failure should be examined.

D. It should automatically be treated as an issue.

Correct Answer: C. Its evidence, validation owner, and consequences of failure should be examined.

Question 6

Which method is especially useful for revealing handoffs, dependencies, and single points of failure?

A. Systems mapping

B. SWOT analysis

C. Delphi

D. Individual voting

Correct Answer: A. Systems mapping

Question 7

If a project uses a 1–5 probability score and a 1–5 impact score, what is the screening score for P = 4 and I = 3?

A. 7

B. 12

C. 15

D. 43

Correct Answer: B. 12

Question 8

What is the main purpose of a risk trigger?

A. To prove that a risk will occur

B. To indicate that a risk’s exposure is changing or the event is emerging

C. To replace the risk owner

D. To eliminate the need for monitoring

Correct Answer: B. To indicate that a risk’s exposure is changing or the event is emerging

Question 9

Which practice best reduces authority effects in a risk workshop?

A. Allowing the most senior participant to speak first

B. Using silent individual idea generation before group discussion

C. Accepting only ideas supported by executives

D. Removing disagreement from the final record

Correct Answer: B. Using silent individual idea generation before group discussion

Question 10

What is a necessary condition for meaningful EMV analysis?

A. All impacts must be qualitative.

B. Probabilities and consequences must be credible and expressed in comparable units.

C. Every risk must have exactly the same probability.

D. EMV must replace safety and ethical judgement.

Correct Answer: B. Probabilities and consequences must be credible and expressed in comparable units.