Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
IEC 62198: Project Risk Management — Application Guidelines for Engineering Projects
A practical framework for identifying, analysing, and responding to risks in engineering and technology projects
IEC 62198, published in 2013, provides application guidelines for project risk management. While the generic ISO 31000 standard defines risk management principles and framework, IEC 62198 translates these into practical guidance specifically tailored for project environments — from engineering and construction projects to software development, technology deployment, and system integration initiatives. The standard adopts the widely recognised risk management process: establish context, identify risks, analyse risks, evaluate risks, and treat risks, with continuous communication and monitoring throughout the project lifecycle.
What makes IEC 62198 particularly valuable for engineers and project managers is its emphasis on the project-specific context. Unlike generic risk management standards, it recognises that projects are inherently unique, time-constrained, and resource-limited endeavours where risks evolve dynamically as the project progresses through its phases. The standard provides detailed guidance on how to establish the risk management framework within the project governance structure, including role definitions, documentation requirements, and escalation procedures tailored to project size and complexity.
IEC 62198 is applicable to all types of projects, regardless of size, complexity, or industry sector. The standard can be used for both the overall project level and individual work packages or activities within a larger programme. It is designed to be compatible with existing project management methodologies such as PMBOK, PRINCE2, and ISO 21500 (Guidance on Project Management).
The Risk Management Process and Implementation
The standard structures the risk management process around six core activities. The first, establishing the context, involves defining the project objectives, identifying internal and external factors that influence risk exposure, and setting the risk criteria — the thresholds for acceptable risk that will guide decision-making throughout the project. Risk criteria must consider legal and regulatory requirements, stakeholder tolerance for uncertainty, technical complexity, contractual constraints, and the project budget and schedule sensitivity. For large engineering projects, this phase should also define the risk classification taxonomy, such as technical risks, schedule risks, cost risks, legal risks, and force majeure events, ensuring consistent categorisation across the project organisation.
Risk identification aims to generate a comprehensive list of risks based on events that might create, enhance, prevent, degrade, accelerate, or delay the achievement of project objectives. The standard recommends a combination of techniques: structured brainstorming with cross-functional teams, the Delphi method for expert elicitation, checklists based on historical data from similar projects, SWOT analysis (strengths, weaknesses, opportunities, threats), and scenario analysis. For engineering projects, technical risk identification should involve domain experts who understand the specific technologies, interfaces, failure modes, and performance uncertainties inherent in the project scope.
| Technique | Best Suited For | Output Format | Key Advantage |
|---|---|---|---|
| Brainstorming | Early project phases, cross-functional teams | Risk list with initial classification | Broad coverage, team buy-in |
| Delphi method | Novel or complex technical areas | Anonymised expert consensus | Eliminates groupthink bias |
| Historical checklists | Projects with similar precedents | Structured risk register | Leverages past experience |
| SWOT analysis | Strategic and program-level planning | Strategic risk map | Links risks to project objectives |
| Scenario analysis | High-uncertainty environments | Multiple future-state narratives | Captures cascading risk interactions |
| HazOp (for engineering) | Process, system, and design reviews | Detailed deviation analysis | Systematic, guideword-driven |
A common failure in project risk management is treating risk identification as a one-time exercise at project initiation. The standard emphasises that risks must be continuously identified and reassessed throughout the project lifecycle. Industry data shows that over 40% of significant project risks are first identified outside the initial planning phase — during detailed design, prototyping, testing, or commissioning. Weekly or bi-weekly risk review cycles are recommended for medium-to-large engineering projects.
Risk analysis involves developing understanding of each risk. The standard distinguishes between qualitative analysis (risk rating using probability and impact scales) and quantitative analysis (numerical modelling of risk impacts using techniques such as Monte Carlo simulation, decision tree analysis, or sensitivity analysis). For engineering projects, quantitative analysis is particularly valuable for cost and schedule contingency estimation, where the combined effect of multiple risks can be modelled probabilistically. The output of the analysis phase is a prioritised list of risks that informs where to focus management attention and resources.
A well-implemented risk management process following IEC 62198 can provide: a 15-25% reduction in cost overruns, a 20-30% improvement in schedule predictability, and significantly fewer late-stage design changes. These benefits are documented across multiple industry studies of engineering projects that adopted structured risk management practices. The return on investment for risk management activities typically ranges from 5:1 to 10:1 for capital-intensive engineering projects.
Risk Response and Engineering Design Insights
Risk treatment (response) involves selecting and implementing measures to modify risk. The standard identifies four primary response strategies: avoid (eliminate the threat by changing the project plan), mitigate (reduce probability or impact), transfer (shift the risk to another party, typically through insurance or contractual provisions), and accept (acknowledge the risk and budget for consequences). For opportunities (positive risks), the corresponding strategies are exploit, enhance, share, and accept. The standard emphasises that response selection must be cost-effective, timely, realistic, and agreed upon by relevant stakeholders.
| Risk Type | Strategy | Engineering Example | Implementation Consideration |
|---|---|---|---|
| Threat (negative) | Avoid | Eliminate unproven technology from design | May reduce performance or increase cost |
| Threat (negative) | Mitigate | Add redundancy to critical subsystems | Increases complexity and testing scope |
| Threat (negative) | Transfer | Fixed-price contract for high-risk scope | May increase procurement cost |
| Threat (negative) | Accept | Establish contingency budget/time reserve | Requires management approval |
| Opportunity (positive) | Exploit | Accelerate schedule using proven innovation | Requires early resource commitment |
| Opportunity (positive) | Enhance | Invest in prototyping to discover improvements | Increases front-end spending |
From an engineering perspective, several insights emerge from applying IEC 62198 to technical projects. First, technical risks — those related to design uncertainty, technology maturity, system integration complexity, and performance margin verification — tend to be the most impactful and should receive priority attention. The use of Technology Readiness Levels (TRLs) as a systematic framework for assessing technical risk maturity is strongly recommended, with clear criteria for transitioning between readiness levels tied to verification and validation milestones.
Second, risk interdependencies must be explicitly modelled. In complex engineering systems, individual risks rarely occur in isolation. A delay in a critical component delivery (supply chain risk) can trigger cascading effects on integration testing schedules (schedule risk), which in turn may force parallel testing strategies that increase costs (cost risk). The standard recommends using risk dependency mapping techniques such as bow-tie analysis, influence diagrams, or Bayesian belief networks to capture these relationships, enabling more accurate overall risk exposure assessment.
Third, risk communication and reporting structures must be tailored to different stakeholders. Executive sponsors need aggregated risk dashboards highlighting top-tier exposures and critical decisions. Project managers require detailed risk registers with assigned owners, planned responses, and current status. Technical leads need risk-action lists focused on the specific risks within their domain of responsibility. The standard recommends a three-tier reporting structure aligned with the project work breakdown structure, ensuring that risk information flows effectively between technical teams, project management, and governance bodies.
Fourth, the standard emphasises that risk management should be integrated with other project management processes: change management (design changes often introduce new risks), configuration management (baseline changes affect risk exposure), quality management (non-conformances are realised risks), and procurement management (supplier risks require specific treatment strategies). This integration ensures that risk management is not a standalone bureaucratic exercise but an integral part of project decision-making.
Q1: How does IEC 62198 differ from ISO 31000?
A: ISO 31000 provides the generic principles and framework for risk management applicable to any organisation. IEC 62198 tailors these principles specifically to project environments, with practical guidance on risk identification techniques, analysis methods, response strategies, and documentation suited to the time-constrained, unique nature of projects.
A: ISO 31000 provides the generic principles and framework for risk management applicable to any organisation. IEC 62198 tailors these principles specifically to project environments, with practical guidance on risk identification techniques, analysis methods, response strategies, and documentation suited to the time-constrained, unique nature of projects.
Q2: Is IEC 62198 applicable to agile software development projects?
A: Yes. While originally developed with traditional project management in mind, the standard’s principles are adaptable to agile frameworks. Risk identification and analysis are incorporated into sprint planning, and risk review cycles can be aligned with sprint retrospectives. The key adaptation is that risk response planning must fit within the shorter agile planning horizon.
A: Yes. While originally developed with traditional project management in mind, the standard’s principles are adaptable to agile frameworks. Risk identification and analysis are incorporated into sprint planning, and risk review cycles can be aligned with sprint retrospectives. The key adaptation is that risk response planning must fit within the shorter agile planning horizon.
Q3: What is the recommended level of detail for a project risk register?
A: The standard recommends that each risk entry include: unique identifier, description, root cause, probability rating, impact rating, risk level (probability x impact), risk owner, planned response strategy, response actions, current status, and a risk trigger that signals when the response should be activated. For large projects, a risk register with 100-300 entries is typical.
A: The standard recommends that each risk entry include: unique identifier, description, root cause, probability rating, impact rating, risk level (probability x impact), risk owner, planned response strategy, response actions, current status, and a risk trigger that signals when the response should be activated. For large projects, a risk register with 100-300 entries is typical.
Q4: How should contingency reserves be determined from risk analysis?
A: IEC 62198 recommends using quantitative risk analysis (e.g., Monte Carlo simulation) to determine contingency. The P50 (50th percentile) to P80 (80th percentile) range of the cumulative cost distribution is commonly used, depending on organisational risk appetite. For schedule contingency, the difference between the deterministic critical path and the probabilistic P80 completion date is the recommended schedule reserve.
A: IEC 62198 recommends using quantitative risk analysis (e.g., Monte Carlo simulation) to determine contingency. The P50 (50th percentile) to P80 (80th percentile) range of the cumulative cost distribution is commonly used, depending on organisational risk appetite. For schedule contingency, the difference between the deterministic critical path and the probabilistic P80 completion date is the recommended schedule reserve.
