Last edited 20 Jul 2021

Main author

CIOB Institute / association Website

Risk management


[edit] Introduction

A risk is a potential event, either internal or external to a project, that, if it occurs, may cause the project to fail to meet one or more of its objectives.

A project by definition is trying to introduce some form of change; a new building, production system or way of working. Change involves uncertainty, which in turn means that projects are more likely to be blown off course by a potential future event. In other words, projects are inherently risky undertakings.

Project managers need to recognise that risks exist and actively manage them; this is an indication of good project management, not an admission of failure. By looking ahead at potential events that may impact on the project and by putting actions in place to address them, project teams can pro-actively manage risks and increase the chances of successfully delivering the project.

Risk has two aspects:

An ‘issue’ in project management terms is something that is happening now and is jeopardising (or will soon jeopardise) the delivery of one or more of a project’s objectives or deliverables. It may therefore represent a risk that has materialised (in other words one where the probability has reached 100%). A risk may turn into an issue (when the risk occurs); an issue will not turn into a risk, because by definition, it has already occurred.

Risk management aims to recognise potential problems as early as possible so that the opportunity for taking effective action is maximised.

[edit] Taxonomy of risks

Risks can be classified in relation to their locus of action, that is, the organisational level at which the risk will have the most impact.

[edit] Project risks

Those risks within the project boundary that could affect the delivery of the business outcome that the project is set up to deliver.

[edit] Business risks

Those risks that affect the operation of the business outcome once it has been delivered by the project.

[edit] Environmental risks

Those risks that are external to the project environment but which nevertheless can affect the project objectives.

[edit] External change risks

Those risks that are beyond the immediate project environment but which could have a major impact. Frequently in contractual terms these may include 'force majeure' events (exceptional, unforeseen events or circumstances that are beyond the reasonable control of the parties to a contract). However, external change risks go beyond force majeure, for example because of a shift in government policy or in its interpretation of a law.

See Risk for more information.

[edit] Risk management

The main aims of risk management are to:

Effective risk management should:

[edit] Risk management plan

To achieve effective and efficient risk management, risk planning is required. The commonest form of risk planning is the Risk Management Plan (RMP).

A risk management plan (RMP) comprises:

The risk strategy, which records how risks will be owned, evaluated, controlled, reviewed and reported upon; the plan will show:

  • Who is accountable for a particular risk (ownership).
  • What that particular risk is (evaluation).
  • How that particular risk will be managed, controlled, reviewed and reported, in other words the physical actions or management actions that will be taken to avoid, reduce, control or accept the risk.

The key to effective risk management is ownership. Each risk (and associated actions) must be owned so that there is clear responsibility and accountability for that risk and its associated action. It has become an axiom of good risk management that the ownership of a risk should lie with the party ‘best’ able to control the risk probability and its impact.

Different risks and actions will need to be owned by different stakeholders. For example:

The project manager may initially determine ownership, when risks are accepted and entered onto a risk log. It may then be ratified / agreed by the client or contractor.

The risk owner is responsible for ensuring that the risk is effectively monitored and managed through appropriate, agreed mitigating actions. The project manager has overall responsibility for the control of risks (and any actions associated with them) and the communication of the plan so that all parties understand their role(s). This includes reporting the presence of any risks that, if realised, would:

[edit] The process

Risk management is about trying to eliminate the unexpected, by thinking about all the things that might happen to deflect a project from its objectives. The process can be divided in to 2 phases comprising 4 iterative stages, shown schematically below:

Phases and stages of risk management process 1.jpg

Each stage has a number of steps.

Phases and stages of risk management process.jpg

It is important to begin developing the RMP from as early on in the project as possible, when the feasibility appraisal or any full study is undertaken, or as a part of any financial appraisal, before formal project approval is sought. However, risk management is an ongoing part of project management. This is not just in terms of mitigation and control. It also means that the whole process should be repeated and re-assessed throughout the project.

Some key stages which might be suitable as review points are:

[edit] Risk identification

[edit] Identification

Identification is a key stage of the risk management process providing the foundation upon which the remainder of the process is built.

