- Project plans
- Project activities
- Legislation and standards
- Industry context
Last edited 23 Feb 2018
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:
- The expected likelihood (or probability) of an event occurring.
- The expected impact if it does occur.
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 problem as early as possible so that the opportunity for taking effective action is maximised.
Those risks within the project boundary that could affect the delivery of the business outcome that the project is set up to deliver.
Those risks that affect the operation of the business outcome once it has been delivered by the project.
Those risks that are external to the project environment but which nevertheless can affect the project objectives.
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.
NB See Risk for more information.
 Risk management
The main aims of risk management are to:
- Identify potential risks.
- Assess the probability and impact of each risk.
- Identify alternative actions that may prevent the risk from happening (avoidance), or if it does happen ameliorate the impact (reduction), or provide a strategy for dealing with the accepted consequences (acceptance).
- Implement and monitor those actions that are cost effective and necessary to the successful delivery of the project objectives.
- Provide feedback from experiential learning to improve the risk management of future projects and to inform the training and development of project managers.
Effective risk management should:
- Anticipate and influence events before they happen by taking a proactive approach.
- Provide knowledge and information about predicted events.
- Inform and where possible improve the quality of decision making, recognising the hierarchy of risk avoidance, risk reduction, risk control, and risk acceptance.
- Avoid covert assumptions and false definition of risks.
- Make the project management process overt and transparent.
- Assist in the delivery of project objectives in terms of benchmarked quality, time and cost thresholds.
- Allow the development of scenario planning in the event of the identification of a high impact risk.
- Provide improved contingency planning.
- Provide verifiable records of risk planning and risk control.
 Risk management plan
A risk management plan (RMP) comprises:
- 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.
- The client should own any risks that affect the business or business case (those risks that would prevent the benefits of the project from being fully realised).
- The project manager should own any risks that might affect the delivery of the project (those risks that affect the project schedule).
- The contractor should own any risks that might affect the contractors’ ability to deliver the project objectives.
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:
- Affect the project base-line (the business case or schedule).
- Affect the 'fit' of the project within the business strategy.
- Affect dependent projects (or programmes). If the project is a part of a programme, such programme level risks will be managed by the programme management function.
 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:
Each stage has a number of steps.
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:
- Between inception and initiating a project.
- When managing phase boundaries, as one stage is completed and the next is planned in detail, as part of the management review.
- As a part of full project reviews or internal reviews.
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:
- The risk management strategy (recorded in the RMP).
- A risk register for the project.
 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:
- The level of risk management required for the project. Will any risks be quantified or modelled (for example to test cost sensitivities or different likelihood of occurrence)? Or will qualitative analysis provide enough control?
- What the levels or types of risk are for this project.
- The process and frequency with which risks and actions will be reviewed. For example, will a special meeting of the project management team be needed?
- The process for escalating risks. For example, if the project is a part of a larger programme.
- The likely points within the project when the whole risk identification process will be repeated. For example, at the start of each new stage or phase when detailed plans are being developed.
There are a number of different techniques for identifying risks. Two of the commonest techniques are:
- Brainstorming with key stakeholders to capture as many of the risks associated with the project as possible. It may also be worth involving those who have been undertaken other similar projects, so that their experience can be incorporated. As with all brainstorming the key thing at this point is to capture everything. Consideration of which risks to accept or to manage, comes later.
- Checklists. These can seldom be exhaustive, but can help to ensure that the most common key areas of project risk are considered. They are particularly useful as 'prompts' to facilitate brainstorming.
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.
Once risks have been identified they need to be assessed so that decisions can be made about:
- Which are the highest priority and therefore what level of management ownership they require.
- The possible management actions that could be taken.
 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:
|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
Cannot be contained in project base-line
Unlikely to be contained in project base-line
Likely to be contained in project base- line.
Project will not be delivered on time
Project unlikely to be delivered on time
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.
 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.
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.
 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
Image: Risk management decision scheme.
Any management action must be assessed in terms of:
- 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.
 Risk metrics and milestones
 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.
 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.
The final stage is to:
- Monitor risk metrics and milestones so that contingent actions can be implemented if required.
- Monitor the effectiveness of risk management actions to ensure they are having the predicted effect. (Improper root definition may create unexpected events at other points within the system).
- Feedback lessons about which actions are the most effective.
 Monitor progress
Ensuring progress against the risk management plan involves:
- Co-ordinating the risk activities alongside other project work (effective communication between the risk owner and the project manager is a necessity).
- Monitoring resource usage against limits and resolving conflicts.
- Monitoring risks to ensure that they remain within agreed limits.
- Monitoring risks to ensure that they do not become too large for the project manager to manage effectively.
- Monitoring risks to ensure that they do not threaten the viability of the project objectives.
- Reporting risk as outlined in the risk strategy.
- Re-evaluating the risks to the project as outlined in the risk strategy.
- Invoke procedures for any risks or issues that fall outside the authority of the project team. For example, an environmental risk which impacts more than one stakeholder.
- Invoke procedures for any risks or issues that are not being effectively managed by the risk owner, and as a consequence, other stakeholders may be adversely affected.
 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:
- Improve ongoing risk planning on the project itself.
- Share good practice with other projects.
- Monitor risk metrics and milestones to assess which risks are happening or about to happen.
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.
 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.
- Affect the project base-line, in terms of time, cost or quality of delivery of project objectives.
- Might affect the congruence of the project with the business strategy.
- Affect risk owners ability to manage other risks.
- Affect dependent phases or work packages.
- Deleted/closed because they have passed.
- If still current, be transferred to live operation/maintenance as a part of handover.
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.
 Related articles on Designing Buildings Wiki
- Avoiding disaster in existing buildings and infrastructure.
- Code of practice for project management.
- Code of practice for programme management.
- Contingency plan.
- Design risk management.
- Game theory.
- Interface risk in construction.
- Project manager.
- Project risk.
- Risk assessment.
- Risk feedback.
- Risk register.
- Third party dependencies.
Featured articles and news
Whole-life costs consider all costs associated with the life of a building, from inception to disposal. Find out more here.
Reports emerge of injuries caused by Apple employees colliding with the campus' glazed walls.
The winners of NIC's ideas competition on transforming the Cambridge to Oxford arc discuss their concept.
Create new habitats and improve air quality and wellbeing.
New report provides 12 key actions which could close the structural talent gap in the construction industry.
These can be used to find out whether a proposed development is likely to be approved. Read more here.
Studying a built environment degree? Check out our helpful student resources section.
New BRE research paper explores how blockchain technology can benefit the built environment industry.
Timber is a natural carbon sink, but it must not end up in landfill at the end of its useful life.
BSRIA has collaborated with the Department of Health on research into air permeability in isolation rooms.