Many times, a company is required to do a root cause analysis once a defect or bug is found in the software system it has developed and released to customers. Such an approach is not only costly, but almost without exception results in customer dissatisfaction. What is needed is a proactive approach to understand the various possible causes of defects and how to avert them.

A well-documented failure mode and effects analysis (FMEA) with robust action plans and implementation will help an organization avoid rework in software projects, irrespective of the project type (full life cycle development, enhancement or maintenance/production support). In each case, there is an existing process, with a number of process steps/activities. FMEA can unravel the potentially weak steps and show where things may go wrong and where to focus. The FMEA tool – either within a full-fledged Six Sigma DMAIC (Define, Measure, Analyze, Improve, Control) cycle or without – adds immense value to software projects.

How to Use FMEA in Software Projects

The FMEA process begins by identifying the ways in which a product, service or process could fail. A project team examines every element of a process, starting from the inputs and working through to the output delivered to the customer. At each step, the team asks, “What could go wrong here?” The team then figures the probability of each possible failure (known as “occurrence”), the damage it will inflict should it actually fail (termed as “severity”), and the likelihood of finding such failures before final delivery (called “detection”). These three parameters are ranked on a 1-to-10 scale and the product of these three is called the risk priority number, or RPN. The RPN indicates which of the process steps or design components are high-risk items and need to be attended to first for medication and/or control measures. Once this is done, the team has to brainstorm action plans to either reduce occurrence or improve detection. Severity normally remains the same.

During the brainstorming, team members need to be clear that the action items should not sound like a wish list or a statement of intent, but should be aimed at adding, deleting or modifying an existing process. If a project team recommends such vague actions as, “Peer reviews should be more effective” or “Problem tickets should be assigned to a team member within 30 minutes of receipt by the team leader,” little or no improvement can be expected. Instead, the action points need to be more precise, such as, “If the team leader does not assign a ticket coming to the queue in 30 minutes, a pop-up message will be generated to remind them.” The action items vary from introduction of checklist, to mandating reviews before a code release, to planning backup resources, to timely assignment/transfer of problem tickets, etc. Whatever the recommendations, after their implementation, the process flow chart is changed. And once done, the FMEA is executed again in the new process to calculate the reduction in the level of risk exposure.

Thus the objective is to first identify the potential risks and then take corrective/preventive action to eliminate or at least reduce those risks.

When to Use FMEA

To get the best results, FMEA should be done at the beginning of a software project and every three to six months thereafter. However, it is never too late to do an FMEA. The exercise can be done at anytime during the course of the software project. Besides, if a Six Sigma project is executed to improve performance of an ongoing and long-duration software project (especially one that involves maintenance/production support in addition to development/enhancement), executing a FMEA can add considerable value. Here, FMEA should be part of a “look-ahead meeting,” which software project teams normally do to proactively reduce defects/bugs.

FMEA is a group activity, normally with six to ten on the team. It may be done in more than one sitting, if necessary. The process owner, or project manager, is normally the leader of the FMEA exercise. However, to get best results, multi-disciplinary representatives from all affected activities should be involved. Team members should include subject matter experts and advisors as appropriate. Each process owner also is responsible for keeping the FMEA updated.

The heart of the FMEA is the action points arising out of it and the subsequent process improvement that happens when these actions are implemented. A project team at a large manufacturing company was very enthusiastic using the FMEA through the point of completing the calculation of RPNs for each process step. But once that was done, only a few people participated in the brainstorming session for recommending action points for high-RPN process steps. Needless to say, that organization did not benefit much from using the exercise.

Specific Benefits of FMEA

FMEA looks simple, but it is an extremely powerful tool when applied in letter and spirit. It helps the team assess stakeholder issues and concerns, identifying and creating a strategy for those that should be moved to a higher level of support.

Specifically, FEMA:

• Captures the collective knowledge of a team.
• Improves the quality, reliability and safety of the process/product.
• Is a structured process for identifying areas of concern.
• Documents and tracks risk reduction activities.
• Helps the team create proactive action plans and thus improve process robustness.

Is FMEA Really Needed for Software Projects?

Some software project managers argue that they do not really need a separate FMEA tool. Risk analysis and mitigation should be a part of the manager’s normal project management job, they say. The point is: If an organization is looking for better results in risk mitigation and improved processes, it needs to use a better tool or technique, such as FMEA. Unless a FMEA is done, improvement activities are likely to remain unclear and unfocused, and may not even get implemented in the pressure of meeting schedules and deadlines. In addition, since FMEA action items are generated by the project team through collective brainstorming, rather than an individual, the buy-in of the actions is much higher, and thus the project manager faces minimum resistance in implementing them. In short, the benefits a software project team will gain from this powerful technique are well worth the time invested in applying it.