Put risk management training wheels on your project office
by Bruce Chadbourne, PMP
Enhance risk management with a risk database.
THE FAILURE OF PROJECT ORGANIZATIONS to establish a meaningful risk management mind-set was a recurring theme in the risk management papers of PMI's 1999 and 2000 Seminars & Symposia. Whether the uncertainty as to where to begin or the behavioral barriers to sustaining constructive activity, too much of risk management is based on good intentions and insufficient follow-through.
In conveying the fundamental tenets of the risk management process, A Guide to the Project Management Body of Knowledge (PMBOK® Guide [all references are to 1996 version]) does not mention the vital importance of a simple database or repository of risk information. While generally it is appropriate to avoid the pitfall of confusing the attributes of processes (the PMBOK® Guide's purpose) with myriad tools that support those processes, in this case one should make sure he is not navigating the “risk management river” without a proper canoe and paddle. By analogy, one cannot study the process of riding a bicycle for very long without actually obtaining the “tool” on which to practice.
Bruce Chadbourne, PMP, is a systems engineering project manager with Analytical Solutions Inc. of Dahlgren, Va. His 25-year career includes service as a Naval officer, and as an engineer with G.E. and Lockheed Martin. He is also an instructor of project management certificate programs at the Boston University Corporate Education Center. In addition, he serves as Region I director of PMI's Risk Management Specific Interest Group.
Whether in the PMI® symposium exhibit hall or on the Internet, one finds numerous examples and types of tools designed to support risk management. These vary in complexity and have been designed to promote specific types of risk analysis, such as probabilistic schedule modeling, expert interviews, and decision trees. The unwary consumer in search of risk management support needs to know where to go for help before investing good money in one of these advanced, commercially available solutions.
The Risk Database. Each risk management process in the PMBOK® Guide (risk identification, risk quantification, risk response development, and risk response control) is defined by its respective inputs, tools, and outputs. The “tools” mentioned point the practitioner to important concepts, but the idea of a simple data repository is missing.
Simplicity is indeed the key—the risk manager may find it helpful to store risk information in a spreadsheet, a document file, or a generic database. The only problem is how to get started and not waste a lot of time establishing a useful mechanism with the basic essential features, such as report writing, searches, and summary statistics.
The good news is that one does not need to look far for an example. In my practice as a risk manager in the defense industry, I have made good use of a freely distributed risk database tool called Risk Radar©. This product was created by John E. Moore, Ph.D., of Integrated Computer Engineering Inc., for the Software Program Managers Network (SPMN) under contract of the United States government. It is freely distributed on the Internet at www.spmn.com/products_software.html. While many similar homegrown databases exist, I recommend it for its accessibility and adaptability (see sidebar) to the needs of the user. The only prerequisite is having Microsoft AccessTM installed. The tool supports each step of the PMBOK® Guide process, and from personal experience, I can vouch for its practicality in the day-to-day implementation of my projects. Exhibit 1 shows an example of the database's title screen.
Support for Risk Identification. Primarily, Risk Radar is the place where identified risks are collected and stored, as shown in Exhibit 2. When my team performs a new project launch, we conduct a brainstorming session—using all of the PMBOK® Guide methods (for example, checklists, interviews, WBS, cost estimates). This activity generates a long list of risks (usually 50–100), which is immediately captured in Risk Radar. Each prospective risk is entered as a single record, along with any initial estimate of its defining factors.
Risk Radar Title Screen
Exhibit 1. The fundamentals of the PMBOK® Guide risk management process are supported by a basic risk database such as Risk Radar.
Edit Risks Screen
Exhibit 2. Capture data created during the risk identification process in the “Edit Risks” form.
Print Reports Screen
Exhibit 3. One click on this control screen generates formatted reports of risk in formation to support detailed risk analysis and review.
Ways to Enhance a Risk Database
■ Risk Radar© includes raw data fields such as Program Areas, Affected Phases, and Control. These could be enhanced by the use of queries and reports that summarize risk data to support project office analysis of risk.
■ In my use of the tool, I added data fields to record and monitor risk impact in dollars. This information can then be included in reports, giving senior management greater appreciation for the magnitude of the risks.
■ I found it necessary to add a query and report that helped track the delinquency of open action items. This created a “hot list” for the weekly risk meeting to ensure that progress was being made.
■ The reports presently included in Risk Radar do not provide summary statistics, such as total risk exposure. Tracking this as a metric over time would provide insight as to the effectiveness of risk control actions.
After the session, the risk manager spends time reviewing the entries. Similar risk items may be combined or restated so as to discriminate the importance of each. Specifically, the Risk ID (Title), Description, and Responsible Person fields are completed. Additional fields may be used to categorize the risk, highlight the impact time frame, or record amplifying information about the program area and phases affected. Finally, a detailed report (see Exhibit 3) for each risk is printed and distributed for the responsible person to conduct the next process step, quantification. Of course, one benefit of the tool is that it is available to multiple users online, who may perform their work in a “paperless” fashion.
Where the PMBOK® Guide describes the use of historical information as an input to Risk Identification, the benefit of a tool such as Risk Radar should be immediately obvious. At the end of a project, the risk database can be copied and delivered to the next project team, providing a ready list of likely risks and a history of the actions taken to mitigate them.
Reader Service Number 059
Support for Risk Quantification. As each actionee begins analyzing and quantifying the assigned risk item, Risk Radar provides elementary support for recording the probability of occurrence and impact. It includes a formula for computing the total risk factor. In my practice, I require a “basis-of-estimate” statement in the risk description field that records the reason for choosing a specific value for probability and impact. This aids later discussion and updating of the risk.
In my practice as a risk manager in the defense industry, I have made good use of a freely distributed risk database tool.
The Risk Radar approach to quantification is very simple. Impact is a dimension-less scale of 1 (low) to 5 (high), as shown in Exhibit 4. (See the sidebar for desired enhancements to this feature.) This simple approach leaves the project team to establish a manual method for selecting appropriate risk parameters such as suggested in the PMBOK® Guide. On my projects, I have provided basic definitions of probability and impact in the risk management plan to give guidance to my team members. Not being hardwired into Risk Radar, these definitions are easily modified and migrated to another project.
Risk Factor Definitions
Exhibit 4. Defining standard probability and impact terms in your project office risk management plan promotes uniform quantification of risks.
Reader Service Number 078
Risk Response Development
Exhibit 5. Coordinate the development and maintenance of risk response plans using the “Edit Risks” form.
Risk Response Control
Exhibit 6. Facilitate weekly risk management update meetings with formatted printouts.
Support for Risk Response Development. In my project risk process, the individual actionee proceeds immediately to the task of proposing a risk response. The actionee is required to describe in narrative terms in the Risk Mitigation Description text field the proposed strategy for mitigating the risk. This description should describe thresholds or triggers that will be measured to gauge the effectiveness of risk control. This mitigation is further defined in the Risk Mitigation Plan field with specific, measurable action items, with assigned persons and due dates, as shown in Exhibit 5.
In the Contingency Plan field, the actionee describes predefined steps to be taken if the identified mitigation fails to prevent occurrence of the risk event. This should include an estimate of the contingency cost so that appropriate budget and schedule reserves are considered.
In the Set Up Project option, Risk Radar allows the user to adopt the PMBOK® Guide terms for risk response types, such as avoidance, mitigation, or acceptance, or to adopt other preferred terms.
At this stage of the risk quantification and response development processes, the risk manager conducts a planning approval meeting to review the proposed plans with the project leaders. I find Risk Radar very convenient in printing out the summary and detailed reports in hard copy and viewfoil media to facilitate an efficient review.
The team provides the critique as the assigned actionee for each risk presents the proposed plan of action. The comments and agreed changes are immediately captured by marking the viewfoil (or entering the data online if electronic projection is used).
The final risk management plan is produced as a detailed report of cumulative risks. It is briefed to senior management to obtain necessary approvals and commitment of risk management reserves [PMBOK® Guide, 11.3.3].
Support to Risk Response Control. Risk response control is a continuous action during the project. As risk manager, I conduct weekly update meetings on the status of risks in the Risk Radar database. Summary and detailed reports, illustrated in Exhibit 6, can be formatted and printed. We review actual risk events and also conduct additional risk identification [PMBOK® Guide, 11.4.1]. Factors affecting the risk may have increased or decreased in significance, thus affecting the probability and impact values.
We ensure that assigned actions soon due are statused and appropriate updates are made in the database. For example, if an individual has been assigned to perform an analysis, the results of that analysis may in fact result in a reduced probability or impact of the risk. The team approves the revised value and the database is updated. The Historical Events Log provides a narrative record of results and decisions regarding the risk item.
The use of a database tool such as Risk Radar significantly enhances the management of risk information. Coupled with office e-mail, the information is readily distributed among project team members and can be shared with customer team members in professionally formatted working reports.
AS THE PROJECT OFFICE TEAM becomes more sophisticated, more advanced tools provide needed support. However, the basic tenets of the PMBOK® Guide risk management process are universal. A generic database product that supports an application, such as Risk Radar, will serve a project of almost any size, and, in fact, can serve the project office concept where multiple projects need to share similar information. ■
PM Network February 2001