Key deliverables include:

[edit] Context and perspective for analysis

Before identification can begin, the project must have clear scope, objectives and business strategy. It is important to outline the risk strategy at this stage. This will depend on the type of project and its complexity (in terms of number of stakeholders, dependencies and products, its length, timescales, budget, and so on).

It should set out:

[edit] Gather information on risks

There are a number of different techniques for identifying risks. Two of the commonest techniques are:

[edit] Classify risks according to causes

Depending upon the size and type of project, it may be helpful to classify the risks. There are a number of ways of doing this, for example grouped according to causes (relating to customers, staff impacts, technology, and so on), project objectives or critical success factors (CSF’s), project activities or products.

[edit] Assessment

Once risks have been identified they need to be assessed so that decisions can be made about:

[edit] Determine the likelihood and consequences

All risks have two elements:

  • The likelihood that they will happen.
  • The impact on the project if they do happen.

Both of these elements need to be assessed so that risks and actions can be prioritised relative to one another. There are two main methods of doing this: qualitative and quantitative. All risks should be assessed qualitatively first, to give a feel for the relative riskiness of the project and the highest risks. Qualitative assessment looks at the relative likelihood and impact of any risk.

A first step could use the following:

Likelihood High Medium Low
It is very likely that this risk will happen It is quite likely that this risk will happen It is unlikely that this risk will happen

Different risks are likely to impact different aspects of the project. It is worth considering which type of impact is likely to be most critical to the project at the stage it has reached. The impact can then be focused upon this area - for example, costs could be considered as stage costs, development costs or whole project lifecycle costs.

Table: Examples of impacts on project taking into account their level

Impact Level






Cannot be contained in project base-line

Unlikely to be contained in project base-line

Likely to be contained in project base- line.

Schedule (e.g. key milestones)

Project will not be delivered on time

Project unlikely to be delivered on time

Some slippage to milestone Schedule but not overall project schedule


Business case deliverables are not achievable

Business case deliverables likely to be reduced

No real impact

The impact allocation is then taken to be the highest category for that risk in the three impacted areas.

NB: Impact on quality is likely to be reflected in some or all of the above, as, for example benefits include 'soft' issues such as customer service.

[edit] Initial ranking of order of importance

This will be a combination of the likelihood and the impact on cost, quality, schedule and benefits. A ranking technique can be used where: high = 3; medium = 2; low = 1. For each risk multiply the impact and likelihood together: the risks can then be ordered according to the highest score. In this system the highest risk ratio is 9 (high probability and high impact) and the lowest risk ratio is 1 (low probability and low impact).

Finally in this step, consider the timing of the highest scoring risks:

  • When are they likely to impact the project?
  • What does this mean for the possible management actions that could be taken?

Depending on the complexity of the project, it may be worth considering an additional dimension for describing the risk - its ‘urgency’ based upon how soon it will impact the project.

[edit] Mitigation

Once the identified risks have been prioritised and their timing has been established, possible management actions should be considered. These management actions are designed to contain the risk, by either making them less likely or by reducing their impact.

[edit] Decide on any actions

Using the ordered set of risks, decide whether any action should be taken and if so, what:

  • Prevent: An action which reduces the likelihood.
  • Mitigate: An action which reduces the impact to the project should the risk occur.
  • Transfer: Transfer the risk to someone who can better manage it, for example to the contractor (this is normally combined with acceptance) or partner the risk.
  • Contingency: A contingency plan which can be brought in to play should the risk occur, e.g. to deliver the business outcome (or part of it) in a different way.
  • Accept: No action will be taken - the risk is accepted as it is. For example, if the impact is very low, or the potential returns/benefits are very high.
  • Insure: Purchase an underwritten insurance policy that provides for financial restitution if the risk occurs.
  • Decline: Reject the risk – this may entail declining the entire project or entering into detailed negotiations with the prospective client.

Two additional categories of action are also worth considering:

  • Lack of root definition: Not enough information to make a decision - carry out further investigation.
  • Avoidance: A different course is taken so that the likelihood of the risk is reduced to zero. In other words the risk is avoided.

