Risk, Issue, Change and Decision Tools

Introduction

Projects are temporary systems operating under uncertainty. Their plans depend on assumptions, interfaces, suppliers, technologies, people, approvals and decisions that may change over time. Effective project control therefore requires more than a risk register. It requires an integrated set of tools for identifying uncertainty, recording emerging problems, managing dependencies, evaluating requested changes and making defensible decisions.

Risk, issue, assumption, dependency and change logs are management instruments rather than administrative archives. Their value lies in the quality of the information they contain, the timeliness of updates, the clarity of ownership and the decisions that result. A well-maintained log makes uncertainty visible, supports escalation and preserves an auditable history of project reasoning.

This chapter develops a practical and analytical framework for maintaining these logs and applying qualitative and quantitative risk analysis, decision matrices, scenario analysis and integrated change control.

Learning objectives

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

1. Distinguish risks, issues, assumptions, dependencies and changes.
2. Design and maintain fit-for-purpose project logs.
3. Apply probability–impact assessment, scoring, prioritisation and risk responses.
4. Calculate expected monetary value and interpret simple quantitative risk models.
5. Use decision matrices and scenario analysis without disguising managerial judgement as false precision.
6. Operate an integrated change-control process.
7. Evaluate governance, ethical and technological implications of project-control tools.

1. The logic of integrated uncertainty management

A risk is an uncertain event or condition that, if it occurs, may have a positive or negative effect on one or more project objectives. A threat may increase cost, delay delivery or reduce quality; an opportunity may reduce cost, accelerate completion or improve benefits.

An issue is a current condition or event requiring action. A risk concerns what might happen; an issue concerns what is happening or has already happened. A risk can become an issue when its triggering event occurs.

An assumption is a proposition treated as true for planning purposes without conclusive evidence. Assumptions are necessary because planning cannot wait for complete knowledge, but they create exposure if invalidated.

A dependency is a relationship in which one activity, deliverable, decision or organisation relies on another. Dependencies may be internal or external, mandatory or discretionary, and technical, resource, approval or commercial in nature.

A change is an alteration to an approved baseline, requirement, deliverable, design, schedule, budget, method or governance arrangement. Not every clarification is a formal change; the relevant test is whether an approved commitment or control boundary is affected.

These categories are connected. For example, a project may assume that a regulator will approve a design by 1 June. That assumption creates a dependency on the regulator. The possibility of late approval is a risk. If approval is late, it becomes an issue. A proposal to redesign the product because of the delay is a change request.

The principle of traceability

A robust control system links:

• the source of uncertainty;
• the affected objective or baseline;
• the owner responsible for action;
• the evidence supporting the assessment;
• the decision taken;
• the date and authority of approval; and
• the resulting effect on plans and benefits.

Traceability prevents two common failures: treating logs as isolated lists and approving changes without understanding their cumulative effects.

2. The project control log architecture

A project normally needs several linked registers rather than one overloaded spreadsheet. The precise format can vary, but each record should have a unique identifier and a clear status.

2.1 Minimum data fields

A useful risk record may include ID, date raised, description, cause, event, effect, category, affected objective, probability, impact, score, proximity, early-warning indicator, response strategy, actions, risk owner, action owner, due date, residual rating, status and review date.

The cause–event–effect structure improves precision. “Supplier problem” is vague. “Because the sole specialist supplier has limited test capacity, acceptance testing may be delayed, causing a two-week deployment delay” is more actionable.

An assumption log should record the assumption, rationale, source, confidence, validation method, owner, validation date, consequence if invalidated and resulting risk or issue reference.

An issue log should include description, date identified, impact, urgency, severity, owner, immediate containment, corrective action, target resolution date, escalation route, status and closure evidence.

A dependency record should identify predecessor, successor, relationship type, required date, responsible party, evidence of commitment, health status and contingency. External dependencies require particular attention because the project may have limited authority over them.

