Risk management is a systematic and disciplined process to handle risks in every aspect of a project, including project management and technical aspects. Yet despite the need to handle risk management with care, Six Sigma teams and others involved in projects can get ahead of the curve on addressing risks via yokoten.

In general, risk management comprises the following major steps:

• Assess the risks (i.e., access continuously what could go wrong).
• Prioritize the risks (i.e., determine which risks are important to deal with based on risk priority number).
• Manage abatement actions (i.e., plan and implement actions necessary to reduce the impact or the possibility of occurrence of risks).

There are different techniques that can be applied in risk management. These techniques vary predominantly in the way the risks are evaluated. For example, the risks may be evaluated or ranked based on their severity (the negative impact of the risk to the project) and probability (the probability of occurrence of the risk). This is generally followed in handling project management risks. Whereas in techniques such as failure mode and effects analysis (FMEA), which are widely used in handling technical risks, the risks are evaluated based on their severity, probability and detectability (the likelihood of preventing or detecting the occurrence of risk). In any case, risk management process plays a major role and is very critical for effectively managing a project.

Figure 1 illustrates a generic model of the risk management process. This process needs to be repeated periodically throughout the life cycle of projects. The periodicity may vary according to the criticality and/or size of the project. Accordingly, project teams identify the risks, evaluate and prioritize the risks based on the risk priority number. The project teams then plan and implement the abatement actions according to the priority to avoid or reduce the negative effect of the risks on the projects.

Yokoten: From One Place to Another

Generally, each project team performs the risk management activities and retains what it learns within the project. Thus many of the things learned from various projects need to be reinvented in new projects. This consumes lot of effort, time and money that could be avoided if there is a process and mechanism by which whatever is learned from one project is shared among other projects. This is where the Japanese term yokoten, which means taking from one place to another, gets prime attention. Yokoten emphasizes learning at an organizational level through sharing of the best practices from one project to other similar projects. In risk management practices, the identified risks and the corresponding abatement actions provide an immense learning opportunity among projects. Hence, achieving yokoten for risk management is essential for knowledge sharing among projects.

One method of passing on what is learned is to make each new project to go through the risk management documents (risk sheets or FMEA) of other completed projects.

This is a cumbersome process and has the following constraints:

• Effort constraint:This requires lot of effort as new project need to review the risk management documents of all completed projects.
• Time constraint:Sharing of information among concurrent projects is very difficult.
• Location constraint: If projects are handled in different locations, sharing of information is much more difficult.

Hence, there is a need for an automated, database solution for risk management process for seamless information sharing among projects, irrespective of location, time and so on.

Regarding the knowledge sharing aspect in risk management, there are two important scenarios with respect to time that need to be considered:

• Vertical:Learnings passed on from the completed projects to new projects.
• Horizontal: Learnings shared among concurrent projects.

Sharing Information from Completed Projects

In this case, owners of the completed projects need to identify the risks and abatement actions that could be applied to other similar projects and provide such inputs to build a generic risk database, as shown in Figure 2. Care should be exercised while providing such inputs, as only those information that is generic or applicable to future projects need to be provided. Otherwise the generic risk database will quickly become very large and cumbersome.

A panel of technical experts should review the submitted generic risks and approve the items as appropriate. The panel of technical experts for risk management may be a virtual team comprised of a group of technical experts from various teams based on the fields (e.g., software, electronics, etc.). These approved generic risks will then be appended to the generic risk database. While starting a new project, the leader of the project would need to go through the generic risk database and identify those risks and abatement actions that are applicable to the new project for carrying out the risk management activities.

Considering the generic risk database: A number of factors should be taken into account:

• Compatibility: The generic risk database needs to be compatible with the risk management documents (risk sheets or FMEA) used by various projects. Consider the fields, columns or header information.
• Risk description: A good guideline to describe a risk needs to be in place. Good risk descriptions will facilitate locating the appropriate risk easily.
• Category/subcategory: For locating the appropriate risk, it is best to define and assign the categories for risks. The following are some examples of categories:
  • Product classifications
  • Process classifications
  • Project’s lifecycle – requirement, design, manufacturing, testing, etc.
  • Project management risks – cost, schedule, quality, etc
• Maintenance: Maintenance of the contents of the generic risk database needs to be in defined at organizational level. (For example, the panel of technical experts may review the generic risk database periodically and make recommendations such as adding or deleting risks, updating the risk rating and so on).
• Maximum risk rating: In general, as any project progresses, based on the identification and completion of the abatement actions, the corresponding risk rating may gradually reduce. However, while providing the risk information upon completion of the project as an input to the generic risk database, the maximum rating of the risk during its lifecycle needs to be considered.
• Notification: Notification needs to be made to the project teams on changes to the generic risk database, if any. (For example, during the reviews by the technical experts, if the definition or rating of a particular risk is updated in the generic risk database, the same should be notified to the appropriate projects.)

Sharing Information Among Concurrent Projects

There are two different scenarios for sharing information among the concurrent projects.

1. Sharing information among independent but similar projects – copying:The risk information can be copied from one project to other projects and can be maintained in the respective projects, as shown in Figure 3. This will be useful when two different projects are similar in nature but are to be handled independently.

As an example: Assume two independent but similar projects Project A and Project B and a risk Ra1 of Project A is copied to Project B. In this case, the risk information will be stored under a new risk in Project B, say Rb5, and the ownership of Ra1 is with Project A and the ownership of Rb5 is with Project B. Hence the risks are independent of each other.

2. Sharing information among dependent projects – linking:The risks of the dependent projects could be linked from one project to other projects as shown in Figure 4. This will be useful in projects that are related by parent-child or child-child relationship. In this case a risk of a particular project is still maintained in that project but instances are created wherever required for monitoring.

As an example: Assume two projects that are related – a parent project (Project A) and a child project (Project B). Assume that a risk, Rb1 of project B is linked to Project A. In this case, the ownership of Rb1 is with Project B but it is referred/monitored in Project A as well. The reason is that the success of Project A depends on Project B but the ownership of reducing the effect of the risk Rb1 is with Project B.

From Completed and Concurrent Projects

While developing a database solution for risk management, it is reasonable to consider that a risk from any project, dependent or independent, could be copied or linked to any other project, as shown in Figure 5. This approach will broaden the model of the database solution for risk management and facilitate a greater sharing of what is learned among various projects.

Hence, the database solution for risk management will have the following two sections:

• Generic risk database
• Project risk database

The project risk database further contains the following two sections:

• A section for capturing project specific risks.
• A section to link the risks that are related to a particular project but are maintained in other projects.

Conclusion: Understand Risks Earlier and Better

In general, each project team maintains a “to-do” list derived from a work breakdown structure. This list is reviewed periodically and is important for signing-off milestones. Usually this list also is maintained in databases. It is highly desirable to link the abatement actions resulting from the risk management activities with the to-do list of the project. Care should be taken to maintain traceability from both sides – abatement actions and to-do list).

Achieving yokoten for risk management makes the organization understand the risks, earlier and better. This facilitates the project teams to plan the actions proactively to avoid risks at an early stage of projects rather than to act reactively. That will save lots of time, effort and money. In addition to facilitating yokoten through the organizational learning, the database solution for risk management also enhances transparency among projects and brings about uniformity with respect to handling risks.