Achieving Yokoten in the Process of Risk Management

	Bookmark This Page Email This Page Format for Printing Submit an Article Read More Articles
	Related Tools & Articles Applying Theory of Constraints to Managing Bottlenecks Reduce Operational Risk in Business Process Outsourcing Help Desk Can Provide Help for Process Improvements
	Discussion Forum "What is it that you want/expect to reach with BPM in this case? Process improvement? Compliance? Better risk management? ... And also ask yourself where you are in terms of maturity" Contribute to this Discussion

By Muthuvelan Varadharajulu and Carsten Rommel

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, process management teams and others involved in projects can get ahead of the curve on addressing risks via yokoten – getting from one place to another.

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: Risk Management Process

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.

Figure 2: Generic Risk Database

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 life cycle – 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 life cycle 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.