A change record should include requestor, requested change, reason, affected requirements, alternatives, cost, schedule, quality, risk, resource and benefit effects, recommendation, decision authority, decision, conditions, implementation owner, baseline version and communication date.

2.2 Log quality and governance

Logs should be concise enough to be used and detailed enough to support decisions. They should be stored in a controlled location, protected from unauthorised alteration and versioned. Access should reflect confidentiality, commercial sensitivity and personal-data requirements.

A log review should occur at a cadence appropriate to volatility. A safety-critical or rapidly changing project may require daily review; a stable internal project may use weekly or fortnightly review. Review is not merely a meeting ritual. Each item should be challenged: Is it still relevant? Has its rating changed? Is the owner acting? Is escalation required? Has the item become an issue, change or closed record?

3. Qualitative risk analysis

Qualitative analysis ranks risks using informed judgement and ordinal scales. It is valuable when data are limited, rapid prioritisation is needed or the cost of detailed modelling is not justified.

Probability–impact assessment

A common approach assigns probability and impact scores, often from 1 to 5. A simple risk score is:

where P is the probability rating and I is the impact rating. The score is ordinal, not a monetary value. A score of 12 does not necessarily represent twice the exposure of a score of 6 because the scales are judgmental and may not be interval measurements.

A probability–impact matrix can classify scores into low, medium and high bands. The organisation should define thresholds in advance. For example, scores of 1–4 may be low, 5–12 medium and 13–25 high, but these boundaries are not universal.

Impact should be assessed against relevant dimensions such as cost, time, scope, quality, safety, compliance, reputation and benefits. A single aggregated impact rating can conceal a severe safety consequence behind several minor benefits. Therefore, high-consequence dimensions should sometimes have escalation rules independent of the numerical score.

Worked example: qualitative ranking

Three threats have been assessed as follows:

Using the stated thresholds, R1 is high, R2 medium and R3 low. R1 should receive immediate response planning and governance attention. R3 may be monitored through routine controls. The result does not mean R3 can be ignored: a low-rated risk may still become important if its probability or impact changes.

Risk responses

For threats, common responses are:

• Avoid: alter the plan to remove the threat.
• Reduce or mitigate: reduce probability or impact.
• Transfer or share: allocate financial or operational consequences to another party, recognising that contractual transfer rarely removes accountability entirely.
• Accept: take no proactive action beyond monitoring, or establish a contingency reserve and trigger plan.

For opportunities, responses include exploit, enhance, share and accept. A response should specify an action, owner, trigger, timing and expected effect. “Monitor supplier” is weaker than “Supplier manager will obtain weekly capacity confirmation; if available test slots fall below two, the contingency laboratory will be activated.”

Residual and secondary risks

A response may reduce the original exposure while creating another risk. For example, outsourcing testing may reduce schedule risk but increase confidentiality or supplier-dependency risk. The post-response rating is the residual risk. New risks created by the response are secondary risks and must be recorded.

4. Quantitative risk analysis

Quantitative analysis estimates the numerical effect of uncertainty using probabilities, ranges, simulations or models. It should be used where the decision value justifies the effort and where the data and assumptions are credible.

Expected monetary value

For mutually exclusive outcomes, expected monetary value (EMV) is:

where p_i is the probability of outcome i, v_i is its monetary value, and the probabilities sum to 1. Positive values represent gains and negative values represent losses. EMV describes a long-run average under repeated comparable conditions; it does not predict the exact outcome of one project.

Worked example: threat and opportunity

A project faces a 30% probability of a £40,000 delay cost. It also has a 20% probability of a £25,000 saving from an early procurement option.

Threat EMV:

Opportunity EMV:

The combined EMV is −£7,000. This does not mean that the project will lose exactly £7,000. It indicates an average exposure useful for comparing alternatives, setting reserves or evaluating responses.

Decision-tree analysis

A decision tree represents choices, uncertain events and consequences. At a chance node, branch probabilities should sum to 1. The expected value of an alternative is calculated by multiplying each terminal outcome by its probability and summing the results.