Actions aimed at reducing the probability __________________ Actions aimed at reducing the impact

Risk management decision scheme.jpg

Image: Risk management decision scheme.

Any management action must be assessed in terms of:

  • Cost.
  • The kind of action it is; this will affect when that action should be included within the project plan. For example, an action aimed at reducing the likelihood of a risk should be included in the project plan. An action affecting the impact will be contingent upon the occurrence of the risk and should therefore only be included in the plan if the risk occurs.
  • Its predicted effectiveness in containing the risk.
  • Its associated consequences - to ensure that the counter-measure does not have any unforeseen consequences. There is an assumption here that root definition has been achieved and that the action is not to relieve ‘mere’ symptoms.

These can then be compared to the risk assessment, to decide which actions are appropriate given the level of risk. Once a risk has been both accepted and appropriate countermeasures identified the risk and countermeasure owners should be agreed.

[edit] Risk metrics and milestones

For each risk that has an action, consider what measures or milestones will give early warnings that the risk is about to happen. These can then be monitored as a part of the risk management plan.

[edit] Create and agree a risk management plan

Create an initial management plan. The risk register can form the basis for this.

The nature of the plan will be dependent upon the type of risk, its timing and the type of counter-measure selected. For example, where a risk has been identified that is likely to occur in the current stage of the project and a preventative counter-measure is available, that counter-measure can be built into the activities within the project or stage plan. The action should still be controlled and managed through the RMP.

In contrast, contingency management actions are dependent upon the risk occurring and so will not be immediately built into the project plan. These measures have been “planned”, in that they have been considered and accepted, but are only put into operation within the project / phase plan as and when the risk arises and the action is authorised. Such management actions are therefore available as required.

The RMP (along with the other project plans) should be agreed, ensuring that all stakeholders are aware of any actions that are their responsibility.

[edit] Allocate resources and implement plan

Resource allocations should be pre-planned and, where appropriate, allocated to the agreed actions. Immediate actions should be built in with the other project activities as an integral part of the overall project management plan. Other actions will be dependent upon the risk materialising and will be triggered by risk metrics and milestones.

[edit] Control

The final stage is to:

[edit] Monitor progress

Ensuring progress against the risk management plan involves:

[edit] Cybernetic feedback

Cybernetic feedback is knowledge and experiential learning about the effectiveness of actions. For example, a preventative action may have been put in place to reduce the likelihood of a risk from high to medium.

  • Was this effective?
  • Did the risk materialise?
  • If so was this because the action was ineffective or for some other reason?
  • In retrospect might a different action have been more effective?

These lessons can be used to:

This will therefore involve both:

  • Checking whether risk metrics or milestones have been reached and therefore whether any contingent management actions are required.
  • Ensuring that indicators continue to give a clear picture of the status of that risk.

Where appropriate, reduction and contingency actions should be scheduled into the project plan.

[edit] Report progress

Monitor and report on the change of status of any risk. The precise method and frequency of reporting depends on the risk strategy for the project that was developed during inception. The project manager is responsible for reporting progress to the project team. Risk owners are responsible for monitoring and reporting on 'their' risks to the project manager.

In addition, they are responsible for reporting to the project manager, who is responsible for reporting to the project team the occurrence of any risks that:

[edit] Creating a legacy archive

The risk register should be managed throughout the process protocol phases. Risks will either be:

  • Deleted/closed because they have passed.
  • If still current, be transferred to live operation/maintenance as a part of handover.

DBWCTA Deltek 001.png

The text in this article is based on ‘Business Management in Construction Enterprise’ by David Eaton and Roman Kotapski. The original manual was published in 2008. It was developed within the scope of the LdV program, project number: 2009-1-PL1-LEO05-05016 entitled “Common Learning Outcomes for European Managers in Construction”.

It is reproduced here in a slightly modified form with the kind permission of the Chartered Institute of Building.


[edit] Related articles on Designing Buildings Wiki


Designing Buildings Anywhere

Get the Firefox add-on to access 20,000 definitions direct from any website

Find out more Accept cookies and
don't show me this again