An example implementation of a risk management practice with all the processes, methods, and tools defines for the risk engineer how the practice would be integrated into a project. An example implementation has the following components:
The components of an example implementation of a risk management practice are:
The organization's structure combined with the risk management paradigm produces the internal communication framework, which then drives external communication. The organization's structure and the internal communication framework provide the basis for the process and data flow. The framework for the methods and tools is then provided by the defined process and data flow.
There is an overall process for the implemented risk management practice, and then there are the lower level processes for each function (e.g., the Plan, … Track function). Each of the processes in the practice is made up of activities accomplished by project risk members, using the methods and tools for that function. Each method has steps that are performed by project risk personnel.
The example implementation, which is discussed here, is neither the answer nor the solution for all projects, but it does provide a basis for differentiation. It could form a foundation for a target, goal, or end point for a risk project team attempting to implement a risk management practice. Each project and each organization should determine the specific implementation that will work best for their situation.
In any organization, activities and communication occur within a defined structure or framework. The risk management activities and communication about risks must also be performed within an organized framework.
The Figure Organization Structure shows a typical hierarchical organization for a project.
Figure Organization Structure
The plan outlining how a project performs risk management is documented in a Risk Management Plan, which is part of the overall project management documentation. The risk management plan guides the project personnel through the tailored process, methods, and tools of managing risks on the project.
The risk management plan is the "WHAT" that specifies:
The risk management plan is maintained and controlled by the same configuration management and quality assurance processes that maintain and control other project management plans. [Link to risk_man_plan]
The Implementation plan guides the sponsors, infrastructure personnel, and project manager through the transition process. The risk implementation plan is the how management is going to bring risk management into the project. The Implementation Plan specifies the following:
The two primary high-level management plans are the Implementation Plan and the Risk Management Plan. They're easy to get confused so to summarizing the differences. The Implementation plan guides the sponsors, infrastructure personnel, and project manager through the transition process. The risk management plan guides the project personnel through the tailored process, methods, and tools of managing risks on the project. The Table Risk Management vs. Implementation Plan shows the comparison.
Table Risk Management vs. Implementation Plan
|
Implementation Plan |
Risk Management |
|
Sponsorship |
Overview of risk management practice |
|
Roles and responsibilities for transition |
Project organization and responsibilities |
|
Schedule, budget, resources & milestones for transition effort |
Budget, resources, & milestones for risk management activities and risk mitigation |
|
Evaluation measures and completion criteria |
How to document risks |
|
Transition risks and mitigation plans |
|
|
Establish baseline method |
|
In this project, the risk management processes are implemented through specific activities and responsibilities at each level of the project organization. Risk-related activities and communication paths are defined to enable the free flow of risk information. The Figure Internal Communication depicts the internal communication framework for a hierarchical organization. The responsibilities and activities are further elaborated in succeeding paragraphs.
Figure Internal Communication
Individuals (e.g., software engineers, hardware engineers, testers, technical leads, and the project manager) in this project are responsible for these activities:
As example software engineers have identified fifteen new risks (including the estimations of probability, impact, and timeframe) to add to the thirty that they already have. They have also proposed mitigation strategies and actions for ten of the existing risks and expect that their software engineering team lead will review those plans for approval. Nine- teen risks are still being watched, and the software engineers have collected and prepared status reports for these risks. At this point, one risk has already been accepted and closed.
The technical leads (e.g., software manager or configuration management lead) in this project are responsible for these activities:
As an example the software engineering team has 45 risks. Twelve of the risks are prioritized into software engineering's top 12-risk list and are reported to the project manager. Twenty-two risks are being watched, while eleven are accepted and closed.
Continuous Risk Management is not a job for only the manager or a designated technical lead (e.g., risk manager). Transitioning or implementing Continuous Risk Management in a project is also not the job of a single person. It takes everyone on a project to successfully implement Continuous Risk Management and then manage the risks. No single person knows everything; synergy is what enables the project to function.
Although everyone is involved, it does not mean that every person carries out every task. As with any improvement or transition effort, there are tasks and activities, which are best suited to different parts and individuals in the organization.
People both from inside and outside the project are involved. These are the key people in making the decision to do risk management and getting it started. Sponsors are generally the project manager or someone higher in the organization. Change agents should be external to the project to preserve an unbiased viewpoint about problems and possible technological solutions. The roles and responsibilities are in Table Individual Responsibilities.
Table Individual Responsibilities
|
Role/Description |
Responsibilities and Tasks |
|
Sponsor (e.g., senior mgr., VP, division chief) |
|
|
Project manager (Responsible for ultimate success of project) |
|
|
Champion (Advocates new technology or process within the project) |
|
|
Change agents (Plan and implement changes in organizations and projects |
|
|
Facilitators (Trained in meeting skills, conflict resolution, tools, etc., - act individually or as a team) |
|
|
Technical managers (e.g., team or functional leads, such as software/hardware manager, test mgr., etc.) |
|
|
Project personnel (e.g., software or hardware engineers, testers, etc.) |
|
The project manager is responsible for these activities:
As an example, the hardware manager reports 11 important hardware risks as well as one risk, which should be transferred to the software engineers. In addition, the software manager reports 12 risks, the quality assurance manager reports 4 risks, the configuration manager reports 2 risks, the personnel and training representative reports 5 risks, and the testing lead reports 6 risks. Thus, a total of 41 risks were reported to the project manager, which is more than the project can afford to mitigate at this time. The project manager and the technical leads then reprioritize the risks to identify the top 15 risks to the project. The risks on the top 15 lists will be allocated mitigation resources. Also, the risk that the hard- ware team wanted to transfer to the software engineers is reassigned to and accepted by them.
The Roger L Van Scoy's risk management paradigm [Van Scoy 92] provides a conceptual view of the Identify, Analyze Plan, Track, Control, and Communicate functions. A defined process and data-oriented view provides an alternative view of the functions for this example implementation. Due to budget constraints, only the top N risks to the project will be mitigated, and the number of risks that are on the top N list will vary over time.
Reviewing Risks
The top N risks are either mitigated or watched and are reviewed weekly. Risks that are on the non-top N list are reviewed once a month for progress or significant changes. New risks are added to the top N list when they have a high probability, a high impact, and a near-term timeframe; otherwise, they are added to the non-top N list. New and watched risks may move between the top N and non-top N lists when all of the risks are re-prioritized or when significant changes occur which warrant review. Researched risks are treated as watched risks until the research is completed, and transferred risks are reviewed once a month to determine what progress is being made by the transferee.
The following diagram illustrates the constraints on the management of risks for this project.
The Figure Implementing Continuous Risk Management Process and Data Flow is a combined high-level process and data flow.
For this project, only the top N risks are mitigated. However, there is a hierarchy of top N lists, which is illustrated by following diagram. Major resource commitments for mitigation can only be allocated to the project's top N risks. Each team for risks, which appear on its individual top N lists, can make discretionary or minor resources commitments for mitigation.
Continuous Risk Management activities occur in three basic settings:
Individuals are responsible for identifying new risks, for classifying them, and for estimating the impact, probability, and timeframe for each new risk. Once an individual has been assigned responsibility for a risk, he or she will be required to decide if the risk needs to be researched, accepted, watched, or mitigated. If the risk needs to be mitigated, the individual determines the scope of the mitigation effort (i.e., action items or a task plan) and develops the mitigation plan. Individuals also track the risks that are assigned to them as well as produce status reports for the risks. When necessary, individuals can form small sub teams to deal with their risks (e.g., when a complex risk requires team expertise to develop mitigation plans).
At weekly team meetings, the technical lead establishes a priority of the team's risks (both new and existing) to determine which ones are most important and which ones must be reported to the project manager. Also, the technical lead either assigns responsibility for new risks to team members or transfers the risks to another team or to the project manager. Mitigation plans, which are developed by team members, are reviewed and approved by the technical lead during this meeting. If a mitigation plan is not approved, a selected sub team subsequently revises it. Status reports for risks and mitigation plans are presented at this meeting, and the team decides if the risks can be closed, if the mitigation plans need to be changed, if contingency actions are now required, or if risk tracking should continue. Decisions concerning risks that are currently being reported at monthly project reviews cannot be made at weekly team meetings. Control decisions for those risks must be approved at monthly project reviews.
At monthly project meetings, the technical leads bring the top N risks from their teams to review and prioritize at the project level. The project manager and technical leads decide if the risks can be closed, if the mitigation plans need to be changed, if contingency actions are now required, or if risk tracking should continue. The project manager deter- mines where to allocate significant project resources for mitigation; however, technical leads also have an "allowance" of discretionary mitigation resources. The project manager must approve all mitigation plans that exceed the mitigation allowance for a team. Successful mitigation efforts are recognized at the monthly project meeting, and informal rewards in the form of "honorable mentions" in monthly project status reports are also provided. Priority changes at the project level may affect priorities at the team level.
The project has chosen to expand its problem database to include risk data. As risks and problems are closed and solved, the lessons learned associated with risks and their mitigation plans as well as with problems and their solutions are added to the database. The project manager wants the organization to adopt the process of adding lessons learned for both problems and risks. Having a repository of risk and problem data would support the ability to do cross-project lesson learned analyses as well as general trend analyses (e.g., identify patterns, common mitigation strategies, etc.).
This section describes the methods and tools used to perform the Continuous Risk Management activities as well as the rationale for selecting them for this project.
The Table Methods and Tools for Individuals illustrates the methods and tools that can be used by individuals or sub teams to complete the identification, analysis, planning, and tracking activities that are assigned to them. The tools listed in the table are database reports or data entry forms (or both).
Methods and Tools for Individuals
|
Individuals Risk Management Activities |
Methods and Tools |
|
Identify, classify, and evaluate new risks |
Risk information sheet Taxonomy classification Tri-Level attribute evaluation |
|
Plan assigned risks: determine approach and Action item lists scope, develop mitigation plans, and identify indicators to track risks and plans. |
Action item lists Planning worksheet |
|
Track assigned risks and plans and develop status reports. |
Spreadsheet risk tracking |
The Table Methods and Tools for Weekly Team Meetings describes the methods and tools used during (or to support) weekly team meetings. The methods and tools are used to review risks and their status reports, to prioritize risks, to assign responsibility, and to take controlling actions.
Table Methods and Tools for Weekly Team Meetings
|
Weekly Team Meetings: Risk Management Activities |
Methods and Tools |
|
Meet to discuss progress and problems and to assign new tasks. |
Risk Information Sheets Spreadsheet risk tracking |
|
Prioritize risks within the team. |
Multivoting |
|
Assign responsibility (planning step): keep risks, delegate risks to another team member, or transfer risks out of the team. |
Document decision on risk information sheet. |
|
Control risks: close risks; take planned actions (contingencies), continue tracking and executing the current plans, or replan if the current mitigation efforts are not succeeding. |
Closing a risk Document decision on risk information sheet. |
|
Select risks to report at the monthly project meetings. |
Spreadsheet risk tracking |
The Table Methods and Tools for Monthly Project Meetings describes the methods and tools used during (or to support) monthly project meetings. The methods and tools are used to review risks and their status reports, to prioritize risks, to assign responsibility, and to take controlling actions.
Table Methods and Tools for Monthly Project Meetings
|
Monthly Project Meeting: Risk Management Activities |
Methods and Tools |
|
Meet to:
|
Spreadsheet risk tracking Stoplight chart |
|
Prioritize risks within the project. |
Cost-benefit analysis Multivoting |
|
Assign responsibility (planning step): keep risks, delegate risks to another project member, or transfer risks out of the project. |
Document decision on risk information sheet |
|
Control risks: close risks, take planned actions (contingencies), and continue tracking and executing the current plans, or replan if the current mitigation efforts are not succeeding. |
Document decision on risk information sheet |
|
Select risks to report externally. |
Spreadsheet risk tracking for details Stoplight chart to summarize |
The Table Rationale outlines the rationale used to select the set of methods and tools for the example project. A similar type of rationale for choosing methods and tools should exist for any project that is using Continuous Risk Management.
Table Rationale
|
Method or Tool |
Selection Rationale |
|
Action Item List |
Action item lists are used to document the selected set of mitigation actions. If a risk or set of risks is so complex that a formal task plan is needed for mitigation, it will be added as a task to the project plan and tracked as a project task with a pointer to the risk. |
|
Closing a Risk |
Other managers would like their projects to learn from the experiences of this project. The lessons learned which are captured by this method are a key part of the learning experience. |
|
Cost-Benefit Analysis |
A corporate tool already existed as an aid to developing cost-benefit analyses, and no tailoring was necessary to support the evaluation of mitigation costs and benefits. The project manager requires this type of analysis before major resources for mitigation are committed. |
|
Multivoting |
Multivoting is a standard voting method that was already used and taught as part of the project's quality improvement initiatives |
|
Planning Worksheet |
A planning worksheet is used to help planners consider all aspects of a risk that might influence its mitigation. It is also used as a checklist to document comprehensive strategies and actions and to document planning decisions. |
|
Risk Information Sheet |
The project uses this tool as the primary documentation for an individual risk. The project wanted a one-page description of information for each risk to complement the summarized spreadsheet (e.g., as back-up documentation during meetings if detailed information on a particular risk is needed). |
|
Spreadsheet Risk Tracking |
Risk tracking spreadsheets are used to summarize the current statuses and priorities of all of a team or project's risks. It supports a quick, high-level review Of risks during meetings. |
|
Stoplight Chart |
The project manager was already required to use the simple red-yellow-green metaphor for reporting status for problems, schedules, and budgets. The extension to risk was intuitive. |
|
Taxonomy Classification |
The software development risk taxonomy was chosen as the classification method for software engineering, quality assurance, configuration management, personnel, and testing risks. A tailored set of additional classes was added for hardware risks. |
|
Tri-level Attribute Evaluation |
Binary evaluation did not provide a sufficient level of discrimination, so a tri-level evaluation was chosen. |
The project manager often communicates with people external to the project about status information, problems, schedules, budgets, as well as other relevant topics. Risk information is a part of the project manager's external communication because it keeps people who are external to the project informed and aware of potential problems. External communication is also used to elicit additional information that is needed to understand risks or to acquire additional resources or assistance when mitigating risks. The project manager believes that open communication about the project's risks will help to foster effective risk management and will decrease the likelihood of creating unpleasant surprises for customers, suppliers, and the site manager.
There are three basic external paths for communicating risk information: senior managers, customers, and suppliers. The Figure Communication Paths shows the relationships between the external parties and the project.
Figure Communication Paths
The site manager is the senior manager in the company and gets quarterly status reports from all of the projects at the site. The site manager's goal is to understand the risks facing projects and to determine whether the risks are under control. If extensive resources are needed for mitigation or if serious problems are about to occur despite mitigation efforts, it is the responsibility of the site manager to decide how to proceed. Detailed status information, plans, and progress reports are normally not required, unless they are specifically requested. "The site manager is primarily interested in issues which may significantly affect the quality, cost, or schedule of delivered products.
Site risks, those common to multiple projects, may also be identified at the quarterly meetings and may be assigned to project representatives or other staff members for resolution.
Selected risks are chosen from the project's top N list and discussed with the customer The risks which are reviewed are those that may cause the customer to see a difference in the budget, schedule, or quality of the product. The objective is to inform the customer and to prevent any future surprises. The customer is kept aware of the most important risks and how they are being mitigated. If decisions or agreements are required to change the contract or project plan, then they are negotiated with the customer.
Many risks, even if they become problems, can still be absorbed by the project wit out the customer seeing any impact. These are normally not reported to the customer.
There are several suppliers who are subcontractors for this project. Some of the risks that were identified by project personnel affect the suppliers, who need to be kept aware of progress. A few risks will even have to be mitigated or partially mitigated by the suppliers, so these risks need to be delegated or jointly managed. Selected risks (i.e., those that may impact a supplier's cost, schedule, or product quality) are shared with the appropriate supplier during routine meetings and through status reports. Suppliers provide mitigation plans and status reports on delegated risks when appropriate.
External risk management communication occurs during routine meetings and project events (e.g., system design review) between project personnel and senior managers, customers, or suppliers. Standard reports are another vehicle, which enhance external communication. The Table Meetings shows the types of activities, which might occur during typical meetings to address risks as well as the methods, or tools, which are used to support those activities.
Table Meetings
|
Meetings |
Description |
Methods and Tools |
|
Quarterly site manager's reviews |
Quarterly site manager's reviews are multi-project meetings to apprise the site manager of progress and issues. Risk specific activities include
Output
|
Cost-Benefit Analysis (As needed) Risk Information Sheet Stoplight Charts (which are used for top N risks in each project) are integrated into standard |
|
Weekly teleconferences with customers and suppliers |
Teleconferences with customers and suppliers are used to review current progress, issues, and problems. Risk-specific activities include
Output
|
Risk Information Sheet Spreadsheet Risk Tracking is faxed or emailed prior to conference |
|
Customer's project milestone reviews (e.g., sys- tem requirements review) |
The customer's project milestone reviews are major meetings to review progress with respect to the project schedule. Risk specific activities include
Output
|
Risk Information Sheet Stoplight Charts |
|
Supplier's project milestone reviews (e.g., system requirements review) |
The supplier's project milestone reviews are major meetings to review progress with respect to the 'project schedule. Risk specific activities include
Output
|
Risk Information Sheet Stoplight Charts |
The key to practicing effective continuous risk management is to adhere to the principles when performing the paradigm functions. The project or organization needs to choose and adapt the methods and tools, which meets its own requirements, needs, and standards. Personnel in a project or organization should 'also consider who uses the methods and tools as well as how risk data are collected and stored. All selections and adaptations must be made with the principles in mind. The Table Example Implementation summarizes how the example implementation, which was discussed in this chapter, demonstrates the principles of Continuous Risk Management.
Table Example Implementation
|
Principle |
Implementation |
|
|
Open communication |
During weekly and monthly project meetings, risk information is included as an agenda topic, encouraging open communication about risk within the project. Sponsorship by the project manager and the site manager as well as rewards for successful risk management encourage others to begin dealing with their risks and communicating about their progress. Adding risk information to external communication increases the openness with which issues can be discussed and successfully resolved with the site manager, customers, and suppliers. |
|
|
Forward-looking view |
As risk communication becomes a part of the project's culture and as risk management is openly rewarded and appreciated, project personnel will begin to look further into the future when thinking about and identifying new risks to the project. The integration of risk information with the problem database encourages project personnel to consider the long-range effects of problems and problem resolution. It has also provided a link between risks and problems, which enables trend analyses to be performed on risks data. |
|
|
Shared product vision |
Project personnel can achieve a shared vision of the real goals, priorities, critical issues, and desired end state of the project by integrating risk management with the project meetings. Project personnel can achieve a shared vision of the real goals, priorities, critical issues, and desired end state of the project by including risk information when communicating with customers and suppliers. |
|
|
Global perspective |
The monthly project meetings provide a broader view of all of the project's risks. A more global perspective of the issues, priorities, and desired mitigation goals are obtained by adding customers and suppliers to the risk management process. A global perspective of the organization's risks can be achieved when all of the projects report risks. This happens when the top risks are communicated to the site manager. Risks which are identified by project personnel can be understood more globally from a system perspective by including information from all of the project members, not exclusively from software engineers. |
|
|
Integrated management |
Risk information is added to the project's problem database. The addition of lessons learned for risks and problems result in the integration of risk management with problem solving. During weekly and monthly project meetings, risk information is included as an agenda topic, integrating risk management with routine project work. The discussion of risk information is not scheduled as a separate meeting that could easily be ignored by some project personnel. |
|
|
Teamwork |
The weekly team meetings and the monthly project meetings bring project personnel together to discuss and understand issues, to set more realistic priorities, to improve mitigation plans, and to exchange information and knowledge. The personnel responsible for risks use small sub teams when developing complicated or costly mitigation plans. Small sub teams require team synergy to identify risks and to collect and analyze tracking information. External communication with customers, suppliers and senior management enables broad-based teamwork through the exchange of expertise as well as through the joint development of cooperative mitigation actions and mitigation plans. |
|
|
Continuous process |
Risk management is not a one-time only activity. The ongoing individual activities as well as the weekly and monthly meetings are part of a continuous process. |
|
This module described how risk management is implemented and captured in the Risk Management Plan. Implementation of a new technology, process, or tool in a project or organization takes time, energy and a commitment up front to invest. It is not a one-step process there are many facets to successful technology transition. Adapt risk management to your project. Document your practice and rationale. Change and improve the risk management practice as the risk management team gains experience and improves their methods and tools. Catalogue and capture the lessons learned for future projects.
© January 1, 2006 James C. Helm, PhD., P.E.