Suppose Option A costs £100,000 and produces a £180,000 benefit with probability 0.6 or a £90,000 benefit with probability 0.4. Its expected net value is:

Option B costs £70,000 and produces a certain £105,000 benefit, giving an expected net value of £35,000. On expected value alone, Option A is preferred. However, decision makers should also consider liquidity, downside tolerance, strategic fit, safety and whether the probabilities are trustworthy.

Three-point estimates and PERT-style reasoning

For an activity with optimistic estimate a, most-likely estimate m and pessimistic estimate b, a commonly used weighted estimate is:

The formula assumes that the three estimates represent a meaningful range and that the most-likely estimate deserves four times the weight of each extreme. It is a planning approximation, not a law of probability. If a = 4 days, m = 7 days and b = 16 days:

The estimate is appropriate only if the units are consistent and the estimates refer to the same scope and working-calendar assumptions.

Sensitivity and simulation

Sensitivity analysis examines how an output changes when one input changes. A tornado chart is often used to identify influential variables. Scenario analysis changes several coherent assumptions together, such as demand, exchange rates and regulatory timing.

Monte Carlo simulation repeatedly samples from specified input distributions to produce an output distribution. Its results are only as credible as the model, correlations, distributions and input data. Simulation should not be used to create an impressive probability statement from arbitrary assumptions.

5. Decision matrices and scenario analysis

A decision matrix supports structured comparison when alternatives must be judged against several criteria. The basic weighted-score model is:

where S_j is the score for alternative j, w_i is the weight of criterion i, and r_ij is the rating of alternative j on criterion i. Weights should sum to 1, and ratings must use a consistent scale.

For Option A, the score is 0.30×4 + 0.25×2 + 0.25×5 + 0.20×5 = 4.00. Option B scores 3.25. The result favours internal development, but the conclusion depends on the selected criteria, weights and ratings. A criterion such as regulatory acceptability may be a non-negotiable constraint rather than a compensable score. Decision matrices should therefore be accompanied by sensitivity testing and narrative justification.

Scenario analysis explores coherent futures rather than assigning one forecast as certain. A project may develop baseline, upside and downside scenarios, each with assumptions, indicators, consequences and response actions. Scenarios are especially valuable when uncertainty is structural, such as policy change, market disruption or emerging technology.

6. Integrated change control

Integrated change control evaluates proposed changes across the whole project rather than allowing local optimisation. A change that appears beneficial to one workstream may damage cost, schedule, quality, safety, benefits or another workstream.

A disciplined process is:

1. Submit: record the request and its origin.
2. Screen: determine whether it is a change, clarification, defect correction or emergency action.
3. Analyse: assess scope, requirements, cost, schedule, resources, risks, dependencies, procurement, quality, compliance and benefits.
4. Develop options: include do nothing, defer, partially implement or alternative solutions.
5. Recommend: document evidence, assumptions and the analyst’s recommendation.
6. Decide: obtain approval from the authorised change authority.
7. Baseline: update approved requirements, schedule, cost plan, product configuration and related logs.
8. Communicate: notify affected stakeholders and suppliers.
9. Verify and close: confirm implementation and preserve the decision record.

Emergency changes may follow an expedited route, but they should still be documented retrospectively. A change authority should be defined in the governance framework. The project manager may approve changes within delegated limits; larger changes may require a change control board, sponsor or steering committee.

Change impact analysis

Impact analysis should distinguish direct, indirect, cumulative and opportunity effects. It should ask:

• Which requirements and acceptance criteria change?
• Which work packages or interfaces are affected?
• Does the critical path change?
• Are additional risks or dependencies created?
• Does the business case remain valid?
• Are contracts, permits, data protections or safety controls affected?
• Is the change reversible?
• What happens if the change is not implemented?

A project should not implement an approved change merely by editing a plan. The revised baseline and configuration must be controlled so that performance is measured against the correct commitment.

