The effectiveness of an organisation’s PRM is directly proportional to the maturity of its risk management practices and the degree to which they have been successfully integrated into the projects it implements. Integration here refers to whether risk management activities are well defined and described in the project plans and processes and incorporated into the project life cycle (the incremental stages in the project’s life). Integration additionally relates to whether these activities happen routinely, as part of project management processes, or if they have to be “policed” and regularly prompted before they occur. In this context the terms “integration”
and “embedding” are treated as if they are synonymous. Hence, well-defined risk management practices will count for little unless they are embedded within the organisation as a whole and are part of the project culture. However, embedding risk management within a project is not straight forward as there are a number of commonly recognised challenges.
18.5.1 Common Challenges in Implementing Project Risk Management
There are a number of challenges to the implementation of PRM that occur time and time again. These include, but are not restricted to:
• lack of clearly defined and disseminated risk management objectives;
• lack of senior executive and project director commitment and support for PRM;
• lack of a risk maturity model to guide the goals for risk management;
• lack of a change process to introduce the discipline (in situations where some form of PRM has not previously been embarked upon);
• no common risk language (terms and definitions);
• lack of articulation of the sponsor’s risk appetite (i.e. risks the project will and will not take);
• no definition of risk management roles and responsibilities;
• lack of risk management awareness training to build core competencies;
• no integration of risk management with other project disciplines;
• reticence of project personnel to spend time on risk management;
• risk owners not automatically taking responsibility for the risks assigned to them;
• no clear demonstration of how risk management adds value and contributes to project performance;
• overcomplicated implementation through confusing policies, strategies, frameworks, plans, and verbose and mutually incompatible procedures;
• lack of alignment between the overall business strategy, the project business model and the risk management objectives for projects.
18.5.2 Lack of Clearly Defined and Disseminated Risk Management Objectives Prior to the commencement of risk management activities on a project it is important for the risk management objectives to be defined to ensure planned activities are directed towards the desired outcomes. If management are particularly concerned about the impact of the project on existing operations (e.g. manufacturing), the project being completed on time (e.g. getting a drug to market prior to a competitor) or customer relations (e.g. initiating internet banking), the risk management objectives must reflect this required focus. Once the objectives are agreed they must be communicated to the team to ensure the risk process both commences and continues toward this focus.
18.5.3 Lack of Senior Executive and Project Director Commitment and Support Risk management can never be successfully embedded within a project through attempts to drive it from the “bottom up” by risk management personnel. It needs to be driven from the “top down” by the project director and senior project personnel who clearly demonstrate belief in and commitment to PRM, not just because the project sponsor’s remit calls for risk management but also because there is a belief that successful project management is dependent on knowing the risks, knowing their potential impact and proactively responding to them.
18.5.4 Lack of a Risk Maturity Model
The benefits of PRM derived by an organisation will depend directly on the level of maturity its risk management practices have attained. In the absence of an organisation-wide knowledge infrastructure, repeatable results are typically entirely dependent on the availability of specific individuals with a proven track record. This rarely provides the basis for long-term success and continual improvement. The starting point for an organisation wishing to embed risk management is an understanding of its own current competencies, its requirements and the planned method of accomplishment.
Risk maturity models can be used in a structured process to understand current risk man- agement competencies and where and how improvement may be achieved. They can be used to answer the questions “What is it we want to accomplish with risk management and why?”
and “What resources will it take to realise those benefits?”. In general terms, a risk maturity model is a representation of mature practices for appraising an organisation’s risk management competency. Models are typically structured as a series of distinct incremental steps which progressively drive greater benefits. The old adage of “If you fail to plan, you plan to fail” is just as true for implementing risk management. With the aid of a maturity model, organisa- tions can set long-term goals for risk management having a clear understanding of the current maturity of their working practices and the areas that require improvement.
A maturity model provides:
• a shared goal;
• a common language;
• a description of incremental steps of improvement;
• a means of identifying the current level of risk management capability;
• a guide for process improvements;
• a tool to support a structured approach to process improvement.
338 Simple Tools and Techniques for Enterprise Risk Management
18.5.5 Lack of a Change Process to Implement the Discipline
Where risk management is not already integrated into project management processes it needs to be implemented as part of a formal change process. Organisations that ignore the change management aspects of risk management do so at their peril. Integration is a building process where awareness and capabilities are incrementally developed. It is important not to overesti- mate the capacity and capability of an organisation to introduce a change. Introduction of the change will involve:
• establishing the objectives of the change;
• establishing the benefits the change will deliver;
• establishing the organisation’s willingness and readiness to change;
• establishing the timeline of the change, the cost (if any) and the resources required;
• defining the substance of the change, the sequence of implementation and the method of effecting the change;
• recognising the factors that may influence, constrain or block the implementation of the change;
• defining the contributions that will be required to effect the change;
• understanding the interdependencies between this change and other change initiatives planned or already commenced;
• deciding if it is appropriate to carry out a pilot implementation first, to absorb the lessons learnt.
18.5.6 No Common Risk Language (Terms and Definitions)
Confusion can occur when there is a lack a common understanding of at least the key risk management terms, undermining effective implementation. The easy remedy is the production and dissemination of a schedule of terms and definitions which is regularly reviewed and expanded and/or modified to suit the implementation of projects. Ideally the risk management terms and definitions should be a subset of project–wide terms and definitions which are fully coordinated across all disciplines. For instance, the disciplines of risk management and cost planning should have the same understanding of what a contingency is and how it is defined.
Likewise risk management and value management should have the same understanding of what an opportunity is and so on.
18.5.7 Lack of Articulation of the Project Sponsor’s Risk Appetite
Projects are the tools to deliver the business strategy, growth and performance targets. Hence, projects must reflect and be subservient to the business strategy and the capital constraints of the organisation. The board and management will normally balance the cost of a project against its benefits (within the environmental context of the organisation) and, importantly, decide on the tipping point – the amount of risk that they are willing to accept before the business case for the project is negated. Without boards articulating this position, decisions are likely to be taken which are inconsistent with the cost–reward balance. In addition, they will be unable to challenge recommendations made by management about the initiation and progress of the project over time. Hence, a project sponsor (a manager with project delivery responsibility) should be given the project’s “risk appetite” which will influence the degree of tolerance or latitude the project has in securing an individual project’s objectives. However, risk appetite
is commonly “defined” by exhibited behaviours rather than by a formal documented process.
For the trouble with risk appetite is that it is not the easiest concept to define or communicate even though, for instance, each time an organisation enters into a contract with a third party, it is making a decision about its tolerance for risk. In most cases risk appetite is defined by a mixture of both qualitative and quantitative measures. Qualitative measures are typically intangible, such as customer and stakeholder relationships or reputation, whereas quantitative measures relate typically to potential changes in the capital investment required.
Why is risk appetite important? Without a definition of “risk appetite” an organisation may embark on a project without thinking through the possible levels of failure that may arise and the organisation’s ability to withstand them. If the project failed in its entirety, what would that mean? How are procurement routes together with forms and conditions of contract to be objectively chosen unless there is both a recognition of the inherent risk exposure in each and an agreement on the “ceiling limit” to acceptable risk exposure?
18.5.8 No Definition of Roles and Responsibilities
A lack of a clear designation of responsibility for leading or participating in risk management will inhibit its effective implementation. The roles and responsibilities for risk management across a project team need to be clearly established and communicated. This is typically accomplished through a combination of activities, as follows:
• preparing a risk management plan and incorporating within it a RACI chart (or a variant thereof; see Section 18.9.3) which describes the individual risk management activities, those responsible and accountable for implementing them and those who will be consulted or informed in the process;
• presenting the risk management plan to the client and the project team;
• including risk responsibilities within job descriptions;
• reviewing whether the responsibilities included within job descriptions are being followed and conducting staff performance reviews;
• clear allocation of risk response actions to designated risk owners and risk actionees (where an actionee supports the risk owner in risk mitigation implementation);
• clear designation of risk reporting requirements;
• identification of an individual or group that will provide guidance and support in the implementation of risk management.
18.5.9 Lack of Risk Management Awareness Training to Build Core Competencies Comprehension of, commitment to and implementation of risk management will be directly influenced by project team member’s knowledge of the discipline of risk management and how it should be integrated with the other project disciplines. Methods of building awareness include:
• formal risk management training or seminars and refresher training;
• presentations of the risk management plan and procedure;
• the creation of risk management “champions” who are able to provide support to team members;
• the inclusion of plans, procedures, presentations and risk management guidance papers on the company intranet.
340 Simple Tools and Techniques for Enterprise Risk Management
18.5.10 Lack of Integration of Risk Management with Other Project Disciplines For a project to be successful, risk management needs to be integrated with the other project disciplines throughout the project life cycle, from inception through to handover and imple- mentation. Risk management should:
• Be integral to and support project management and hence overall project delivery.
• Support feasibility assessments and the selection of a preferred option.
• Form an integral part of gate reviews.4Gate reviews are a safeguard for the sponsor. They discern whether the original business case is being satisfied and whether further funding should be committed to the project. The culmination of a gate review is the recommendation as to whether the project should proceed to the next phase or additional work should be undertaken.
• Be a formal part of the change control process so that there is an understanding of how the planned change(s) will affect the overall risk exposure of the project.
• Be integrated with stakeholder management so that there is an awareness of the degree to which any one stakeholder can influence the outcome of a project so that risk management effort can be prioritised.
• Influence the procurement route, form of contract and contract conditions.
• Be integrated with cost planning and scheduling to provide robust realistic defendable contingencies for cost and time, respectively.
• Be integral with project governance whereby the organisational structure, responsibility matrix and job descriptions appropriately reflect the project scope.
• Be integral with the discipline of value management through an understanding of the client’s value system and the project’s value chain and recognising that risk exposure is a by-product of the pursuit of value.
• Complement and support earned value analysis and scenario modelling.
18.5.11 Reticence of Project Personnel to Spend Time on Risk Management
A significant obstacle to the implementation of risk management is the reticence of project personnel when it comes to devoting time to its application. Many consider it adds little value, and the pace of projects means that there is always a myriad of pressing issues for project personnel to respond to as opposed to spending time on identifying risks which may or may not happen. Hence, risk management has to be “sold” to projects on the basis that while it is not more important than say design, estimating, scheduling or change management, it is equally important. For risk management is a key tool in delivering project sponsor satisfaction through identifying threats to successful delivery and responding to them. The ability to manage risk is one of the core competencies of any organisation and its employees.
4A gate review is a “peer review” carried out at the end of intermediate project stages by an independent individual or team from outside the project, who use their knowledge and experience to examine the progress to date and the likelihood of the project being successful. The review uses a series of interviews, documentation reviews and the team’s experience to provide valuable additional perspective on the issues facing the project team, and provides an external challenge as to whether or not the current phase has been completed. Critically, the review will recommend whether or not the project should move to the next project phase, and hence whether further funds should be committed to the project.
18.5.12 Risk Owners not Automatically Taking Responsibility for Assigned Risks Experience illustrates that project personnel will attend regular risk meetings having not looked at the risk register or the risks allocated to them as owners since the last meeting. As a consequence, any opportunity to progress risk response actions in the interval between the two will have been lost. When this lack of participation is demonstrated by one individual the impact can usually be contained. When all project personnel are exhibiting the same behaviour, risk response planning is largely ineffective and a cultural shift is required. Risk management then needs to be taken back to “first principles”. The risk champion must reinforce why the project is engaging in risk management, the benefits sought from its application, the downside if it is not implemented, the ramifications if the project benefits are not realised and the lessons learnt.
18.5.13 No Clear Demonstration of How Risk Management Adds Value and Contributes to Project Performance
The holy grail of PRM is being able to both describe and demonstrate through examples that the disciple adds value and contributes to project performance. To persuade the project team to spend time on risk management when they could be directly contributing to project delivery requires winning their hearts and minds. It requires an explanation that theraison d’ˆetre of project management is the management of risk from inception to handover. It involves assessing risk at project sanction, during options analysis, at each gate review, as part of feasibility analysis, during procurement route and contract selection, as part of contract clause reviews and tender return reviews and during management of execution. Project sponsors require the project manager they have engaged on a project to manage the risks to their project so that it satisfies its objectives and meets the pre-agreed cost and time constraints.
18.5.14 Overcomplicated Implementation from an Unclear Risk Policy, Strategy, Framework, Plan and Procedure
Embedding risk management will be hindered by a myriad of documents that are intended to provide guidance but have been prepared without a clear understanding of their unique purpose, content or applicability. The documents in common circulation are risk policies, strategies, frameworks, plans and procedures. Many organisations prepare a suite of documents which are supposed to be hierarchical in nature but are not – they do not clearly state their purpose and their content overlaps. Project participants have mountains of documents to digest and should only be provided with those that directly affect the project objectives, their scope of work and the deliverables.
18.5.15 Lack of Alignment between the Business Strategy, Business Model and the Risk Management Objectives
PRM will be fruitless if the business model for the project does not adequately support delivery of the business growth strategy. If the business strategy calls for, say, a freight railway with a particular annual throughput and the scope of the project will not accomplish that throughput, there will be a gap between what the business needs and what the project will
342 Simple Tools and Techniques for Enterprise Risk Management
deliver. Organisations must have the ability to prepare business cases or commission them and have the ability to assess models that are prepared on their behalf.
18.5.16 Lack of the Integration of Risk Management Activities into the Day-to-Day Activities of Project Managers
Often risk management is seen as a peripheral activity which will make no difference to the project outcome. However, a project manager’s role is the management of planned tasks to a predetermined schedule to achieve agreed objectives. The successful completion of these tasks will clearly influence the overall satisfaction of the objectives. Each of these tasks will have challenges, which may be described as threats or risks. For risk management to be embraced the discipline needs to be recognised as the tool to manage these threats (or opportunities) to the planned tasks. While there will always be risks that materialise that a team had not identified, it could be argued that the primary source of risk on a project is a lack of adequate management of known threats. These threats will emanate from both inside and outside the project team’s organisation(s). The term “management” does not imply that the threats will be under the total control of the team, but suggests that management processes should include an appreciation of how events may unfold and knowing how to make provision for them.
Progress reporting is in essence describing whether the project is on track, as mea- sured by whatever metrics have been agreed, and describing the events (materialised risks) which have increased the budget and/or schedule, threats which may derail the project in the future or activities implemented to eliminate or reduce known or potential threats.