creating a risk superstructure for projects
Vice President Communications, Project Management Institute Romania Chapter
Risk management can avoid up to 90% of the project’s problems. While it can have such a huge impact, project risk is usually managed individually by each project manager. This paper discusses risk management maturity levels and starting a specialized function in your organization.
Only one third of the world’s projects are successful (The Standish Group, 1995, p. 2), so more than 60% of the projects use more money and time that they don’t have. Risk management is one organizational function that can significantly help in solving this problem, and while talking about risk management is in fashion today, its practices are largely unutilized. Risk management is done by some project managers alone.
In studies conducted worldwide, RMC Project Management, founded by Rita Mulcahy, PMP, determined that managers of US$700-million projects used only checklists, while only interviews were used by a team of US$300,000 project that could have resulted in the death of many of their workers (Mulcahy, 2010, p. X) .
Projects in organizations with well-implemented risk management meet all their objectives and were completed on average at 5% below plan, whereas in an organization with poor risk management, projects fail on average, with 70% costs and schedule overruns (Hillson & Simon, 2007, p. 7).
Risk management is, therefore, too important to let it happen for each project individually. Therefore, a risk management superstructure needs to be created to cover all projects in the portfolio and also some of the operations, such as bidding or finance.
Risk Management Function
To be effective, an organization needs to have a consistent set of processes and policies for managing risk. These must be constantly communicated, monitored, and controlled, just like any other area that is managed efficiently. Such a demand cannot be met independently at the project or team member level, but in a centralized way, it can be placed as high in the management hierarchy as possible, for example, reporting directly to the CEO or to the board, just like quality management. Both have a very delicate nature, frequently exposing unpleasant realities, and therefore sometimes being exposed to internal pressures.
In fact, some companies, such as IBM, have merged the two quality and risk functions. In the company’s Approach to Quality Assurance (International Business Machines, n.d.), it is stated that independent risk management representatives who are specially trained in project management and the QA discipline review projects at set points of the lifecycle in order to recognize, contain, and mitigate any risks that could jeopardize the quality or success of a project. It is important to note the risk management (RM) representative is independent, i.e., not involved or having stakes in the initiative he or she is reviewing.
The RM function acts regularly as a central point of trustworthy information for management and as a moderator between opposing company areas such as sales and technical teams. The Institute of Risk Management synthesized its responsibilities in the Risk Management Standard (Institute of Risk Management, 2002, p. 13), and it should ideally include at least the following:
- Setting policy and strategy for risk management
Policies and strategies set the approach and the scale of risk-related activities, including any legal requirements if applicable. Like other policies, RM policies are more effective when supported by executive management commitment. These policies cover topics such as what departments are involved, how sponsors participate, what training is necessary, and who is to be trained on risk management.
- Primary champion of risk management at strategic and operational level
The RM function must act as an enabler of risk activities. It must enthusiastically support executives, team members, and project and program managers in their day-to-day activities on risk. In addition, it must demonstrate the benefits both at the corporate and individual level, in terms of avoided problems, reduced over-runs, and less stress. All this investment is required to gain and maintain momentum on risk management.
- Building a risk aware culture within the organization including appropriate education
Everybody in the organization should know that risk management is not done as a hobby or for pleasure, but it’s necessary to reduce up to 90% of project problems (Mulcahy, 2010, p. X). RM function must then communicate this by setting up information channels (intranet pages, newsletters, workshops, surveys) to promote tools and techniques, mitigate strategies, key risks, or escalation procedures.
Also, a key role is to ensure that lessons learned management is done and valuable information related to risk is collected from all projects and released to use in other projects. Having such a process in place would eliminate duplicate problems from showing up repeatedly (Mulcahy, 2010, p. 285). Lessons learned are not created by the RM function, but by project teams and stakeholders. RM functions may act as a facilitator in the process.
- Establishing internal risk policy and structures for business units
It is the business units’ responsibility to manage risk in its day-to-day activities. The performance can be measured by using metrics—standards that once evaluated will show how the units are performing against the plan. Such metrics may consist of the number of risks identified, the total effort allotted to risk activities, the number of risk reviews, the cost reduction resulted after creating contingency plans, etc.
In addition, it is very important that the business units and the organization as a whole know what their risk tolerance is. Tolerances to risks differ vastly among companies and stakeholders, so the extent of the negative risks that are acceptable in projects and operations must be known. Furthermore, teams must know how unacceptable threats should be treated. This means to know how much is too much and what to do then. For example, a risk of 25% cost overrun might be considered unacceptable and the project (or the component) gets a “no-go” verdict.
- Designing and reviewing processes for risk management
Processes for risk management should be adapted to project nature and size. They can be created from scratch or using frameworks as those found in A Guide to Project Management Body of Knowledge (PMBOK® Guide)—Fourth Edition (Project Management Institute, 2008). There is, however, a common structure of these processes because they all need to plan risk management and then iteratively identify, analyze, monitor, and control risks, and plan how to respond to these risks.
The processes describe specific inputs and outputs and provide consistent tools and techniques, such as checklists, risk categories, sample risk breakdown structures, etc. In addition, part of the RM function responsibility is to create sets of common metrics, for example, scales for the probability/impact matrix and risk thresholds.
These processes must constantly be improved to reflect changes in the organization and incorporate lessons learned in current and previous projects.
- Coordinating the various functional activities which advise on risk management issues within the organization
Risk management cannot exist without input and advice from business units such as operations, finance, sales, etc. The RM function can be regarded as an enabler and a facilitator that allows these units to establish practices that avoid problems and exploit opportunities through risk management.
- Developing risk response processes, including contingency and business continuity programs
The risk management process is as strong as its weakest response plan. The purpose of managing risks is not having an extensive risk register with thousands of risks, but knowing how to react in case uncertainty— good or bad—finally materializes, affecting the project.
- Preparing reports on risk for the board and the stakeholders
Management decisions are better when made with an understanding of the risks involved rather than making a decision when it can make or break the company future (e.g., accepting a project without analyzing the risks or opportunities)
There is no use for a set of policies, procedures, and processes if they are not followed consistently. The RM function must make sure that business units really plan and monitor risk on their activities using appropriate organizational standards. Hence, there is a strong internal audit role for the RM function. According to the same IRM standard, the internal risk management audit should:
- Focus on the internal audit work on the significant risks, as identified by management, and audit the risk management processes across an organization;
- Provide assurance on the management of risk;
- Provide active support and involvement in the risk management process;
- Facilitate risk identification/assessment and educate line staff in risk management and internal control; and
- Coordinate risk reporting to the board, audit committee, etc.
The role that RM function has in the organization is, therefore, quite complex. There is a lot of effort that needs to be devoted to risk management activities and to support them with a specialized function. Yet, the benefits of having such a setup in terms of reliability, problem avoidance, and opportunity exploiting make it worth.
Risk Management Function Involvement in Project Management Processes
Of course, all project management methodologies include risk among their project processes and activities. However, risk management goes far beyond being a pure knowledge area.
According to David Hillson (2007), “Risk management process must be integrated with other project management processes. Not only must these processes use risk data, but there should also be a seamless interface across process boundaries. This has implications for the project toolset and infrastructure, as well as for project procedures” (p. 6).
Indeed, there is hardly any activity in project management that is not affected by risk. Scope, time, cost, quality, human resources, communications, procurement, etc., are all subject to “uncertainties that matter” and relevant to risk management practices need to be applied to eliminate the surprise factor as much as possible.
The RM function involvement in project management processes is quite solid. Aside from usual consulting, distributed in both planning and execution phases, the RM function reviews projects during monitoring and controlling activities, helps project teams collect lessons learned for future projects, and acts as a direct link to top management.
Besides the risk itself, the RM function must handle risk causes, risk effects, project problems, and project issues. In a real-life project, there are just a few problems that couldn’t have been predicted using basic risk management practices, so when a project has a problem, it usually means that it’s a poorly managed risk. In addition, the RM function can help the project team find common root causes for risks and ways to eliminate them.
Therefore, the RM function will act as a superstructure for all projects in the organization.
Risk Management Function and the Project Lifecycle
As risk management is done throughout the project lifecycle, the RM function should be involved continuously from the very beginning of the project to the very end. However, this is not always feasible, because the effort required to monitor each second of each project’s life would hardly justify the benefits.
Nonetheless, risk management must be done in a constant manner, but focusing on key project lifecycle moments, such as project selection, baseline approvals, major milestones, phase completions, etc.
Exhibit 1: Risk management function involvement during project lifecycle
Exhibit 1 illustrates a usual service company project lifecycle, with several key milestones: project identification, proposal writing, submission, contract signing, project execution, and finish. Risk management can be involved at any moment, yet there are some project key moments when risk management is most effective. The dots represent these proposed involvement times:
- After the project is identified and before the proposal team is assembled:
Some say that a company is not only the result of what projects it has done, but also of what projects it didn’t do. Choosing bad projects can make a company fail quickly, and projects often fail because of poor risk management. The RM function needs to be involved when selecting projects.
- Before the proposal is submitted:
This is by far the most important risk review of all, since it covers the final part of the planning phase. The RM function can help the project team identify new threats and opportunities, can assess if the project risk planning was done and if the risk policies and procedures have been followed properly.
- Before the contract is signed:
This review concentrates on the differences between what was submitted as a proposal and what changed as a result of negotiations. Concessions made during this process can severely affect the project risks because of new commitments, price, and deadline changes. Of course, the RM function can be involved proactively in negotiations, but this may not be always possible.
- Sometime after the project begins:
This first review analyzes the project plan versus the project reality. It is advised that this review is not done on the first day of the project but after a period of time that allows the project team to get the actual feeling of the project. Even if the project is going well, it is often necessary to revise the risk register to update it by bringing in new risks and reassessing the probability and impact of the existing entries to reflect the current situation.
- After key project deliverables or when after major event has happened:
Project state changes after major events and consequently so are the risks. After a phase is completed successfully, risk for that phase disappears, also the probability and impacts of other threats decrease. Also, if a negative event has occurred, as a result of an unforeseen risk, all project risk management tasks have to be revised (i.e., if a threat has been missed there might be others and also the effects on the project need to be examined).
- Just when the project finishes:
It may look somehow bizarre to have a risk meeting at the end of the project, since there is no risk that can affect a finished project. This meeting does not address though the risks that are to occur, but the risks that have or have not materialized into events. The project team and significant stakeholders need to be involved at this step, so that important lessons learned are extracted from their experience on the project, both risk related, and nonrisk related. Problems and issues in this project are likely risks for the next project; also, records produced by the team activity may be used for other subsequent similar projects.
Creating the Superstructure
The RM function is usually sized depending on the company dimension and on risk management maturity: as small as an individual with risk management knowledge or as big as a full-scale department.
Best practices have shown that the RM function can grow incrementally (Treasury Board of Canada Secretariat, 2004; IRM, 2002, p. 13). It is indeed hard to believe that a risk management department can be created from scratch or in a week. To create a RM function, the organization is undertaking a significant cultural change. No matter what maturity level, the RM function, just like any function that requires audits and reviews, must stay independent to assure unbiased and complete data on the projects.
The IACCM Business Risk Management Maturity Model (BRM3) (International Association for Contract and Commercial Management, 2003, p. 5) identified four levels of organizational competence in the area of business risk management: novice (or naïve), competent, proficient, and expert. These organizational maturity levels can be mapped to phases of the RM function development in the organization. No matter what maturity level, RM function, just like any function that requires audits and reviews, must stay independent, to assure unbiased and complete data on the projects.
The novice/naïve level can be ignored, Because it does not involve risk management practices whatsoever.
Phase 1: Risk Champion Phase
An enthusiastic and knowledgeable supporter of integrated risk management will act as the risk champion in the organization. The champion may be a project manager, a PMO member, or an executive manager. His or her primary mission is to establish a corporate focus for risk management, besides consulting the colleagues on risk matters. Risk management and governance may still be the responsibility of the project manager, yet the project manager can get advice and support from the risk champion.
This phase can be usually mapped to the competent maturity level in BRM3. There still is no integration with other business processes, or the integration is insular (functionally orientated). In addition, knowledge on risk starts to be organized on an ad hoc basis, but due to the availability limitation on staffing this information is inconsistently applied.
Phase 2: Part-Time or Full-Time Risk Manager
At this stage of development, a dedicated risk management professional is promoted or hired. The corporate direction for risk management is now clear and risk management is integrated into existing decision-making structures.
Being cross-functional (part of the business processes), knowledge is maintained; lessons learned are captured and used to update risk processes in the now proficient maturity level organization.
Phase 3: Risk Management Department
When the company grows, a full-scale risk management department can be created. This will build organizational capacity to integrate threats and opportunities at a culture level.
The knowledge system is comprehensive and available. It includes external data, and lessons learned are captured and discussed. Furthermore, they are communicated and strategy is now proactively modified to reflect changes in environment.
Hillson, D., & Simon, P. (2007). Practical project risk management: The ATOM methodology. Vienna, VA: Management Concepts.
Mulcahy, R. (2010). Risk management tricks of the trade® for project managers and PMI-RMP® exam prep guide. Minnetonka, MN: RMC Publications Inc.
Institute of Risk Management. (2002). A risk management standard [Electronic version]. Retrieved from http://www.theirm.org/publications/documents/ARMS_2002_IRM.pdf
International Association for Contract and Commercial Management. (2003). The IACCM business risk management maturity model (BRM3) [Electronic version]. Retrieved from http://www.risk-doctor.com/pdf-files/brm1202.pdf
International Business Machines Corp. (n.d.). Approach to quality assurance. Retrieved from https://www-304.ibm.com/easyaccess3/fileserve?contentid=104374
Project Management Institute. (2008). A guide to the project management body of knowledge (PMBOK® Guide) (4th ed.). Newtown Square, PA: Project Management Institute.
The Standish Group. (1995). The Chaos report [Electronic version]. Retrieved from http://www.projectsmart.co.uk/docs/chaos-report.pdf
Treasury Board of Canada Secretariat. (2004). Integrated risk management implementation guide. Retrieved from http://www.tbs-sct.gc.ca/pubs_pol/dcgpubs/RiskManagement/guide-eng.asp
© 2010, Cristian Dinu
Originally published as a part of 2011 PMI Global Congress Proceedings – Dublin, Ireland