📤 Review the primary risks at all stages of the project and agree primary risks, constraints and dependencies with the primary decision-maker. This should be included in the business case.

👩‍🏫 Project team and strategic team with authority and experience in both general and energy projects

✅ Use an extended RAAIDD log to capture context and decisions.

Identify the main risks

Risk is the possibility of a ‘negative’ event occurring and adversely impacting the project. At this stage in the development of the project business case, focus on the 20% of risks that are likely to provide 80% of the project’s risk value. Identifying, mitigating and managing the key risks is crucial to successful delivery, since the key risks are likely to be that the project will not deliver its intended outcomes and benefits within the anticipated timescales and spend.

✅ Specify the main risks associated with the achievement of the project’s outcomes and the proposed countermeasures for mitigation and management.

There are 3 major types of risk that need to be considered:

Business risks – These risks remain with the organisation, cannot be transferred and include political and reputational risks.

Service risks – These associated risks fall within the design, build, financing and operational phases of the project and may be shared with others from outside of the organisation.

External risks – These non-systemic risks affect all society and are not connected directly with the proposal. They are inherently unpredictable and random in nature. They include technological disruption, legislation, general inflation and catastrophic risks.

The Net Zero Go Risk Framework can be helpful to work through possible risks to identify those that are relevant to this type of project or just to provide a structured approach to capturing project risks through the project lifecycle.

Identify the constraints

Project constraints are limiting factors for your project that can impact quality, delivery and overall project success.

✅ Specify any constraints that have been placed on the project. Constraints are the external conditions and agreed parameters within which the programme must be delivered, over which the project has little or no control.

These can include policy decisions, ethical and legal considerations, rules and regulations, and timescales within which the project must be delivered. Affordability constraints may include agreed limits on capital and revenue spend. Constraints on the project need to be managed from the outset, since they will constrain the options that can be considered for project delivery.

Identifying the dependencies

Dependencies are changes or positions that are outside the scope of the project upon which the ultimate success of the project is dependent.

The extent to which it is necessary and prudent to provide indicative values for these risks depends on the nature of the project and should be agreed between the project lead and the approving authority prior to the commencement of the business case. The scoping document should be used for this purpose. Adopt a prudent and evidence-based approach and capture supporting analysis and assumptions in a preliminary risk register for the project (to be made more detailed later).

✅ Specify any dependencies outside the scope of the project upon which the ultimate success of the project is dependent.

I*nterdependencies between other programmes and projects*. These are the dependencies that are external to the project but are still within the perimeters of the organisation’s project and project management environment, most likely linked to the scope of another project or project within the strategic portfolio.

External dependencies outside the project environment. These are the dependencies that extend beyond the boundaries of all the projects into other parts of the organisation or even other organisations. These dependencies are outside the control of the project management environment, potentially in business operations and partnering organisations, and include external dynamics such as legislation, strategic decisions and approvals.

Best practice

Developing a RAID log for a project is an accepted way of tracking the various facets of the risks, constraints and dependencies for a project. The governing organisation may have its own approaches.

• *R*isks are negative events that haven't happened yet but could in the future. Risks have owners that are responsible for preventing them by identifying mitigations.

• *A*ctions are something to mitigate a risk and resolve an issue. Actions are assigned to people.

• *I*ssues are risks that have manifested and need to be addressed.

• *D*ependencies are descriptions of how risks and actions may affect each other. They may become issues if a connected risk occurs or a connected action or activity doesn't happen as required.

There is an extension to this, which can be used especially if external financing is required, that captures assumptions and decisions. This is called a RAAIDD log.

• *A*ssumptions are events or conditions that are expected to be in place, happen or are considered true. Assumptions are assigned to people to ensure accountability.

• *D*ecisions should be captured to ensure a clear audit of consensus and accountability.

Already have an account? Login