7. Applied case: the Northbridge clinical scheduling platform

The following is an illustrative case.

Background

A university hospital commissions a 12-month project to implement a clinical scheduling platform. The approved baseline includes a £2.4 million budget, integration with three existing systems and a target launch before the winter demand period. Patient safety, data protection and service continuity are explicit constraints.

Problem

The identity-management supplier reports that its interface will be available six weeks later than planned. At the same time, clinicians request additional appointment-priority rules. The project team initially records both matters as “requirements changes,” obscuring the distinction between an external dependency, a risk, an issue and a change.

Analysis

The late interface is first recorded as a dependency: the scheduling platform depends on the supplier’s interface by a specified date. Once the supplier confirms the delay, it becomes an issue. The risk register records the consequence of further delay, including integration rework and launch slippage. The clinicians’ request is a change request because it alters approved functionality.

The team assesses three responses to the interface issue:

• wait for the supplier interface;
• build a temporary adapter; or
• defer the affected integration and conduct a controlled phased launch.

A decision matrix uses cost, launch protection, operational risk and maintainability. The temporary adapter scores highest, but technical review identifies a significant data-security risk. The team therefore proposes a restricted adapter with additional testing and a sunset date.

A quantitative assessment estimates a 40% probability of a three-week delay if the team waits. At £55,000 per week, the delay EMV is:

The adapter costs £48,000 and has a 15% probability of causing £80,000 of remediation cost. Its expected remediation exposure is £12,000, giving a simple expected cost of £60,000 before considering schedule benefits. The decision is not determined by arithmetic alone: the adapter may protect the winter launch, but it requires security assurance and clinical testing.

The change request for priority rules is analysed separately. It would add £90,000, two weeks of development and a new test cycle. The change authority approves only a subset of rules that are required for safety and legal compliance. Desirable reporting enhancements are deferred to a later release.

Approach and solution

The project establishes linked records:

• dependency D-07 for the supplier interface;
• issue I-04 for the confirmed delay;
• risk R-12 for further integration slippage;
• change C-09 for priority-rule modifications; and
• decision DEC-15 recording the adapter decision and its security conditions.

Weekly reviews examine trigger indicators, adapter test results, supplier commitments, residual risks and the effect on the launch decision. The baseline is reissued after approval, and the deferred enhancements remain visible in the product roadmap rather than being silently removed.

Outcome

The restricted adapter passes security and clinical testing. The project launches on the target date with the approved priority rules. The adapter is replaced in the next release after the supplier interface becomes stable. The final review finds that the decision log and linked records were essential in explaining why the project accepted temporary technical debt and how that debt would be retired.

Learning points

1. One event can move through several control categories over time.
2. A numerical comparison supports, but does not replace, professional judgement.
3. Safety, privacy and regulatory constraints may be thresholds rather than weighted criteria.
4. Every approved change should have a baseline, owner, implementation condition and verification method.
5. Temporary solutions require explicit exit criteria.

8. Challenges, limitations and ethical governance

False precision

Scores, probabilities and monetary values can create an illusion of objectivity. Judgements should identify evidence quality, confidence and disagreement. Ranges may be more honest than single-point estimates.

Correlation and aggregation

Risks are not always independent. Several risks may depend on the same supplier, market or technical assumption. Adding EMVs without considering correlation can understate or overstate aggregate exposure. Quantitative models should document dependencies and avoid double counting.

Bias and group dynamics

Anchoring, optimism bias, availability bias and hierarchy can distort estimates. Facilitated workshops, independent challenge, reference-class data and anonymous estimates can improve quality. The project manager should ensure that dissent is recorded rather than suppressed.

Ethical and regulatory issues

Risk prioritisation must not conceal harms to vulnerable groups. A low-probability event with severe safety, privacy or equity consequences may require action despite a modest score. Personal data in logs should be minimised, access-controlled and retained according to applicable policy and law. Commercially sensitive information should not be copied into uncontrolled tools.

