By Dawnell K. Claessen | Senior Member
Risk is everywhere and there are many different types of risks that can affect an organization. Managing risk is something that everyone does in one way or another, but the degree of formality and the nature of the process varies widely.
For those who work in the financial or manufacturing sectors, risk management (RM) will likely be a high-level strategic activity concerned with returns and quality. For the public sector, RM will be most likely concerned with public safety and welfare. And for those of us who work in technology, we will encounter RM throughout our careers as part of our organization’s security management plan and strategy.
Risk Management and Technical Communication
For a technical communicator, bringing your skills in communication and documentation to the risk management process can make important contributions to your organization and be a big boost to your career. And for those who are really interested in RM, consider also how integral and strategic risk communications are to any well-run RM program. For any technical communicator, adding even the basics of a risk management skillset to your résumé is something well worth considering.
Risk Management Context, Definition, and Scope
Because the term risk is used in so many different contexts, one of the first and most challenging tasks associated with RM is defining risk and tailoring RM to meet the specific needs of the organization. The definition of risk and terms associated with RM are not complicated, but they are extremely context sensitive, and terminology and usage often vary significantly from one organization to another.
So much variation exists that the International Organization for Standardization (ISO) publishes a Risk Management Vocabulary: The ISO Guide 73. The 2009 edition is available online and it has about 15 pages of definitions (www.iso.org/iso/catalogue_detail?csnumber=44651). The official ISO definition of risk is deceptively simple: “the effect of uncertainty on objectives.” This effect can be either positive or negative. Except for the financial industry, most RM activities are concerned with mitigating the negative effects of risk.
Risk Management Activities
Establish Context: Risk context is established by defining assumptions, goals, and objectives for your RM activities. Your organization may also wish to identify what exactly is at risk and what laws and regulations apply. When context has been established, and risk is properly defined and scoped as it pertains to the organization, it becomes easier for the organization to plan and to develop a framework and a process for managing risk. At this early stage, the organization may have draft of a risk management plan (RMP) with at least a preliminary agreement on a division of activities and responsibilities for the next RM activities.
As the context is being defined and scoped, plans to conduct an initial risk assessment (RA) should be drafted. The initial RA may be done at the corporate level, department level, and often down to the product or project level, depending on the needs of the organization. During the RA, risk is identified, analyzed, and evaluated to determine the appropriate treatment (or disposition) of a particular risk.
Identify Risks: The identification of risks is as simple (and as complicated) as discovering, defining, documenting, and communicating the existence of a particular risk. According to the organization’s specific needs, the initial risk identification activities may be conducted from a high, more strategic level, resulting in a comprehensive list of all the risks identified, commonly called a risk register.
For a smaller organization, a risk register may be a simple list compiled from team member contributions or lessons learned from previous experiences. For larger, more complex organizations, approvals may be necessary, as well as naming conventions or taxonomy. These are all typical parts of a systematic and repeatable process for identifying risk.
Analyze & Evaluate Risks: Risk analysis and evaluation looks at an identified risk and attempts to predict how likely it is to occur and, if it did occur, what the impact would be to the organization. The likelihood of and the impact of occurrence are often assigned values and an overall score of likelihood plus (or times) impact is assessed and noted on the risk register. This is often referred to as quantifying risk. Some types of risk are very difficult to quantify, such as a loss of reputation or good will, and those risks are often expressed in more qualitative terms like catastrophic or severe.
There are various ways to score risk and express the results. A three-by-three (nine box) grid is often used with a red, yellow, and green color scheme. The risks with the highest scores (most likely and most serious impact) are shown in the red boxes, the risks with middle scores are shown as yellow, and the lowest scored risks are shown as green. A simpler expression would be a quadrant like Table 1.
Treat Risks: There are several ways to treat risk. The most common risk treatment is risk mitigation. Risk mitigation is the implementation of measures to reduce the likelihood of risk occurrence and/or to reduce the impact of a risk occurrence. These mitigations can be implemented to the extent practically feasible, either financially or technically.
It is on risk mitigations that organizations will spend a significant portion of their risk management and security budgets. This is especially true about information technology (IT) risk mitigation. This holds true when mitigating the risk associated with IT as the organization’s primary business (like a software development organization) and also when mitigating the risk associated with IT as a support function within an organization engaged in a line of business that is not IT (like a financial organization).
If the risk can be quantified in financial terms, the organization may choose to transfer the risk, typically by purchasing insurance. Often, organizations simply decide to accept any risk that remains (called residual risk) after all treatments have been implemented.
Monitor and Review: Once an organization has cycled through all the RM activities at least once, the risk management plan can be updated and finalized. But RM is likely to always be a volatile process, and it should be monitored and reviewed for process improvement opportunities. Ideally, an RM process would aim for continuous improvement of process maturity and may even follow a model, such as Carnegie Mellon’s Capability Maturity Model Integration (CMMI).
Communicate and Consult: Risk management relies upon clear and concise communication. A lot of documents flow from the RM plan and many are related to one another. For example, an incident response plan describes what to do if a risk event does occur and a disaster recovery plan talks about restoring operations after a risk event.
In addition to the risk management plan, the risk register, the risk analysis and evaluation artifacts, and the risk mitigation plans, there is also the creation and maintenance of the risk management framework and the underlying risk management process, with its policy and procedure. And there is always the need to communicate and collaborate with other stakeholders, both internal and external.
Opportunities for Technical Communicators
The RM process has so many artifacts, deliverables, documents, plans, and reports that the opportunities for technical communicators should be obvious. But they are not at all obvious, and it is my opinion that technical communicators could add significant value to the entire RM process if we choose to get more involved. I see a lot of opportunity and unmet need for better risk communication, especially in external communication about risk and risk events.
Still, there are very few career/full-time risk managers. If you do choose to get involved, you will likely start with something simple, such as participating in a document or process review. If you are really interested, my advice is to simply persist. Volunteer and join the team as a documentation specialist or process analyst and persist your way up through subject matter expert and risk manager for your group or for a project.
Conclusion
Most of us of excel at facilitating communications about complex ideas and abstract concepts like risk management. We understand well the inter-relatedness of our organizations’ people, products, and processes, and we know how to explain these things to others. I got involved simply by offering to help manage a system of related documentation which evolved over time into security and risk management documents. It has been my experience that an offer of help is rarely refused, so dip your toe into the risky business water!
Dawnell K. Claessen (mail@dawnell.com) is a technical communicator and certified security systems professional (CISSP) specializing in security certification and accreditations of information systems operated by the Military Health System. This includes a lot of risk management shenanigans. Dawnell holds a Master of Library and Information Science with a specialization in federal information policy from the University of Texas at Austin. For STC, Dawnell also acts as comanager of the Policies and Procedures SIG.
Risk Management Resources
Carnegie Mellon Software Engineering Institute’s Risk site, www.sei.cmu.edu/risk/.
Carnegie Mellon Capability Model Integration, http://cmmiinstitute.com/. Excellent process model information.
The Institute of Risk Management, www.theirm.org. An excellent resource for aspiring risk management professionals.
The Institute of Risk Management publishes their own RM standard, which is concise and an excellent resource, www.theirm.org/publications/documents/Risk_Management_Standard_030820.pdf.
International Organization for Standardization Risk Management Vocabulary, www.pqm-online.com/assets/files/standards/iso_iec_guide_73-2009.pdf. The ISO Guide 73. Read this first.
NASA Risk Management Handbook, www.hq.nasa.gov/office/codeq/doctree/NHBK_2011_3422.pdf. Very through CMMI Level 5 RM (long).
NIST National Institutes of Standards and Technology, http://csrc.nist.gov/groups/SMA/fisma/framework.html. I use this resource nearly every day.
Risk World: Events and News in the field of Risk Management, www.riskworld.com/.
Wikipedia’s Risk Management Wiki, http://en.wikipedia.org/wiki/Risk_management. I offer the usual Wikipedia skepticism and warnings, but overall, this RM Wiki is pretty good. There are lots of links to RM good resources.
A list of the Environmental Protection Agency’s Seven Cardinal Rules for Risk Communication, http://en.wikipedia.org/wiki/Risk_management#Seven_ cardinal_rules_for_the_practice_of_risk_communication.
Note: A Web search conducted on risk management and your field of interest or practice will likely yield some useful results.
