As young children, our parents do their best to protect us from harm. We're taught not to play in the road or speak with strangers. As we grow and our environment changes, these foundational lessons guide us even when we are old enough to know better than to touch a hot stove.
When my wife and I had our first daughter, we had a very low Risk tolerance. We child-proofed every corner of the house, sanitized every surface, and never fed her candy. At that moment, our Risk radar was solid red. It was hard to see areas where there wasn't danger around every corner. Over the years we relaxed, and by the time we had our third child, we stopped sanitizing surfaces that likely would never be touched and even allowed the youngest to eat that piece of candy Grandma was always trying to give the kids. Our Risk tolerance level raised significantly as we gained context on parenthood.
We didn't realize that all along we were conducting Risk analysis. Risk analysis is a process of evaluating the result, or Exposure, of either a positive or a negative event occurring. When considering Risk Exposure, consideration is given to two factors:
- What is the Probability of that Risk?
- What is the Impact of that Risk if it were to occur?
Based on that assessment, Risks are generally categorized into one of three buckets:
- Red Risks have a high exposure rating. These are the Risks that we continuously monitor. For these Risks, we develop detailed qualitative mitigation plans. However, with Red Risks, we also spend time to determine the quantitative impact of the Risk.
- Amber Risks are the Risks we monitor regularly, but not continuously. For these Risks, we generally only focus on the qualitative impact of the Risk.
- Green Risks are similar to the tooth your dentist tells you "we're going to keep an eye on this one". You know these Risks could become an issue down the line, but that is either of low impact or low probability.
Risk tolerance is unique to the culture of an organization. Teams dealing with life safety or teams that are extremely risk-averse might have a Risk tolerance table that looks like this:
In some organizations, this may, in fact, be an accurate representation of their Risk decision table. If you send humans into space, or similar zero-fail situations, nearly any risk being realized can be catastrophic. For most, however, this decision table would be unrealistic. As the cost to mitigate or avoid all red Risks would be prohibitive, this aggressive categorization could cause the "real" red Risks to get lost in the shuffle.
After years of refinement, this decision table is more commonly used in industry.
Many organizations initiate Risk Identification from the ground up. This literally means starting from scratch and asking "So, what are our Risks". As stated in PMBOK, the Project Management Body of Knowledge, there are specific techniques organizations may leverage to identify Risk. The most common of these techniques include documentation review, brainstorming, interviewing, root cause analysis, assumption analysis, and more commonly, expert judgment. Each of these has provided an opportunity to identify Risks, yet still lacks the function of leveraging historical data across the organization.
As part of the Identification stage, many organizations do not necessarily consider the wide array of possible Categories of risk. Typically, Categories of Risk are only considered from the four major management categories of Scope, Cost, Time, and Quality. However, there are many other Categories of Risk that should be considered. Examples of these include Resources, Materials, Equipment, Customer/Client, Technology, Delivery, Regulatory, Governance, or Political.
Most people agree that Risk Management is not necessarily the most exciting knowledge area and historically takes a back seat to what some may consider the "real work" of a project. In fact, Risk Management is the weakest of all project management maturity knowledge areas according to William Ibbs and Young H. Kwak1. This statement holds even more truth as you evaluate the maturity of technology-based projects. As a Risk Officer, the largest challenges I've seen regarding effective Enterprise Risk Management comes down to an organization's Risk culture. Is an organization Risk-aware or are they Risk-unmindful? Does an organization perform effective Risk management or do they simply check the box that they've considered a risk? This culture is generally driven by the top of the organization.
Some Risk-aware organizations celebrate Risk as a management tool to be prepared for known challenges. These organizations have well-documented plans and contingency budgets to address Risks based on both priority and approach. Other Risk-unmindful organizations appear to punish projects for identifying Risks. In some extreme cases, organizations are literally told they should never report a red Risk for fear of "looking bad". These are the projects that quickly go from "Green" to "Red", or even into Issue mode
It may seem counterintuitive that an organization doesn't wish to prepare for Risk or feels that Risk isn't "their problem", yet many managers have learned that reporting a risk can be worse than dealing with the fallout. Risk management starts with encouraging open and transparent communication surrounding Risk. Some of the more concerning comments I've heard in my career which are counterproductive to Risk management have included:
- "Your Risks make us look bad"
- "We won't read your' risk register"
- "You can report Risks, just don't report anything as red"
- "These are your Risks, not our Risks"
- "These aren't Risks, because they haven't happened yet"
- "We already did the Risk management when we came up with the list at the start of the project"
Even within an organization that has created a culture of openly addressing risks, individual projects often keep their Risk registers as a silo, making the enterprise-level analysis impossible.
Regardless of an organization's Risk Management competency, Risks are organic and will change in probability or impact over time. Approaches to address Risk or the Risk itself also evolve over time as more information becomes available or as better ideas to address Risk are identified. Organizations face this same need to review current Risks to ensure they remain both relevant and timely. The challenge they have is tracking the risk cadence based on evolving exposure.
Finally, though some programs work hard to monitor for external changes in Risk, it is difficult to constantly monitor data that is not reported consistently, as in the case of an SMS feed from a data source or in the case of a heart rate monitor connected to a patient.
What we've just defined are some of the challenges of Enterprise Risk Management. In summary, these challenges include:
- Starting from scratch every time
- Storing Risk in silos
- Allowing Risks to stagnate
- Lacking intelligent automation
- Fostering a Risk-aware culture.
In late 2020, CollabraLink introduced its Enterprise Risk Management (ERM) product. As both a Risk evangelist and the ERM Product Owner, I worked with the CollabraLink LinkLab team to develop a solution that addressed each of the challenges I've discussed.
CollabraLink built an Enterprise Risk Management solution on the Appian platform to deliver a comprehensive suite of reports, analytics, and metrics meeting industry standards, but delivering far more for the federal government. We chose Appian as the hosting platform for several reasons.
- Appian's low-code capabilities allowed us to quickly prototype, develop, and deliver the product.
- We were able to retain our Risk data on our current infrastructure, without the need to rehost the data.
- Appian's complete automation allowed us to use Appian's native workflow, RPA, AI, business rules, and case management to create an enterprise-grade application using Appian's feature-rich components.
Risk management is an active process. Whereas worksheets such as Excel or Google Sheets can list Risks, they lack the necessary capability to perform active case management of Risk, including security, auditing, escalation, and intelligent automation. ERM is unique in that it leverages AI to guide users through the creation and evaluation of Risk. Leveraging existing Risks, ERM uses AI to suggest approaches to both capturing and planning for similar Risks. ERM supports guided categorization and identification through Appian's intuitive wizard-like interface. By not starting with a blank sheet of paper, users are able to harness existing Risks to develop and maintain a more comprehensive risk register.
ERM's executive dashboard provides a highly interactive user experience to ensure individual managers have awareness of their key Risk metrics. Authorized users can dynamically filter ERM data and drill down from the enterprise to the program or base levels. This allows for executive awareness of Risk across the enterprise and provides a means to quickly focus on the significant Risks rather than interpreting static reports. Since ERM captures the complete history, including field-level logging, executives are able to obtain situational awareness without needing to go outside of ERM for the desired data.
CollabraLink ERM is consistent with common ERM frameworks such as ISO 31000, ISO 27000, ISO 9001, PMBOK, and the GAO's Enterprise Risk Management framework.
Finally, CollabraLink ERM is unique in that it incorporates Appian RPA to actively monitor for changes to Risk probabilities based on data outside of our domain. For example, if we were to track a Risk pertaining to license compliance and that compliance data did not provide a native interface to evaluate the data from another system, we would configure ERM to actively monitor the specific criteria within the licensing systems using Appian RPA to monitor potential changes in Risk exposure, actively notifying both Risk owners and watchers of the potential impact.
Interested in learning more about CollabraLink's ERM solution? Check out CollabraLink's ERM demonstration video. If you would like to learn more about this solution, contact the CollabraLink team at ERM.Info@CollabraLink.com.
-------------------
1C. William Ibbs and Young Hoon Kwak, Assessing Project Management Maturity, Project Management Journal 31, no. 1 (March 2000), pp. 32 43.
