General
Risk management allows individual risk events and overall risk to be understood and managed proactively, optimising success by minimising threats and maximising opportunities. Its goals are to:
- ensure that levels of overall risk within a project, programme or portfolio are compatible with organisational objectives;
- ensure that individual risks and responses are identified;
- minimise the impact of threats to objectives;
- optimise opportunities within the scope of work.
Risk is inherent in all projects, programmes and portfolios because each one is a unique combination of objectives, solutions, people and context. Each project, programme and portfolio will have an inherent level of overall risk. This overall risk has two components: risk events and uncertainty.
A risk event is an identifiable event that, if it occurs, will have an impact on the objectives. The key phrase here is “if it occurs”. Risk management is all about dealing with things that may, or may not, happen.
Uncertainty relates to a form of risk that cannot be identified as a specific risk event. For example, in the use of innovative technology there may be uncertainty about performance or reliability of some components. At a more mundane level every set of plans has a degree of uncertainty because they are based on estimates of varying accuracy.
Risk events are viewed as being either positive or negative. A negative risk (threat) is the one most people are more familiar with. It is something that will have an adverse effect on the objectives if it occurs. A positive risk (opportunity) is something that can enhance the value of the work if it occurs.
The procedure as illustrated below starts with the planning step that defines the scope and objectives of risk management and results in a risk management plan. Many risk management plans focus on dealing with risk events because these are more tangible. A more mature organisation will ensure that plans also address uncertainty and make allowances for this difficult to quantify aspect of overall risk.
The initiation step is performed once the work is approved and the resources needed to manage risk are mobilised.
The first specific step of the procedure is to identify risk events and uncertainty. These are documented in the risk register. There are many techniques that aid risk identification but the greatest fault of many P3 managers is to take this step too far. Because risk identification is about thinking of things that might not happen the potential list of risk events is, quite literally, endless. Experienced P3 managers sift out the risks that need to be managed from those that must be left to ‘background risk’.
In the next step the nature of the risk is assessed and, where possible, its potential effect on objectives is estimated. A variety of risk techniques are available to assess both risk events and broader uncertainty. These fall into two groups generally referred to as qualitative and quantitative risk techniques.
Once the risk is understood the management team have to decide on how to respond. Once again there are various approaches to dealing with threats and opportunities and the planned responses are added to the risk register.
Depending upon the nature of the planned responses some are implemented as part of the delivery plans while others may only come into effect should the risk occur.
The procedure is iterative with the assessment and response planning steps potentially leading to the identification of more risks.
Risk is inherent in everyday life. All animals have evolved to deal with risk and, naturally, different individuals react in different ways. P3 managers need to identify and manage the behavioural influences of both individuals and groups on the risk procedure. This risk context can have a significant impact on the effectiveness of the procedure.
The management of general health and safety risks (hazards) is usually excluded from P3 risk management, as the management of these risks is traditionally handled by a separate function within the organisation.
Projects, programmes and portfolios
The nature of risk and the principles used to manage it do not vary between projects, programmes and portfolios. In fact it isn’t very different in P3 management than in the rest of human endeavour. However, the specifics do vary in line with the complexity of the work. Risk events become more numerous and diverse, and uncertainty becomes a more influential factor.
As the work becomes more complex its management is distributed. Major projects are sub-divided into sub-projects; programmes into projects; portfolios into projects and programmes. As a consequence risk management also becomes distributed and this is the difference between risk management in smaller projects and more complex work.
For example, the management team of a programme have to develop a programme risk management plan that promotes consistency across programme level activity, projects and change management activity. They then delegate responsibility for risk management to the project managers and business change managers. Each project and area of business change will maintain its own risk register.
The challenge for the programme management team arises from the fact that risk does not respect the same boundaries. Risk events often have an impact beyond their host project or business area. The programme management team have to balance the need for delegation with the need for co-ordination. All parts of the programme need to work together to understand which risk events should be recorded in the programme risk register (and managed at that level) and which events should be recorded and managed at a more ‘local’ level.
The basis for this common understanding is the analysis of risk and uncertainty and, in particular, the objectives the risk affects. Risk that has a local effect on project objectives can clearly be managed at the project level. Risk that directly impacts on programme objectives should be part of the programme risk register. The tricky area, as always, is the one in-between.
Understanding this is the same as understanding the inter-relationships between the component objectives of the programme. If the realisation of a benefit will be adversely affected by a one month delay in the delivery of an output, then a risk event that could cause a 2 month delay in the delivery is clearly a programme level risk. The teams must also be aware of how risk can move between levels as its impact varies with time.
The same issues apply for large complex projects and portfolios, albeit with slightly different emphases.
