Risk Reduction Analysis
Risk Reduction Analysis translates the results of the preceding Risk Assessment into two things: a clear statement of where risk reduction is required, and a structured shortlist of feasible mitigation options.
It is the link between risk assessment and the subsequent optioneering stage within the wider Risk Mitigation module.
Purpose
The process determines whether the assessed level of risk is acceptable and, where it is not, what type and scale of intervention would reduce it to an acceptable or tolerable level.
What it does not do
The process does not select the final investment programme. It defines the risk reduction need, identifies feasible responses, and prepares an evidence-based option shortlist for the next stage.
Selection happens in Detailed Option Assessment and Portfolio Optimisation.
Questions answered
- Which assets, systems, routes or network locations exceed the agreed risk threshold or otherwise require management action?
- Can the risk be accepted, monitored, maintained, reduced, transferred, or avoided?
- Which broad intervention types are technically relevant and proportionate to the identified need?
- What requirements, contextual factors and constraints affect the feasibility of each intervention?
- Are individual interventions sufficient, or should they be combined into a coordinated mitigation package?
- Which options are suitable for immediate implementation, and which should be retained as future pathway choices or trigger-based adaptations?
- Which options should be passed forward as a shortlist?
The six risk responses
Accept, monitor, maintain, reduce, transfer, avoid. Only one of those six involves building anything.
Listing them as equal candidates is what stops the process defaulting to construction. An accepted risk, consciously accepted and documented, is a legitimate outcome.
What the process does to each option
Four activities are applied to the candidate options.
Screen for feasibility
Assess whether each option is feasible across six dimensions:
| Dimension | The question |
|---|---|
| Technically | Can it be engineered? |
| Operationally | Can it be run alongside the service? |
| Spatially | Is there room, and access? |
| Legally | Is it permissible? |
| Commercially | Can it be procured and contracted? |
| Institutionally | Can the organisations involved actually deliver it? |
Options that fail minimum requirements are removed or revised.
The last two are the ones usually missed
Technical and operational feasibility are always tested. Commercial and institutional feasibility, meaning whether it can be bought and whether the organisations can deliver it between them, are where otherwise sound options fail late and expensively.
Assess costs and wider performance
Estimate capital, operating, maintenance and whole-life costs, together with benefits and effects on asset performance, service level, sustainability, resilience and other decision criteria.
Consider interdependencies
Where an option affects connected assets or systems, test whether it creates additional requirements, constraints, benefits or unintended consequences elsewhere.
Develop packages and pathways
Combine complementary measures into mitigation packages. Where future uncertainty is important, organise options into staged adaptation pathways with decision points and trigger conditions.
A pathway is not a plan
Staging options with trigger conditions means committing to a decision rule rather than to a fixed sequence of works. The next step is taken when the trigger fires, and not before, which is what allows a programme to stay robust when the future does not arrive as projected.
Systematic steps
1. Receive and interpret the Risk Assessment outputs
Use the risk matrix and supporting asset, system or network-level results to identify the location, magnitude, category and principal drivers of risk.
Keep the components, not just the score
The likelihood and consequence components should be retained, so that the required response is linked to the cause of the risk rather than only to an overall score.
A high score driven by likelihood calls for a different response from the same score driven by consequence. Collapsing them into one number loses the information that determines what to do.
2. Apply risk thresholds and decision rules
Compare the assessed risk against user-defined or organisational thresholds, tolerability criteria, statutory requirements, service standards, and risk appetite.
This step determines whether the risk can be accepted, or whether a defined reduction need must be established.
3. Define the risk reduction need
Translate the exceedance into a clear performance-based or outcome-based requirement. This may include:
- Reducing the likelihood of deterioration or failure
- Limiting the consequence of disruption
- Restoring asset capacity
- Improving reliability
- Meeting a statutory requirement
- Achieving a target residual-risk level within a specified timeframe
4. Identify the relevant response strategy
Screen the full range of response types:
| Response | |
|---|---|
| Accept the risk | No intervention, consciously chosen |
| Inspection or monitoring | Watch rather than act |
| Time-based maintenance | Scheduled intervention |
| Minor maintenance | Small-scale repair |
| Major maintenance | Substantial works |
| Upgrade | Improve beyond original capability |
| Renewal | Replace like for like |
| Redesign and construction | Build something different |
| Repurposing | Change what the asset is for |
Plus other context-specific measures.
5. Retrieve candidate mitigation options
Use the risk mitigation options database to identify applicable intervention types and their technical details, costs, resource needs, end-of-life implications, and expected risk reduction mechanisms.
The database should contain both standard options and asset or sector-specific measures.
6. Test options against requirements, context and constraints
Assess each candidate against operational requirements, local context, engineering feasibility, access conditions, environmental and planning constraints, safety requirements, available resources, delivery windows, and dependencies with other assets or systems.
7. Generate and screen the option shortlist
Remove options that are infeasible, non-compliant, disproportionate, or unable to achieve the required risk reduction.
Retain a transparent shortlist of technically credible options, including the evidence and assumptions supporting inclusion or exclusion.
8. Evaluate and filter the very long list
This stage systematically reviews the very long list of options identified during problem framing, and eliminates those that are clearly infeasible, ineffective, or inconsistent with the project objectives. The purpose is to focus subsequent effort on a manageable set of credible options.
The evaluation may combine:
- Option-by-option assessment matrices
- Threshold criteria and constraints
- Simple multi-stage sifting methods
- Expert judgement and stakeholder review
- SWOT analysis, covering strengths, weaknesses, opportunities and threats
Options may be screened against:
| Screening factor | |
|---|---|
| Strategic alignment | Does it serve the stated objectives? |
| Technical feasibility | Can it be built and operated? |
| Environmental constraints | Is it permissible and acceptable? |
| Deliverability | Can it actually be delivered? |
| Affordability | Is it within reach financially? |
| Stakeholder acceptability | Will the parties involved support it? |
| Consistency with problem framing objectives | Does it address the problem as defined? |
The assessment should be transparent and documented, giving a clear rationale for every inclusion and exclusion.
Consistent with NZTA guidance
The handbook notes that this approach follows NZTA guidance, where a preliminary filtering process reduces a large number of potential options before a more detailed Multi-Criteria Analysis is undertaken.
The outcome is a filtered long list of feasible options warranting detailed assessment.
9. Prepare outputs for Detailed Option Assessment
Package the shortlisted options and their comparable assessment fields, so that the optioneering stage can undertake detailed multi-criteria analysis, cost-benefit assessment, sensitivity testing and option development.
Engagement required
Interviews
| Who | What they clarify |
|---|---|
| Asset owners and asset managers | Condition, operational importance, maintenance history, risk appetite, feasible intervention windows |
| Engineers and technical specialists | Failure mechanisms, intervention applicability, design requirements, expected risk reduction |
| Operations and service teams | Access constraints, disruption tolerance, service-level requirements, emergency arrangements |
| Finance, procurement and delivery teams | Cost assumptions, resource availability, lead times, commercial constraints |
| Environmental, sustainability, planning, safety and regulatory specialists | Requirements that may affect feasibility or option performance |
Workshops
| Workshop | Purpose |
|---|---|
| Risk review | Confirm which risks exceed thresholds, and agree the required reduction objective |
| Option generation | Identify standard, innovative and cross-asset interventions |
| Constraint and dependency | Test options against system interdependencies, delivery interfaces and local context |
| Option screening | Document why options are retained, combined, deferred or rejected |
The screening workshop records reasons, not just outcomes
Its stated purpose is to document why each decision was made. That record is what allows a rejected option to be revisited later when circumstances change, instead of being silently lost.
Desk studies
- Review of the Risk Assessment, risk matrix, asset condition information, consequence analysis, inspection records, and previous incident reports
- Review of maintenance standards, design guidance, statutory duties, service requirements, previous schemes, and lessons learned
- Review of published intervention performance, deterioration models, adaptation measures, and whole-life cost evidence
- Review of environmental, planning, land, access, heritage, safety and operational constraints
Data collection
- Option-specific costs: capital, maintenance, inspection, labour, machinery, material, traffic-management and end-of-life
- Intervention performance: intervention life, deterioration reset or improvement assumptions, expected performance gain, residual-risk estimates
- Site-specific information: access, geometry, utilities, asset interfaces, demand, service disruption, construction constraints
Iterative steps
Interdependency review. Options are reassessed where they affect other assets, services, routes or systems, or where another planned intervention changes the risk reduction need.
Model calibration, scenario assumptions and option-effectiveness estimates may be revised, producing an updated impact matrix and updated option scores.
Output schema for the next process
The principal output is a structured shortlist of risk reduction options, provided at a level that allows consistent comparison without prematurely selecting a preferred solution.
| Output field | Description |
|---|---|
| Risk reference | Unique link to the relevant asset, system, route or network risk in the Risk Assessment and risk matrix |
| Risk reduction need | Clear statement of the required change, target performance, target residual risk, and relevant timeframe |
| Risk driver | The principal likelihood, consequence, capacity, performance or compliance factors driving the need |
| Candidate option ID and name | Unique identifier and concise description of each retained option |
| Response category | Accept, inspect or monitor, minor maintenance, major maintenance, upgrade, renewal, redesign and construction, or repurpose |
| Option scope | Affected assets, location, scale, interfaces and proposed implementation boundaries |
| Risk reduction mechanism | How the option reduces likelihood, consequence, exposure, vulnerability, service impact or recovery time |
| Expected risk reduction | Estimated pre- and post-intervention risk, including residual-risk category or score |
| Technical feasibility | Feasibility status, technical assumptions, dependencies and evidence base |
| Requirements and compliance | Relevant service, safety, regulatory, design and performance requirements |
| Context and constraints | Operational, spatial, environmental, access, planning, delivery and resource constraints |
| Cost fields | Capital, inspection and monitoring, maintenance, labour, machinery, materials, disruption and end-of-life costs, with uncertainty ranges where available |
| Benefit and impact fields | Expected service, safety, economic, environmental, social, sustainability and resilience benefits where relevant |
| Interdependencies | Physical, informational, geospatial, functional, logical, delivery and model dependencies |
| Implementation timing | Earliest feasible start, urgency, intervention window, duration and potential phasing |
| Uncertainty and confidence | Data gaps, uncertainty range, model confidence, and sensitivity to key assumptions |
| Screening status | Shortlisted, combined, deferred or rejected, together with the reason |
| Impact matrix reference | Reference to the option-specific impact matrix and the calibration scenarios used to generate it |
Two fields that do the heavy lifting
Risk driver and screening status with reason are what make this schema more than a list. The first keeps each option tied to the cause it addresses; the second keeps the rejected options auditable.
Without them, the shortlist records what survived but not why, which is exactly the information a challenge or a later reappraisal needs.