Decision records should disclose conflicts of interest. A supplier should not be allowed to define both the evidence and the acceptance of its own corrective action without independent assurance. Automated recommendations should remain reviewable and contestable.

AI-enabled tools

AI can classify log entries, detect duplicate risks, identify overdue actions, summarise decision history and analyse patterns across projects. It can also generate fabricated evidence, reproduce historical bias, expose confidential data or assign unjustified confidence to weak predictions. Human owners must validate classifications, protect data, preserve audit trails and ensure that automated outputs do not make unauthorised decisions. AI should augment governance, not replace accountable authority.

9. Professional best practices

1. Use one source of truth with controlled access and version history.
2. Write risks in cause–event–effect form.
3. Give every active item an owner, due date and next action.
4. Define rating scales and escalation thresholds before assessment.
5. Separate inherent risk from residual risk.
6. Record assumptions and test them deliberately.
7. Link risks, issues, dependencies, changes and decisions through unique IDs.
8. Use quantitative analysis when it can change a decision, not merely to decorate a report.
9. Treat safety, legal and ethical constraints as possible “must-pass” conditions.
10. Analyse cumulative change, not just individual requests.
11. Close items only with evidence of resolution or accepted transfer.
12. Review the usefulness of the control system itself and remove fields that do not support action.

Chapter Summary

Risk, issue, assumption, dependency, change and decision records form an integrated project-control system. Risks describe uncertain future events; issues are current problems; assumptions are planning propositions; dependencies describe reliance; changes alter approved commitments; and decision logs preserve governance rationale. Effective logs use clear definitions, unique identifiers, owners, dates, actions, status and traceability.

Qualitative analysis uses probability–impact assessment to prioritise attention, while quantitative analysis uses methods such as expected monetary value, decision trees, three-point estimates, sensitivity analysis and simulation. These methods support judgement but cannot eliminate uncertainty or compensate for poor assumptions. Decision matrices structure multi-criteria comparison, whereas scenario analysis examines coherent alternative futures.

Integrated change control requires submission, impact analysis, authorised decision, baseline management, communication and verification. Ethical governance requires attention to safety, equity, privacy, conflicts of interest, data quality and the limits of automation. The professional objective is not to predict the future perfectly, but to make uncertainty visible, decisions defensible and project commitments controllable.

Key Terms

Assumption: A proposition treated as true for planning purposes.

Change control: The governed process for assessing, approving, implementing and verifying changes.

Change authority: The person or body authorised to approve changes within defined limits.

Decision log: A controlled record of material decisions, rationale, authority and conditions.

Dependency: A relationship in which one activity, deliverable or decision relies on another.

EMV: Expected monetary value calculated by weighting outcomes by their probabilities.

Issue: A current condition requiring action or resolution.

Mitigation: Action intended to reduce the probability or impact of a threat.

Probability–impact matrix: A grid used to rank risks using likelihood and consequence ratings.

Residual risk: Risk remaining after responses have been implemented.

Risk: An uncertain event or condition that may affect objectives.

Risk appetite: The amount and type of uncertainty an organisation is willing to pursue or retain.

Risk owner: Person accountable for monitoring and responding to a risk.

Scenario analysis: Examination of coherent alternative future conditions and their implications.

Secondary risk: A new risk created by a risk response.

Sensitivity analysis: Analysis of how changes in input variables affect an output.

Stakeholder: An individual, group or organisation that may affect, be affected by or perceive itself affected by a project.

Trigger: An observable warning sign that a risk response or escalation may be required.

Weighted decision matrix: A structured comparison of alternatives using weighted criteria and ratings.

Workaround: An unplanned response used to address an issue when no approved solution is immediately available.

Review Questions

Short Answer Questions

1. Distinguish a risk from an issue and explain how one can become the other.
2. What information should be included in a risk register entry?
3. Why should residual and secondary risks be recorded after a response?
4. State the purpose of a decision log.
5. Why can a risk score not normally be interpreted as a monetary value?

