Risk Management Techniques in Project Planning

Risk Management Techniques in Project Planning

A poorly scoped risk register discovered at the detailed engineering gate does not protect the project — it documents the damage. The consequence is tangible: , and .

Effective risk management is not a compliance exercise. It is a structured engineering discipline that, when applied correctly, shifts decisions from reactive firefighting to proactive control.

Standards and Requirements Context

Several frameworks govern risk management practice in oil and gas project environments:

• ISO 31000 establishes the general principles and guidelines for risk management applicable across any organisation or project.
• IEC 62198 provides application guidelines for project risk management across sectors, including process industries.
• IEC 61511 governs functional safety for safety instrumented systems and requires hazard and risk analysis as the basis for safety integrity level determination — a direct input to project risk registers.
• API RP 17N covers reliability, technical risk, and integrity management for subsea production systems and provides a structured framework for risk-informed decision-making during project development.
• ISO/IEC 31010 provides a catalogue of risk assessment techniques and guidance on selecting the appropriate method for a given situation.

Where a project falls under regulatory jurisdiction — UKCS, GoM, Norwegian continental shelf — the applicable competent authority will typically require a formal safety case or equivalent document that draws directly on project risk assessments.

The Risk Management Process in Project Phases

Align the Process to the Project Lifecycle

Risk management must be phase-gated. Applying a single risk register from concept to commissioning without structured review points is a common failure mode. Each project phase — concept selection, pre-FEED, FEED, detailed design, procurement, construction, pre-commissioning — has a different risk profile, a different level of design certainty, and a different cost to act on identified risks.

At concept selection, risks are broad and strategic: reservoir uncertainty, technology readiness, regulatory pathway, partner alignment. At FEED, risks become technical and commercial: equipment long-lead procurement, interface management, ground conditions, vendor qualification. At construction, risks are largely execution-related: workforce competency, weather windows, material availability, concurrent operations.

Risk Identification Methods

The choice of identification technique should match the project phase and the nature of the hazard:

HAZOP is frequently misapplied — run too early when P&IDs are immature, or run too late when changes are prohibitively expensive. The correct trigger is a frozen, IFC-quality P&ID set.

Risk Assessment: Qualitative vs. Quantitative

For most project risks, a well-structured qualitative assessment using a consequence-likelihood matrix is sufficient and proportionate. The matrix should be calibrated to the project: consequence categories should include safety, environmental, schedule, cost, and reputational dimensions, each with defined descriptors rather than arbitrary numeric scores.

Quantitative risk assessment (QRA) is warranted when:

• The project involves novel or complex process configurations where consequence severity cannot be bounded qualitatively.
• Regulatory requirements specify it — as is common for offshore installations, LNG facilities, or densely populated onshore sites.
• A risk is close to the tolerable/intolerable boundary and the decision to proceed requires a defensible numerical basis.

The output of a QRA is only as reliable as the data and assumptions feeding it.

Risk Response Strategies

Four response strategies apply to any identified risk. The choice depends on the risk level, the cost of response, and the project's risk appetite:

Avoid — restructure the project scope or approach to eliminate the risk entirely. Applicable when the risk is unacceptably high and no credible mitigation exists within cost constraints. Example: selecting a proven technology over a novel one when the schedule cannot absorb qualification testing.

Mitigate — reduce the likelihood or consequence through engineering controls, procedural safeguards, or design changes. This is the most common response and should be costed and assigned to a specific owner.

Transfer — shift the financial consequence of the risk to a third party through contract terms, insurance, or performance guarantees. Transfer does not eliminate the risk; it reallocates the financial exposure. Technical risk remains with the project team.

Accept — acknowledge the risk and proceed without active mitigation, typically because the cost of mitigation exceeds the expected impact. Accepted risks must be explicitly documented and reviewed at each gate. Passive acceptance — where a risk is simply not addressed — is a project governance failure.

Schedule Risk and Float Management

Schedule risk is frequently underestimated because project teams confuse a deterministic critical path with a reliable forecast. A critical path model with zero float on every major activity is not a schedule — it is an optimistic aspiration.

Monte Carlo simulation applied to the project schedule generates a probability distribution of completion dates based on the range of durations assigned to individual activities. The output — a cumulative probability curve — allows the project team to select a target completion date at an appropriate confidence level rather than committing to the most optimistic scenario.

Key inputs to a credible schedule risk model include:

• Realistic three-point duration estimates (minimum, most likely, maximum) for each activity, developed by the discipline leads who own the work.
• Explicit modelling of risk events — discrete risks that, if they occur, add duration or create rework loops.
• Correlation between related activities — equipment delivery delays, for example, affect multiple downstream installation activities simultaneously.

Illustrative Scenario: Subsea Tieback FEED Risk Register

The following is an illustrative example constructed to demonstrate application of the techniques described. It does not represent a specific named project or incident.

Consider a subsea tieback project in FEED. The risk register identifies a long-lead item — a subsea control module from a single qualified vendor — as a schedule-critical procurement risk. The initial qualitative assessment places this risk in the high-consequence, moderate-likelihood cell of the project matrix.

The project team applies a bow-tie analysis: the threat is vendor manufacturing delay; barriers include early purchase order placement, contractual milestone payments, and a vendor inspection programme. The consequence, if barriers fail, is a delayed first oil date.

The response strategy selected is mitigation combined with partial transfer: the purchase order is placed at FEED completion with contractual liquidated damages for late delivery, and the schedule model is updated to include a discrete risk event representing a vendor delay scenario. The Monte Carlo output confirms that the project completion date at the required confidence level requires an additional schedule contingency beyond the deterministic critical path.

This contingency is funded explicitly in the project sanction cost estimate — not absorbed into a general contingency line that masks the specific driver.

Project Risk Management Checklist

Use the following at each project gate review:

Risk Register Quality

• [ ] All risks have a defined owner, not a team or discipline
• [ ] Consequence and likelihood ratings use the project-specific calibrated matrix, not generic defaults
• [ ] Accepted risks are explicitly documented with rationale
• [ ] The register has been updated since the previous gate

Identification Coverage

• [ ] HAZID or equivalent has been completed and findings are reflected in the register
• [ ] Long-lead equipment and single-source procurement items are captured as schedule risks
• [ ] Interface risks (between contractors, between project and operations) are explicitly listed
• [ ] Regulatory approval pathway risks are included

Schedule Risk

• [ ] Three-point estimates have been prepared for critical path activities
• [ ] A Monte Carlo simulation has been run and the target completion date is stated at a defined confidence level
• [ ] Float is not relied upon as the primary risk buffer

Response Actions

• [ ] Each high-rated risk has a documented mitigation action with a completion date
• [ ] Mitigation costs are included in the project cost estimate
• [ ] Transfer mechanisms (contracts, insurance) are confirmed, not assumed

Governance

• [ ] The risk register has been reviewed by the project sponsor
• [ ] Risks approaching the tolerable/intolerable boundary have been escalated for independent review

Conclusion

Risk management in project planning is effective only when it is continuous, phase-appropriate, and owned by the engineering team rather than delegated to a project controls function. The tools — HAZID, HAZOP, bow-tie, Monte Carlo — are well established. The failure modes are equally well established: late identification, generic matrices, unowned risks, and registers that are updated for gate reviews and then filed.

The immediate next step for any project team reviewing their current approach is to audit the risk register against the checklist above and ask a direct question for each high-rated risk: who owns this, what is the mitigation action, and is that action funded and scheduled? If the answer to any part is unclear, the risk is not managed — it is recorded.