The risk analysis process is broken down into six steps, outlined in the figure below. This page provides guidance on how the Project Team should undertake this process.
The Project Team must undertake the risk analysis process in an informed, careful and robust way so contingency allowances are not over- or under-estimated. To this end, the risk analysis process should involve key stakeholders and specialists across the full Infrastructure Investment Lifecycle. The Project Team may wish to engage well-qualified and experienced advisors to undertake informed, robust and defensible risk analysis.
Risk analysis process
Each of the six steps in the risk analysis process identified above occurs at different points within the overarching stages of the Infrastructure Investment Lifecycle. Initially, the Project Team identifies preliminary project risks as part of Stage 1 – Develop of the Capital Framework. The Project Team then undertakes Steps 1 to 5 of the risk analysis process as a part of Stage 2 – Prove of the Capital Framework, building on the risks identified in Stage 1 – Develop. Although these steps are set out consecutively, the Project Team may undertake them concurrently, if it is practical to do so.
Although risk analysis is a linear process, it is also a dynamic one. Step 6: Review is an ongoing process and must be continually undertaken throughout the Infrastructure Investment Lifecycle. Through Stage 3 – Procure and Stage 4 – Implement of the Infrastructure Investment Lifecycle, the Project Team should ensure the Risk Register is reviewed regularly and updated as required, which may involve the inclusion of new risks made apparent through procurement and implementation. This may require the Project Team to review the Risk Register and re-take Steps 1 to 5 at further points in the Infrastructure Investment Lifecycle.
Before the risk analysis process commences
Before the risk analysis process commences, the Project Team should define the context for analysing risk. This should involve the Project Team considering and assessing:
- The objectives of the risk analysis process
- The scope of the risk analysis process
- The key stakeholders of the risk analysis process
- The internal and external environment of the project.
Step 1: Identify
As the first step of the risk analysis process, the Project Team should identify the potential risk sources and resulting risk events associated with the project, their corresponding Consequences and Likelihoods, and current Controls and possible Treatments. The output of this step is a Risk Register, which documents the outputs of the entire risk analysis process. It typically takes the form of a table listing each identified risk and including for each risk:
- A detailed description of the risk or uncertainty, including the risk category or project phase to which the risk applies (e.g. procurement, approvals, design, construction, planning, etc.)
- The source of the risk (i.e. how would the risk come about?)
- A detailed description of the risk Consequences (undertaken as part of Step 2)(i.e. what would happen should the risk event eventuate?)
- The owner of the risk
- Any risk Controls and/or Treatments
- The Consequence rating and Likelihood rating of the risk occurring, and the resulting Impact rating of each risk (undertaken as part of Step 2)
- The proportional allocation of each risk between the private and public sectors (undertaken as part of Step 4).
The Risk Register is a live document, which is updated and refined through Steps 2 to 6. Step 1 should evolve over the course of the project’s lifecycle, as the Project Team undertakes further project analysis and as the project achieves key milestones during design, procurement and delivery.
For Tier 1 projects, if the project options have significantly differing risks, the Project Team should compile a Risk Register for each individual shortlisted project option.
The Project Team should identify the risks that could affect the project in achieving its objectives (including the implicit objectives) or expected outcomes across the project’s lifecycle. If the Project Team identifies risks that are not aligned to the objectives of the project (also known as systemic risks), these risks may be too broad and:
- Not necessarily relevant to the specific scope of the project; or
- Not measurable.
For example, the risk that electricity outages due to storms and bushfires affect the production of supplies required for the construction of a transport project is a systemic risk that should not be included in the project’s Risk Register.
Risk identification process
The Project Team should collect any available investigations, data and analysis that have been undertaken on the project or relevant information from similar projects to identify risks. The Project Team should then identify risks through informed discussions with key stakeholders. These stakeholders may include:
- Representatives of the Sponsoring Agency
- FABG
- iCBR
- ICA
- Where appropriate, any external or internal advisors (e.g. design team or technical consultants)
- Agencies that may be involved in the project’s planning, delivery or operations
- End user groups (if appropriate).
When identifying risks, the Project Team should carefully consider all potential sources of risk to ensure that all relevant risks are captured. The Project Team should frame each risk in terms of an event that would occur if the risk materialises. The examples in the table below are framed in this way.
When identifying the risks associated with the project, the Project Team should consider a variety of types of risks. The table below provides a non-exhaustive list of the types of risk that the Project Team could consider in this step and some examples of how the risk may lead to a Consequence. The Project Team should categorise risks based on their drivers and the timing of when each risk may eventuate along the Infrastructure Investment Lifecycle.
Type of risk category | Risks | Example risks and Consequences |
|---|---|---|
Design risk | Risks associated with the design of the project | Design fails to comply fully with a regulation and this is not picked up until later in construction, requiring remediation – for example, additional works for groundwater management |
Planning risk | Risks associated with the planning approvals required to progress the project to implementation | Planning permissions are granted but require additional capital expenditure – for example, on intersecting transport infrastructure and services – or take longer to achieve than expected |
Procurement risk | Risks associated with processes for procurement of the project | Inadequate procurement documentation leads to delays due to the need to issue addenda and/or low market interest |
Environmental and heritage risk | Risks associated with the impact of the project on the natural environment, flora and fauna, Aboriginal cultural heritage or historical heritage | An unidentified archaeological artefact is found on the site during site excavations, leading to increased costs and delays while it is investigated |
Stakeholder risk | Risks associated with the varying and conflicting interests of stakeholders, including governance arrangements | Environmental groups protest against the project and delay or stop its commencement |
Site risk | Risks associated with the condition of the site | Additional services are found on site during ground works or services identified are not in the location shown on site plans, leading to costs of diversion and delays |
Construction risk | Risks associated with the construction and delivery of the project | Inadequate oversight arrangements of the service provider leads to the service not being delivered as agreed to within the contract, resulting in a failure to meet legislative requirements, increasing the project costs and causing delays |
Safety risk | Risks associated with the safety of the ACT community, workforce and others | Machinery is not stored in the appropriate location resulting in work, health or safety hazards for construction workers |
Climate risk | Risks associated with the physical and economic impacts of natural hazards and climate change | There are acute and chronic risks associated with climate change.
The Office for Climate Action has developed guidance on climate risk |
Market risk (Footnote: Although the Project Team can identify market risks, and other risks associated with private sector engagement, the Project Team should not quantify these risks as part of the contingency allowance. These risks are considered as part of the Delivery Model Analysis and are factored into the discount rate for the associated Financial Analysis, where relevant. ) | Risks associated with the wider market, including the supply of labour, materials and equipment needed to undertake the project | Inability to access materials for construction or market demand for engineers and/or other labour restricts the supply available to manage the project, increasing materials and labour costs and leading to greater project costs and delays |
Financial risk | Risks associated with the financial sustainability and structure of the project (including alternative financial instruments), such as interest rates, timing of cashflows and taxation treatments | Fluctuating interest rates result in additional costs to service loans, leading to financial instability of the project |
Operational risk (Footnote: The inclusion of operational risks in the Risk Register depends on the delivery model selected and the funding that is being sought in the Business Case. ) | Risks associated with the operations and implementation of the project once delivered | Operations of the project are not undertaken to the standard required due to the inadequate training of operational employees, leading to customer dissatisfaction and reputational damage |
Maintenance risk | Risks associated with ongoing maintenance of project assets | Inadequate maintenance of an asset to the manufacturer’s instructions results in wear and tear that causes its replacement sooner than its design life |
Decommissioning risk | Risks associated with decommissioning of project assets | Decommissioning of contaminated waste at the end of the project is not accounted for – for example, landfill materials are found to contain contamination – leading to increased costs |
The Project Team may also wish to include ‘positive risks’, or opportunities, in the risk analysis. However, it is critical that the Project Team ensure that potential opportunities are not over-stated – refer to the information on optimism bias in in Step 2: Analyse section below. The Project Team should identify opportunities in a similar way to identifying risks, and frame any opportunities identified in terms of an event that would occur for the opportunity to materialise. For the purpose of risk analysis, opportunities relate to the potential for cost or time savings during the project’s implementation and not to the benefits that the project will deliver to the community.
Identify uncertainties
The Project Team should assess the extent to which uncertainty exists and the potential impacts that could be attributed to those uncertainties. The Project Team should aim to reduce the level of uncertainty through good planning and risk analysis. Where the extent of uncertainty significantly reduces the ability to price a proposal accurately, the Project Team should consider building in options that allow for decisions to be taken when uncertainties are resolved. For example, this could involve further research, pilot studies or staged development that gives Government future flexibility.
The Project Team should document the recommended strategies to deal with these uncertainties and how the project could adapt, should those strategies be unsuccessful. The Project Team should also document the events / outcomes that would trigger the project to be reassessed.
Identify risk Controls and Treatments
Residual risks are the risks that remain after planned Controls and Treatments have been implemented. Wherever possible, the Project Team should mitigate identified risks so that the level of residual risk is reduced. When undertaking the risk analysis process, the Project Team must be clear on what risk Controls have been implemented and what risk Treatments will be implemented, and their effect on the risk rating.
Examples of Controls and Treatments include:
- Taking additional steps in design
- Project management initiatives
- Stakeholder engagement or management
- Technical analysis or surveys.
This means that, when analysing risks in the next step, the Project Team should focus on residual risks—those that cannot be controlled or treated fully at any given stage. Where possible, each risk should be allocated a Control and/or a Treatment.[3] As Controls and Treatments are implemented, the Project Team should update the Risk Register and undertake Steps 2 to 6 again (see Step 6: Review section).
The Project Team should document Controls and Treatments in enough detail to ensure the continuous monitoring and review of the Control and for the Treatment to be implemented as intended. This should include setting a due date for implementation of the recommended Treatment and nominating an individual who is responsible for the implementation. The Project Team should monitor Controls and Treatments to ensure the risks are being adequately managed and the Controls and Treatments continue to be effective.
In relation to ‘positive risks’, or opportunities, the Project Team should identify any strategies that would increase the Likelihood that the opportunity can come to fruition.
Step 2: Analyse
The second step of the risk analysis process requires the Project Team to determine the Consequence and Likelihood of each risk that has been identified and subsequently update the Risk Register developed in Step 1.
The Project Team must analyse each risk by identifying the Consequence and Likelihood of it occurring. The Project Team ideally should identify first the Consequence of a risk and then the Likelihood of that Consequence occurring. The Project Team may need to undertake further analysis or investigation to ensure that all risks are analysed accurately. The Consequence and Likelihood ratings applied to each risk should reflect the residual risk—that is, the Consequence and Likelihood of the risk once any planned Controls or Treatments are implemented.
In terms of Consequence, a risk occurring can:
- Affect project cost
- Cause a delay
- Affect the quality of project delivery
- Affect the ACT community
- Affect Government’s reputation
- Lead to compliance and regulation issues (e.g. non-compliance)
- Cause work, health and safety issues
- Affect or damage the environment
- Lead to Aboriginal cultural or historical heritage impacts.
The Consequences included in the Risk Register should reflect the effect on the project objectives (including implicit objectives) or outcomes if the risk eventuated.
The Project Team should convert non-monetary Consequences to monetary equivalents in order to determine an appropriate level of project contingency allowance. For example, the Project Team may estimate the monetary equivalent of a delay Consequence by assessing the costs incurred as a result. This may include indirect costs incurred during the project’s construction over the delay period, such as overheads, security or supervision costs, and insurance, as well as the opportunity cost of delaying the start of operations, which may be estimated as the cost of operations.
The Consequence rating system applied to a project should be bespoke for each project and should be determined in collaboration with the key project stakeholders. The Project Team should define the rating system prior to allocating ratings to any risks. An example is provided in the table below.
Consequence | Capital cost impact | Recurrent cost impact |
|---|---|---|
Insignificant An event, the impact of which can be absorbed through normal activity | Less than 2.5% of total capital costs, or less than $5,000, whichever is the greater | Less than 2.5% of total annual costs during operations and maintenance |
Minor An event, the consequence of which can be absorbed but management is required to minimise the impact | At least 2.5% but less than 5% of total capital costs, or at least $5,000 and less than $50,000, whichever is the greater | At least 2.5% but less than 5% of total annual costs during operations and maintenance |
Moderate A significant event that can be managed under normal circumstances | At least 5% but less than 10% of total capital costs, or at least $50,000 and less than $500,000, whichever is the greater | At least 5% but less than 10% of total annual costs during operations and maintenance |
Major A critical event that with proper management can be endured | At least 10% but less than 25% of total capital costs, or at least $500,000 and less than $5 million, whichever is the greater | At least 10% but less than 25% of total annual costs during operations and maintenance |
Catastrophic A disaster with potential to lead to collapse of the project | At least 25% of total capital costs or at least $5 million, whichever is the lesser | At least 25% of total annual costs during operations and maintenance |
The Likelihood of each risk should reflect the probability of that risk’s Consequence eventuating. The Project Team should apply the rating system in an objective and consistent manner across risks.
The Likelihood rating system should be aligned with the standard ACTIA rating system. If the Project Team wants to deviate from the standard Likelihood rating system, this should be discussed with FABG, iCBR and ICA. The Project Team should define the rating system prior to allocating ratings to any risks. An example is provided in the table below, which has been informed by the ACTIA Likelihood Criteria.
When assessing the Likelihood that the project will be exposed to each specific risk, the Project Team should consider the risk Controls in place and the risk Treatments planned to be implemented, and the history of any previous similar project.
Where the Project Team has rated a risk Consequence with an Almost Certain Likelihood, the Project Team should include the risk Consequence as a cost within the raw cost estimate, rather than as part of the contingency allowance. This Likelihood rating is only used during risk monitoring and reporting to reflect developments that lead to an actual increase in the probability of the risk occurring. For example, once technical engineering works are completed, more information may be available about the level of contamination present on site, which may result in an increased Likelihood for contamination risks.
Likelihood | Historical frequency | Expectation | Indicative frequency | Probability of occurrence |
|---|---|---|---|---|
Rare | The event has never occurred here, but may have/has occurred somewhere | The event might occur but only in exceptional circumstances. It would be very surprising if the event occurred | 1 in every 100 years or less | 0-1% |
Unlikely | The event has never occurred here | The event might occur, but it is unlikely. It would be surprising if the event occurred | 1 in every 10-100 years | 1-10 % |
Possible | The event infrequently occurs here | The event could occur at some time in the future. It would not be surprising if the event occurred | 1 in every 4-10 years | 10-25% |
Likely | The event occurs on some occurrences of the activity | The event is expected to occur on one of the next few occasions | 1 every year to 4 years | 25-75% |
Almost Certain | The event occurs on most occurrences of the activity | The event is expected to occur this time | 1 every year or more | 75-100% |
The Project Team should document the findings of the above analysis in the Risk Register.
Based on the Consequence and Likelihood rating of each risk, the Project Team should identify and document the risk Impact rating (ranging from low to extreme) within the Risk Register, using the matrix below, which is informed by the ACTIA Risk Matrix (Footnote: The Project Team should note that the ACTIA Risk Matrix represents a set of generic parameters for risk-based decision making within Government. In some circumstances, it may be appropriate for the Project Team to adopt the Matrix and tailor the Consequence categories to fit within the context of the project. ) .
Risk Impact matrix
Once the Consequence and Likelihood of occurrence have been allocated to each risk, the Project Team can proceed to determine an appropriate level of contingency allowance. For risks that have multiple potential Consequences, the Project Team should select the risk Consequence that has the highest risk Impact rating to use in determining the contingency allowance.
Optimism bias
Infrastructure projects are inherently risky due to their long planning horizons, imperfect information, complex interfaces and reliance on users’ behaviours to determine the level of their benefits. These various technical factors should, in theory, be unbiased, in that they should be as likely to lead to overestimated costs and underestimated benefits as to underestimated costs and overestimated benefits. However, in practice, this is not the case. Nevertheless, such technical factors are often cited as reasons for cost overruns and failures to achieve the expected levels of benefits.
Optimism bias is a cognitive bias that refers to the tendency to underestimate the likelihood of experiencing adverse events. In relation to infrastructure planning, optimism bias may lead to the underestimation of costs and/or risks, or the overestimation of project benefits. (Footnote: Australian Transport Assessment and Planning (ATAP), Optimism Bias, July 2016 )
The Project Team should be aware of the impact of optimism bias in estimating the Consequence and Likelihood of each project risk identified through the risk analysis process, as well as identifying opportunities. The impact of optimism bias during risk analysis may include an underestimation of the Consequence and/or Likelihood of various risks, leading to insufficient contingency allowances being set aside to cover the Impact of risks eventuating.
The Project Team can mitigate the impact of optimism bias through one or more of the following actions:
- Maintaining an awareness of the risk of optimism bias
- Ensuring best practice techniques and the best available data are used to estimate the Consequence and Likelihood for each risk
- Clarifying and documenting assumptions underpinning the chosen Consequence and Likelihood ratings for each risk
- Comparing outcomes of the risk analysis with evidence from elsewhere, including recent similar projects
- Ensuring stakeholders with the necessary technical, costing and other relevant skills are involved in the risk analysis process
- Using independent peer reviews (where practical) to verify the outcomes of risk analysis
- Testing the robustness of risk analysis outcomes through sensitivity testing.
Additional resources on optimism bias have been developed by ATAP (Footnote: Ibid. ) and the UK Department for Transport. (Footnote: The British Department for Transport, Procedures for Dealing with Optimism Bias in Transport Planning: Guidance Document, June 2004)
The opposite of optimism bias is pessimism bias, which is a cognitive bias that refers to the tendency of some people to overestimate the Consequence severity or Likelihood of experiencing adverse events. The above actions to mitigate the impact of optimism bias should also be used to address potential pessimism bias in the risk analysis process.
Step 3: Quantify
The third step of the risk analysis process requires the Project Team to estimate contingency allowances for the project option(s), based on the risk analysis undertaken as part of Step 2.
In some cases, particularly for larger or more risky projects, the analysis required to quantify risks and develop contingency allowances can be complex and technical in nature. The Project Team may wish to engage external advisors with experience in risk analysis. ICA can also assist the Project Team in risk quantification and calculation of contingency allowances.
Develop contingency allowances
The cost estimates for all projects must include a contingency allowance that reflects the risks associated with the project option(s).
Any excess contingency allowance (for example, that results from a reassessment of risks following achievement of a major project milestone) generally is not available to increase the scope of the project. Only Government (Cabinet or the relevant Minister with the agreement of the Treasurer) can authorise a substantive change in scope relative to the budget approved scope, or the transfer of any excess contingency allowance to another project. Otherwise, the Project Team must return any such excess to the Budget.
As already noted, there are two methods the Project Team can use when determining the contingency allowance, depending on the project’s Tier: the stochastic (Footnote: A stochastic process is one that uses a random sampling of a pre-defined probability distribution to give a result that may be analysed statistically but may not be predicted precisely. ) (probabilistic) method or the deterministic method. The following sections provide guidance on how to use each method.
Approach | Description |
|---|---|
Stochastic Required for Tier 1 projects Recommended for Tier 2 projects, particularly those that are not ‘Business-as-Usual’ | A stochastic approach is a more project-specific and accurate model of the volatility and variability of the possible Impact that the risks will have on the expected project cost and whole-of-life cost estimates. This approach is based on a bottom-up method (i.e. the level of contingency funding is determined based on the specific characteristics of the project). This should use Monte Carlo analysis. Monte Carlo analysis is a statistical technique that uses repeated random sampling of multiple probability distributions of the inputs to a computer model to obtain probability distributions of the outputs of that model. The Monte Carlo analysis must be a bottom-up assessment based on the risks identified in the Risk Register, rather than an assessment based on the cost estimate or the inherent risks associated with the cost estimate. Monte Carlo analysis is generally undertaken using specialist computer modelling software. It generates a range of project outcomes, based on the Consequence and Likelihood of the project risks, as identified in Step 2 of the risk analysis process. The outcome of this analysis is a probability distribution curve of expected costs, which can be used to determine the level of contingency funding that provides the desired level of confidence that it will not be exceeded (i.e. the required P-level). This contingency funding seeks to ensure that the project can still be delivered in the event that the project’s risks are realised. To undertake Monte Carlo analysis, the Project Team must identify a probability distribution against the Consequence (based on Example Consequence rating system table) and an appropriate percentage probability of a risk’s Consequence occurring (based on Example Likelihood rating system table using the risk Likelihood). The Project Team should engage suitably qualified expertise and reviewers to conduct and verify the stochastic quantification of contingency allowances. ICA can assist if necessary. |
Deterministic Recommended for Tier 3 projects May be used for Tier 2 projects as agreed in the EPP | Although a stochastic method can and should be used if it is reasonable and affordable for the Project Team to do so, the Project Team may estimate the contingency allowance using deterministic methods for Tier 3 and some Tier 2 projects. The simplest deterministic method is the fixed percentage calculation. However, this method is not favoured and when possible, the Project Team should adopt more rigorous deterministic methods in determining the required contingency funding, which are explained further below. The fixed percentage calculation is useful when there is a lack of information on the risks associated with the project. The contingency allowance is calculated by multiplying the raw capital or whole-of-life cost estimate by an appropriate percentage figure. This percentage figure will be specific to each project but should be informed by the risks identified, their Consequence and Likelihood ratings, industry benchmarks, the level of design and nature of the project, and consideration of precedent projects. These precedent projects are previous projects that the Sponsoring Agency or another Government Agency has undertaken that are comparable to the current project in their scope, cost and qualitative risks. Where this approach is used, the derivation of the percentage figure should be clearly outlined. The Project Team should consider the contingency allowance of such precedent projects to derive an appropriate percentage of risk contingency for the project. The Project Team should also consider the actual project cost outturns of precedent projects against their budgets (from the perspectives of both the public sector and the private sector contractor) to determine if the contingency allowances included were appropriate. Where possible, the percentage figure should be advised by a cost estimator or quantity surveyor. |
Where a stochastic approach to determining the contingency allowance is being used, the Project Team should quantify the Consequences and Likelihoods of risks with ‘High’ or ‘Extreme’ Impacts (Footnote: As defined by the ACTIA Risk Management Policy ) for inclusion in the Business Case. (Footnote: ‘Medium’ Impact risks may also be quantified. This should be discussed with FABG, iCBR and ICA. ) Additionally, there may be further unquantifiable uncertainties that the Project Team should identify and assess qualitatively. The Project Team should develop an estimate for the total contingency allowance of the project, which will be either retained by Government or allocated to the private sector.
Often, quantity surveyors will add a general contingency (e.g. 10%) across cost estimates that they prepare. For projects where a quantity surveyor has prepared the cost estimates, the Project Team must ensure that any general contingency included by the quantity surveyor has been removed before the contingency allowance is added, to avoid doubling up and to enable proper stochastic analysis.
Verify contingency allowances (following a stochastic approach)
Where the Project Team has used a stochastic approach, it should verify the appropriateness of the contingency allowance in the form of a top-down assessment. This involves reviewing the figure against industry benchmarks, precedent projects and / or literature reviews – similar to a deterministic approach to estimating a contingency allowance.
This sense check assists the Project Team in identifying and overcoming optimism and pessimism biases and increases confidence that the Risk Register and contingency allowance are appropriate. The Project Team must provide evidence in the Business Case supporting the rationale for the contingency allowance estimated.
The figure below shows the possible relationship between the level of the project’s development and the estimated contingency allowance as a proportion of project capital cost. The Project Team may use this figure to verify the contingency allowances.
Relationship between the level of project development and typical proportion of contingency
The contingency allowances above are broadly supported by research undertaken by the University of Melbourne, (Footnote: National PPP Forum – Benchmarking Study, Phase II: Report on the performance of PPP projects in Australia when compared with a representative sample of traditionally procured infrastructure projects, University of Melbourne, December 2008 ) which reviewed the cost performance of a stratified sample of infrastructure projects delivered using Traditional models. The results, shown in the table below, clearly demonstrate that cost overruns are significant for most projects, but become smaller as the project becomes better defined.
Cost overrun (%) | Original announcement – actual final (roughly, end Stage 1 – end Stage 4) | Budget approval – actual final (end Stage 2 – | Contractual commitment – actual final (end Stage 3 – |
|---|---|---|---|
Average* | 52.0% | 19.7% | 18.0% |
Median (P50) | 10.1% | 4.0% | 3.6% |
Lower quartile (P25) | 0% | 0% | 0% |
Upper quartile (P75) | 42% | 28% | 17% |
*The average is affected by some projects having a very large cost overrun
Identify the appropriate P-value (Tier 1 and Tier 2)
For Tier 1 and Tier 2 projects, the recommended P-value is P90 (see box below). The use of the P90 value provides an appropriate balance between minimising the potential for the project to require additional budget funding and not tying up scarce budget funds unnecessarily. Any exception to the use of P90 for the expected project capital cost and whole-of-life cost estimate must be discussed and agreed with FABG, iCBR and ICA.
What is a P-value?
The P-value represents a level of confidence in which the actual costs will be less than or equal to the estimated cost.
- P50 is a mid-point estimate. It represents the project contingency with sufficient risk provision to provide a 50% level of confidence in the outcome—i.e. that there is a 50% likelihood that the project contingency will not be exceeded, and a 50% probability that it will be exceeded.
- P90 represents the project contingency with sufficient risk provision to provide a 90% level of confidence in the outcome—i.e. that there is a 90% likelihood that the project contingency will not be exceeded. In other words, it represents a conservative position that has an anticipated 10% chance of being exceeded.
Step 4: Allocate
The fourth step of the risk analysis process is for the Project Team to determine the allocation of the risks between the private and public sectors.
The allocation of risks between the private and public sectors depends largely on the delivery model. Although an allocation should be made to determine an appropriate contingency allowance based on the recommended delivery model, the ability to allocate risks to the private sector is dependent on:
- The changing risk appetites of market participants over time, particularly in response to the occurrence of significant risks both in Australia and globally
- The capability of the private sector counterparty to manage the risk allocated to it
- The financial capacity of the private sector counterparty to absorb the risk should it eventuate
- The robustness of the contractual arrangement of the delivery model in terms of the Territory’s ability to enforce the allocation of risk to the private sector.
The Project Team should allocate each risk between:
- Fully retained, and therefore managed, by the Territory
- Borne entirely by the private sector
- Shared between the Territory and the private sector.
The Project Team should note that the Territory retains overall responsibility for all risks, even when management of some risks may be transferred to the private sector. Government retains the responsibility and accountability to ensure that the risks that are allocated to the private sector are appropriately managed – for example, through the contractual agreements in place between Government and the private sector. The Project Board or ESC has oversight responsibility to ensure risk reviews are being undertaken periodically by the Project Team and that risk Controls and Treatments are being managed adequately by the responsible individuals (refer to the Project Governance Guidelines for further information).
Step 5: Document
Once the Project Team has allocated all risks as part of Step 4, it should update and finalise the Risk Register. The Project Team can then document the finalised required contingency allowance (both cost and time) for Government, based on the risks that have been retained.
Step 6: Review
At key points of the Infrastructure Investment Lifecycle, the Project Team should ensure that it reviews and updates the Risk Register and the project’s contingency allowance. It is critical that this is completed periodically to ensure that the Risk Register is current and accurate.
The Project Team should ensure that the contingency allowance is updated at key milestones. These milestones may include:
- Design finalisation
- Contract execution
- Receipt of planning approvals
- Commencement of construction
- Completion of subterranean works / construction out of the ground
- Commencement of commissioning or operations.
Updating the contingency allowance on this basis helps to ensure that the level of budget funding for the project remains appropriate. However, doing so requires substantial analysis, so Project Teams generally should not undertake such updates more than annually.
Risk review mechanisms
The Project Team should implement risk reporting, escalation and funding review mechanisms that will facilitate the ongoing review of the Risk Register and contingency allowances. The role of the Risk and Change Management Committee (RCMC) (which may also go by other names) is to review and approve or endorse the project and risk expenditure within the project’s contingency allowance. Refer to the Project Governance Guidelines for further information about the RCMC.
These mechanisms should provide the arrangements for the Project Team and other stakeholders to implement the activities stipulated below for the review of the Risk Register, the review of the contingency allowances and any release of funding, request for further funding and value or cash management exercises required.
Review of the Risk Register
The Project Team should continually ensure that the Risk Register is kept up to date. To monitor and update the Risk Register, the Project Team should:
- Contact individuals with responsibility for risk Controls and Treatments and ensure they are being carried out
- Review the effectiveness of the Controls and Treatments that have been implemented
- Update the Controls and Treatments, responsible parties and due dates as appropriate
- Update the Consequence and Likelihood of risks occurring once Controls and Treatments have been implemented or if new information becomes available that may indicate that the Consequence or Likelihood of occurrence should be amended
- Add new risks and opportunities, as they arise
- Close risks and opportunities that have been realised (i.e. have occurred) or retired (i.e. are no longer a risk to the project)
- Document a clear log of Risk Register changes
- Table and discuss the Risk Register regularly at Project Steering Committee meetings
- Raise and escalate risks of concern throughout the project lifecycle to the appropriate authorities for decision making, prior to the risks eventuating (see risk review mechanisms section above)
- Update the risk allocation.
Review of contingency allowances
The Project Team should ensure that updates to the Risk Register are reflected in the project’s contingency allowance when it is updated at key milestones (at most annually). It is critical that the Project Team reviews the contingency allowance and manages cash and value. This process ensures the current level of contingency allowance adequately reflects the level of risk / potential dollar impact that remains outstanding on the Risk Register. The Project Team should review and recalculate the project contingency allowance at the key project milestones noted above.
If such recalculation results in the need for any increase in the contingency allowance, the Project Team should seek additional funding or undertake a value management exercise to reduce project costs without having any significant impact on project scope.
If the recalculation results in the current contingency allowance being higher than is necessary, the Project Team generally should return any excess contingency allowance following such recalculation to the Budget. As noted in Develop contingency allowance section in Step 3, only Government (Cabinet or the relevant Minister with the agreement of the Treasurer) can authorise any other use of excess contingency allowance.
Residual risks at project completion
For certain delivery models, risks may exist that affect the project once the project is handed over or completed (usually during operations), such as risks relating to asset acceptance by the operator. Generally, these risks should be considered within contracts rather than as a part of the Business Case process under Stage 2 – Prove of the Capital Framework. As such, the Project Team is not expected to consider residual risks during operations in the Risk Analysis section of the Business Case. However, where the delivery model involves the operations of the project, these risks should be considered.
Workshops
Depending on the complexity of a project, the Project Team may undertake Steps 1 to 5 using a number of workshops. This may involve a workshop for each step or one workshop that discusses and confirms the identification, analysis and allocation of risks and opportunities with key stakeholders.
Footnotes: