Enterprise Risk Management and the PMBOK

By | March 15, 2017

Enterprise Risk Management is a term used to describe a holistic approach to managing the risks and opportunities that the organization must manage intelligently in order to create maximum value for their shareholders. The foundation for the approach is the alignment of the organization’s management of risks and opportunities to their goals and objectives. One of the keys to this alignment is the “Risk Appetite” statement which is a statement encapsulating the direction the Board gives management to guide their risk management methods. The statement should describe in general terms what kinds of risk the organization can tolerate and which it can’t. This statement plus the organization’s goals and objectives guides management in the selection of projects the organization undertakes. The statement also guides management in setting risk tolerance levels and determining which risks are acceptable and which must be mitigated.

This article will attempt to review Enterprise Risk Management (ERM) and relate it to the best project management practices found in the PMBOK® (4th Edition). The source for most of my information about ERM comes from a study published by the Committee of Sponsoring Organizations (COSO) of the Treadway commission published in 2004. The Treadway commission was sponsored by the American Institute of Certified Public Accountants (AICPA) and the COSO consisted of representatives from 5 different accounting oversight groups as well as North Carolina State University, E.I. Dupont, Motorola, American Express, Protective Life Corporation, Community Trust Bancorp, and Brigham Young University. The study was authored by PriceWaterhouseCoopers. The reason for listing the oversight committee and authors is to demonstrate the influence the insurance and financial industries had over the study.

The approach suggested by the study, which is probably the most authoritative source of ERM information, is very similar to approaches taken to managing quality in the organization in that it places emphasis on the responsibility of senior management to support ERM efforts and provide guidance. The difference here is that, while Quality methodologies such as CMM or CMMI place the responsibility on management to formulate and implement quality policies, ERM takes responsibility right to the top: the Board of Directors.

Let’s go through the study recommendations and relate them to the processes recommended in the PMBOK. To refresh your memories, those processes are:

Plan Risk Management
Identify Risks
Perform Qualitative Risk Analysis
Perform Quantitative Risk Analysis
Plan Risk Response
Monitor and Control Risks

ERM begins by segregating goals and objectives into 4 groups: strategic, operations, reporting, and compliance. For the purposes of managing projects, we need not concern ourselves with operational risks. Our projects might support implementation of reports and our projects may be constrained by the need to comply with organizational or governmental guidelines, standards, or policies. Projects in the construction industry will be constrained by the need to comply with the relevant safety laws enforced in their location. Projects in the financial, oil & gas, defense, and pharmaceutical industries will also be required to comply with government laws and standards. Even software development projects may be required to comply with standards adopted by the organization, for example quality standards. Projects are a key means of implementing strategic goals so goals in this group are usually applicable to our projects.

The study recommends 7 components:

Internal environment The key component of the internal environment is the “Risk Appetite” statement from the Board. The environment also encompasses the attitudes of the organization, its ethical values, and the environment in which they operate.
PMBOK® Alignment The description in the study is actually very close to the description of Enterprise Environmental Factors. Enterprise Environmental Factors are an input to the Plan Risk Management process. The PMBOK also refers to the organization’s risk appetite in their description of Enterprise Environmental Factors, as well as attitudes towards risk.
Objective Setting Management is responsible for setting objectives that support the organization’s mission, goals, and objectives. Objective setting at this level must also be consistent with the organization’s risk appetite. The objective setting here may refer to objective setting for the project, as well as any of the other 4 groups.
PMBOK® Alignment Goals and objectives should include those that pertain to risk management. The project’s Cost and Schedule Management plans are input to the Plan Risk Management process. These documents should contain descriptions of the goals and objectives in these individual areas. These goals and objectives may determine how risks are categorized (Identify Risks), prioritized (Perform Qualitative Risk Analysis), and responded to (Plan Risk Response).
Event Identification Events that pose a threat to the organization’s goals and objectives are identified, as well as events that present the organization with an opportunity of achieving its goals and activities (or unidentified goals and objectives). Opportunities are channeled back to the organization’s strategy or objective setting processes.
PMBOK® Alignment This component aligns exactly with the Identify Risks process from the PMBOK. The only significant difference here is the recommendation that opportunities be channeled back to the organization’s strategy of objective setting processes. The PMBOK offers no guidance here but this component can be supported by simply referring any opportunity not identified with an existing project goal or objective back, to the project sponsor.
Risk Assessment Risks are scored using a probability and impact scoring system. Risks are assessed on an “inherent and residual” basis. This simply means that once a risk mitigation strategy has been defined, its effectiveness is measured by determining a probability impact score with the risk mitigation strategy in place. This score is referred to as residual risk.
PMBOK® Alignment This component aligns closely with the Perform Qualitative Risk Analysis process. This process provides for the probability and impact scoring for the identified risks. The Monitor and Control Risks process also supports this component. This is the process that measures the effectiveness of the mitigation strategies. This is the process that will determine the residual risks.
Control Activities Policies and Procedures are established to ensure that risk responses are effectively carried out.
PMBOK® Alignment This component is supported by the Plan Risk Management process. The output of this process is the Risk Management Plan which describes the risk management procedures the project will follow. Keep in mind that Control Activities is wider in scope than Plan Risk Management, the Plan will only cover those procedures that pertain to the project. The Monitor and Control Risks process also supports this component. This process ensures that the procedures defined in the plan are carried out and are effective.
Information and Communication This component describes how information pertaining to risks and risk management is identified, captured, and communicated throughout the organization.
PMBOK® Alignment This component is actually supported by the processes in the Communications Management knowledge area. The processes in this area manage all project communications. The Risk Management Plan will identify the information, how it is captured, and how it is maintained. The Communications Plan will describe to whom, when, and how the information is to be communicated.
Monitoring Specifies that ERM is monitored and changed when necessary. Monitoring and change are performed in 2 ways: ongoing management activities and audits.
PMBOK® Alignment Monitor and Control Risks supports this component. This process uses Risk Reassessment, Variance and Trend Analysis, Reserve Analysis, and Status Meetings to monitor risk management activities and ensure that the activities are meeting the project’s goals and objectives. This process also describes audits as a technique for determining whether planned activities are being carried out and are effective. One of the outputs of this process is updates to the Risk Management Plan in the case where activities are not effective in controlling risks. Preventive and Corrective actions are also recommended to address cases where activities are not being carried out, or are incorrectly performed.

ERM provides for assurance that it is effective by determining if all 7 components of ERM have been provided for, across all 4 categories of organizational goals and objectives. Project management will not cover off all areas of each component in each category, but will cover those organizational goals and objectives supported by the project and all the reporting and compliance goals and objectives that apply to the project.

Internal Control for ERM is provided for by the guidelines described in the Internal Controls – Integrated Framework document authored by COSO. We won’t go into detail describing these guidelines but treat them at a summary level. The ERM study aligns with the guidelines and refers the reader to that document for compliance details. The details of compliance would concern an organization implementing ERM but that must be instigated by the Board and would only concern a project manager if they were to be responsible for a project which implemented ERM. The guidelines place risk controls with other internal controls of the organization (keep in mind these guidelines are insurance and finance-centric). The guidelines provide for the assignment of responsibilities to 3 organizational roles: the Chief Financial Officer, the Chief Information Officer, and the Chief Risk Officer. The Chief Legal Officer is identified in lieu of a Chief Risk officer. The CFO is responsible for monitoring internal control of financial reporting, the CIO is responsible for monitoring internal control over information systems, and the CRO is responsible for monitoring internal control over compliance with laws, standards, and regulations. The guidelines re-iterate that risk management tone is set from the top of the organization as evidenced by the company officers responsible for monitoring.

The Internal Control – Integrated Framework guidelines also acknowledge that monitoring and control are prone to human error and that not all procedures have equal importance. They address this by the identification of the most critical procedures using “key-control analysis”. Key-control analysis is used to determine whether control procedures and processes are effective. The guidelines also attempt to provide direction in the identification of preventive or corrective actions to improve internal controls. They do this by evaluation of the information measuring the effectiveness. Only if the information is “persuasive” should corrections be made. The guidelines provide for internal audits of internal control procedures but acknowledge that every organization may not be large enough to warrant that role and that there is a place for external audits in internal controls.

Most of the reporting the project manager will be responsible for will be what the guidelines term as “internal”, that is the reports will only be read by management. In some cases reports may be read by 3rd party external organizations. The project manager’s reportage on risk management on their project may form a part of the information reported externally, but the project manager should not be made responsible for reporting externally.

The guidelines require that implementation of a framework be scaled to suit the size and complexity of the organization it serves. Scalability will require the organization to identify who will be responsible for a given activity. For example, the organization may not have a Chief Risk Officer in which case some other role must be identified for compliance responsibility. This responsibility will be delegated to the project manager when any compliance objectives form part of the project’s objectives.