Successful project management requires identifying and planning for events that can impede the undertaking. Each event poses different potential consequences. Some risks can impact cost, others can affect schedule, and still others can alter the facility's operating parameters. While you can easily identify some risk events such as delays in equipment fabrication, others aren't obvious without the benefit of hindsight.
So, use of a formal risk-management tool and process is essential during project planning to avoid project failure due to anticipated or unanticipated events. Failure Mode Effect Analysis (FMEA), a flexible yet powerful tool, is a good option where risks are diverse.
Originally developed for the military aerospace program in the 1940s, FMEA has spread to other industries and areas as a risk management tool. It often serves as an integral part of formal quality systems such as QS-9000. While specialized software programs are available for conducting and documenting results of a FMEA, you needn't use them. Indeed, a simple spreadsheet program can suffice for conducting a FMEA.
A FMEA-based risk management process consists of two phases: completion of a FMEA matrix and then integration of the FMEA matrix results into the project execution and control plan.
The first phase has three steps; each involves completing various columns in the FEMA matrix (Table 1).
The first step is failure mode identification. In the project management context, failure modes are equivalent to project risk events. During this step, you list all possible failure modes in the FMEA table and assign each a severity rating that reflects its impact on project success.
In the second step, you estimate probability of occurrence of each risk. This involves identifying its causes and their probability.
The final step is to determine how to detect occurrence of risks. It's critical to ensure that early detection is possible.
Once you've completed the analysis, you can begin the second phase of the FMEA process. Here, you calculate a risk priority number (RPN) for each risk and document mitigation actions. RPNs enable sorting risks in terms of impact and thus allow the project risk management team to focus on highest impact risks first.
Confusing cause with risk. The most common trap teams fall into while developing the FMEA matrix is confusing causes with risks. Always keep risks separate from causes. The FMEA should document risks, not causes. For example, lack of engineering resources is a cause that can create several risks. It can result in delayed schedules or rework due to poor quality or incomplete data. Treating lack of engineering resources as a risk instead of a cause can lead to missed action plans and invalid risk assessment and visibility.
Not distinguishing multiple causes for one risk. When developing the risk and cause list, make sure to separately identify and document all causes for the same risk. Assuming that a particular risk has only one cause can decrease the FMEA effectiveness; some risks have multiple causes that must be managed differently.
Not periodically reviewing the FMEA matrix. FMEA-based risk management shouldn't be a one-time effort. Periodically review the matrix. Don't just verify applicability of risks but also reassess impact, probability and ability-to-detect scores. In most cases, a risk's RPN will change as the project progresses. Conducted properly, periodic review can ensure that the project team is focused on managing the right risks at the given time.
Using too small a team to develop the FMEA. While it's more time effective to have a small core team initiate the FMEA, have a broader group look over the initial matrix. In fact, having completely independent outsiders review the FMEA can ensure that no significant risks have been missed.
Not distinguishing between project-specific risks and general project-management risks. Risks identified using the FMEA process should relate specifically to the project and reflect its unique scope and success criteria. All projects face some common risks; identifying only them could lead to a shallow risk list. Don't use another project's completed FMEA matrix as a starting point. Start with a blank matrix. Once you finish your matrix, then it's worthwhile to look over other matrices from other projects to stimulate identification of further risks.
Failing to incorporate FMEA results in the project execution plan. The FMEA matrix is a tool to facilitate project risk management. Conducting the analysis and completing the matrix doesn't constitute risk management. You must incorporate the action plans and detection methods identified in the matrix into the project execution plan. You must modify the necessary communication procedures, work processes and other execution elements to reflect the project-specific FMEA.
Adnan Siddiqui, P.E., is principal of ConcepSys Solutions LLC, Houston. E-mail him at [email protected].