Put risk management training wheels on your project support office
Bruce C. Chadbourne, PMP, Systems Engineering Project Manager, Sanders, A Lockheed Martin Company, Nashua NH
How do you establish an effective Project Support office in your company? Can we start by assuming that you have senior management commitment to the idea? After paying attention to the establishment of policies, processes, and training that define the mission of the project office in your company, before long the need for effective risk management in and across your projects will become painfully apparent. The cry for more effective risk management is well documented in PMI ’99, in recent issues of PMI® literature (Ward, 1999; Royer, 2000), and no doubt in the PMI 2000 Risk Management track. Companies that do not actively practice risk management are becoming aware of the need, as evidenced by the increasing demand for training and PMP® certification.
Defining risk practices and even conducting the training are not sufficient to yield an effective risk management experience. A certified project manager must grasp both the hard and soft tools to succeed in this endeavor. In the PMBOK® Guide, the concept of good integration of the project management knowledge areas is clearly stated (PMI, 1996, p. 39). Curiously, Risk Management, so completely intertwined with the attitudes and discipline of the project manager and the project team, is referred to as a “facilitating process.” Good project management and risk management are inseparable. Whether planning, executing or controlling, one does none of them without addressing the associated risk.
To be sure the PMBOK® Guide treatment of risk management is done very well. It is succinct and embraces a “K.I.S.S. (keep it simple)” approach to the activities of identification, quantification, response development and response control. However, as I teach classes on this subject, there is an ingredient that is inevitably identified as missing by one of my students: “What do I do with all of this information? There seems to be no consistent approach, leaving me to guess how to assemble and maintain the risk data.” In this paper I propose that a companion K.I.S.S tool be recognized in PMBOK® Guide, which so far has been overlooked by its stewards.
Enter the Risk Database
Your team has just finished a brainstorming exercise in which they participated wholeheartedly, identifying numerous risks that threaten the success of your program. After the last box of pizza is consumed and the conference room is cleaned up, you hold in your hands a large roll of chart paper containing list upon list of risks—the collective wisdom of your team. Where do you start in reducing perhaps 40, 60, or 300 items into a useful form? As in the classic tale of the Red Hen baking the bread—who will you get to help you? Will the vital risks end up on the floor behind the door of your office, after perhaps choosing three or four of the easier ones to put into your next management report?
The answer is obvious to many of us—the data should be organized in some systematic way in a spreadsheet, or a structured format, perhaps best implemented using a standard PC database product. The idea is not new; but a new practitioner might be disappointed when PMBOK® Guide does not highlight the concept.
In witnessing numerous projects in the defense systems engineering and software development world, these databases spring up in various forms and degrees of complexity. Often a project team learns that the customer wishes to impose their “tool of choice” on the project. Within a larger company, especially one that has recognized the need to establish the Project Support Office concept, there are benefits to be realized in developing a local standard approach to the database.
There exists among the readers a group of individuals who are repulsed by the suggestion that a “tool” is the answer to a process problem, and rightly so. Many sins have been committed by company staffs that become enamored by glossy marketing brochures, which claim to offer the ultimate tool for world-class management of any project. I am not advocating the PMBOK® Guide compromise its excellent standards by stooping to this. The kind of database tool I am recommending is consistent with the usage of the term “tool” or “technique” currently used in PMBOK® Guide.
Better still, the kind of database I am suggesting is currently freely available and can save the project manager the time and frustration of having an engineer develop a homegrown, custom database. A readily available example exists and can be implemented almost overnight on your project or in your project office (while the company staff continues to deliberate over which “company standard” miracle tool they will buy for the organization).
Granted, the commercially available project management tools, and the risk management tools in particular, provide specific capabilities that can serve your project. However, a project office that has only basic maturity in its understanding of risk management needs to start with something much simpler, hence the “training wheels” approach to learning to ride the risk management bicycle.
Exhibit 1. Risk Database Fields
Such an example is the Risk Radar© database, developed by Integrated Computer Engineering, Inc. (ICE) for the Software Program Managers Network (SPMN) under contract by the United States Department of Defense. One may download it free of charge from the ICE and SPMN Web sites at: http://www.iceinc.to and http://www.spmn.com. Many of us could and indeed have produced similar instances. I would encourage one to download this readily available example and consider whether it requires any modification before starting to use it on your project. Consider how a simple database does facilitate the implementation of the PMBOK® Guide risk management process. In the following discussion I will explain how it serves as a simple companion, aiding the project manager in controlling the project risk data, and facilitating the integration of other aspects of the PMBOK® Guide process.
What is a Database?
To emphasize the need for a generic tool and not a specific market product, go to a more recent dictionary to learn that a database is “an extensive body of information organized and stored in a computer's memory for the quick retrieval of data in response to particular queries” (Webster, 1997). One of the original purposes of computers after all is the high-speed storage and retrieval of information.
Many students of my risk management class tend to think of smaller projects in which only a handful of risks exists. This may be true on the smallest of projects, but on most projects where effective risk management is practice, be prepared to manage dozens if not hundreds of risks. Such information could be stored in a box of index cards, or maintained in a simple word processor document, or a spreadsheet. Some refer to it as a risk register (Ward, 1999, p. 41).
The current commercial PC database products are ideal because they include an acceptable set of features such as random access, indexed records, searching, report writing, customizable forms, multi-user access.
Suppose one does implement the simplest database, a shoebox filled with index cards? One card or record is established for each risk identified in the project. What data is managed? Exhibit 1 shows the table of minimum and recommended data for each project risk. Minimum criteria are based upon the current PMBOK® Guide. The recent work by Paul Royer offers a similar data structure for managing risk (Royer, 2000, p. 10–13).
Included in Exhibit 1 is a column identifying which PMBOK® Guide Risk process resulted in creation of the data. It is important to establish one's project office-specific process so project team members have a consistent and efficient method for determining this information. Refer to the PMBOK® Guide “tools/techniques” for additional insight on the methods for generating this information.
Exhibit 2. Risk Radar Title Screen
After the risk is identified and a record started, the risk must next be quantified. The database is well designed to handle both the quantification factors, plus text statements providing the basis for estimating these factors (as well as text statements documenting the changes to these values over the life of the project). The PMBOK® Guide concept of change control and communications management applies here. For risk management to be effective, changes to the risk data, which results in prioritization and commitment of project funds, must be controlled. Likewise, retaining the history of changes and distributing this information to appropriate stakeholders are features readily provided by the database.
The database further brings order out of chaos by handling the sorting of risks, normally in order of their priority based on the quantification factors. This allows the project manager to establish direction for the team, ensuring that the truly important risks receive the attention and expenditure of the limited reserves.
During the process of risk response development the person assigned provides specific, actionable plans and records them in the database, subject to approval of the project manager. The database provides tracking of the budget, expected completion date and historical narrative of the successes of these plans. A more sophisticated tool will integrate this information with the project schedule, work breakdown structure and cost budgets. Also a more capable project team would define risk performance measures and triggers so that alternate contingencies might be applied if the initial risk controls are not sufficient.
As the project proceeds and the risk is being successfully reduced by effective risk response control, the database record is easily maintained. As the risk factors are reduced, or as project team decisions are made, the result is recorded and available for distribution to the project stakeholders according to the communications plan.
Exhibit 3. Risk Identification and Quantification
Exhibit 4. Risk Response Development
How do the Process and Tool Interact?
Given the PMBOK® Guide process and the data elements identified in Exhibit 1, the following is an illustration of the database, using sample screens from Risk Radar©. The title screen, Exhibit 2, provides a simple user interface. The various features, such as data entry and report writing, are activated by the click of a button.
Next, data entry is accomplished with the form titled “Edit Risks Long Form” shown in Exhibit 3. The project manager or designee transcribes data from the Risk Identification process into the appropriate fields. Notice that in addition to the minimum set of data elements, use can be made of additional keyword fields that allow further classification of risk information.
During the Quantification process, the responsible person estimates the probability and impact of the risk. As a further good practice, the basis of these estimates should be recorded (see the risk description field), allowing subsequent discussion and revision of the estimates as appropriate. The database automatically computes the “Risk Exposure,” which is comparable to the expected monetary value (treated in Risk Radar© as a dimensionless quantity). The standard database indexing features then sort the risks based on the relative value of the risk exposure.
Given a prioritized list of risks, the Project Manager selects the higher risks for in-depth risk response development and assigns them to team members for further planning. The individual makes use of additional fields in the “Edit Risks Long Form” (see Exhibit 4), providing a description of the response plan for mitigating the risk, and the contingency plan should the mitigation be unsuccessful. Risk Radar© also provides fields to enter and track completion of specific action plans under “Risk Mitigation Steps.”
The final field illustrated is the “Historical Events Log” which serves as a narrative of the risk during the project risk response control. Any decisions concerning the risk are recorded to ensure proper change control discipline. Other fields of the data may be updated, in which case a note may be entered.
During the Risk Response Control phase, the Project Manager makes use of the report writing features of the database illustrated in Exhibit 5. A summary report provides a listing of all risks, showing their relative priority and a summary status of the individual assigned to manage the risk and the current status. This is useful in communicating to certain stakeholders in the project Communication Management Plan.
A more detailed “full-page” report format allows the full story of a specific risk to be viewed. My practice is to convert these reports to transparencies for viewing during the project staff meeting. This is a straightforward approach to keeping all staff members aware of the risk and to hold specific members accountable for risk response actions. The chart is easily marked up to reflect current status, allowing changes to be keyed into the database immediately after the meeting.
Advice to the Project Support Office
The Project Support office can quickly standardize its projects through a consistent use of the database and the accompanying instructions for managing risk data. Standard definitions for the probability and impact assessment will keep a project from spinning its wheels in reinventing these techniques. The project office can accelerate the performance of the project teams by providing both training and administration of the databases to offload clerical duties from the project staff.
The needs of company or functional management may be further addressed by giving the project support office the role of collecting risk progress from its various projects, summarizing and reporting the information for management review.
Exhibit 5. Risk Response Control (Summary and Detailed Reports)
The Project office also serves as keeper of the risk databases from completed projects. These can be combined, searched, and analyzed as needed to identify common or recurring project risks. The project office staff should contribute to subsequent project risk identification brainstorming by representing the organization's lessons-learned on previous endeavors. The application of standard conventions for risk metrics and triggers may improve the overall quality of project management within the organization.
The project manager's role as integrator of project resources and information is illustrated by the task of managing diverse risk information. The use of a simple database, which by its nature manages the relationship of disparate types of data (text, dates, values), is vital to performing this task with a sense of consistency, accuracy and convenience.
Future clarification of the PMBOK® Guide Risk Management process to include references to this type of critical tool would serve the community well. In the meantime, the well-informed project manager will find in simple database applications such as Risk Radar© the “training wheels” to make project team members effective practitioners of the simple disciplines of risk management.
Royer, Paul. (2000, March). Risk management: The undiscovered dimension of project management. Project Management Journal, 31 (1), 6.
Ward, Stephen. (1999, September). Requirements for an effective project risk management process. Project Management Journal, 30 (3), 37.
“Webster Illustrated Contemporary Dictionary, Encyclopedic Edition.” (1997). Sidney I. Landau, editor, J.G. Ferguson Publishing Company, Chicago.
The author expresses sincere thanks to Integrated Computer Engineering, Inc. and the Software Project Managers Network for consenting to the use of references to Risk Radar©.
Proceedings of the Project Management Institute Annual Seminars & Symposium
September 7–16, 2000 • Houston,Texas,USA