Long Answer Questions

1. Explain how risk, assumption, issue, dependency and change logs can be integrated without losing their distinct purposes.
2. Compare qualitative and quantitative risk analysis, including their strengths, limitations and appropriate uses.
3. Describe the stages of integrated change control and explain the role of baseline management.
4. Explain how decision matrices and scenario analysis support project governance, and discuss their limitations.
5. Evaluate the ethical and governance risks of using AI to classify and prioritise project-control records.

Analytical / Application Questions

1. A project has a 25% probability of a £120,000 delay and a 40% probability of a £30,000 saving. Calculate the separate and combined EMVs, then explain why the result should not be treated as a guaranteed financial outcome.
2. Construct a decision matrix for three implementation options using at least four criteria. State the weights, justify the ratings and test whether a reasonable change in one weight alters the preferred option.
3. A supplier confirms that a critical interface will be delivered one month late, while users request additional functionality. Identify the relevant risks, issue, dependency, assumption and change records, and design an integrated control and escalation approach.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes a risk from an issue?

A. A risk is always negative, whereas an issue is always positive.

B. A risk is uncertain; an issue is a current condition requiring action.

C. A risk requires approval, whereas an issue never requires approval.

D. A risk belongs in the change log, whereas an issue belongs in the assumption log.

Correct Answer: B. A risk is uncertain; an issue is a current condition requiring action.

Question 2

Using a 1–5 probability–impact scale, what is the score for probability 4 and impact 5?

A. 9

B. 12

C. 20

D. 25

Correct Answer: C. 20

Question 3

A project faces a 30% probability of a £40,000 loss. What is the threat EMV?

A. £12,000

B. −£12,000

C. −£40,000

D. £28,000

Correct Answer: B. −£12,000

Question 4

Which item is most appropriate for an assumption log?

A. A confirmed supplier delay requiring corrective action

B. A proposed alteration to an approved requirement

C. The proposition that regulatory approval will arrive by a planned date

D. A completed decision with no remaining conditions

Correct Answer: C. The proposition that regulatory approval will arrive by a planned date

Question 5

In a weighted decision matrix, what should normally be true of the criterion weights?

A. They should sum to 1 or 100%.

B. They should all be equal.

C. They should be expressed only as monetary values.

D. They should be greater than the ratings.

Correct Answer: A. They should sum to 1 or 100%.

Question 6

What is the principal purpose of integrated change control?

A. To prevent all changes after project initiation

B. To assess changes across their effects on the whole project before authorisation

C. To allow each workstream to change its baseline independently

D. To replace the risk register with a change register

Correct Answer: B. To assess changes across their effects on the whole project before authorisation

Question 7

If a response to a supplier risk creates a new confidentiality exposure, the new exposure is best classified as a:

A. Residual benefit

B. Secondary risk

C. Closed issue

D. Decision threshold

Correct Answer: B. Secondary risk

Question 8

For estimates a = 4 days, m = 7 days and b = 16 days, the weighted three-point estimate (a + 4m + b) ÷ 6 is:

A. 6 days

B. 7 days

C. 8 days

D. 9 days

Correct Answer: C. 8 days

Question 9

Which statement about EMV is most accurate?

A. It predicts the exact loss on a single project.

B. It is useful for comparing uncertain alternatives but depends on probabilities and outcome estimates.

C. It can be calculated without assigning probabilities.

D. It automatically accounts for correlation among risks.

Correct Answer: B. It is useful for comparing uncertain alternatives but depends on probabilities and outcome estimates.

Question 10

Which action is an essential part of closing an approved change?

A. Delete the original request to avoid confusion.

B. Implement it without notifying affected stakeholders.

C. Verify implementation and update the relevant baseline and records.

D. Transfer all accountability to the change requester.

Correct Answer: C. Verify implementation and update the relevant baseline and records.