- Project plans
- Project activities
- Legislation and standards
- Industry context
Last edited 01 Aug 2018
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 problems as early as possible so that the opportunity for taking effective action is maximised.
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.
 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:
 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
- 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.
Schedule (e.g. key milestones)
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
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).
- When are they likely to impact the project?
- What does this mean for the possible management actions that could be taken?
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
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.
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.
 Creating a legacy archive
- 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”.
 Find out more
 Related articles on Designing Buildings Wiki
- As Low As Reasonably Practicable (ALARP).
- 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.
- Incident reporting system.
- Interface risk in construction.
- Project manager.
- Project risk.
- Risk assessment.
- Risk feedback.
- Risk register.
- Third party dependencies.
- What is a hazard?
Featured articles and news
George Demetri brings a whole new level of technical knowledge to Designing Buildings Wiki.
Quality professionals need to take an active role in driving the completion process forwards.
The innovations needed to move from rhetoric to realisation.
Creating a sense of place, with radically-low running costs and the highest comfort levels.
A conversation between David Mitchell and Caitlin DeSilvey.
A quick guide to brick sizes.
The Union Street development in Southwark was a passion, as well as a business endeavour.
Do our water quality standards demonstrate to the public that their supply is clean?
A third of practitioners do not have easy access to the knowledge they need.
Sustainable approaches to relief, recovery and reconstruction after a natural disaster.
An introduction to a complex issue, the legal status of which remains unclear.
Dealing with the fats, oils and greases that enter the sewer system.