Search


  Advanced Search
 
Popular Authors
  1. Six Sigma Training Assistant
No popular authors found.
 
 »  Home  »  Six Sigma Implementation  »  Six Sigma Software  »  Making The Case For FMEA In Managing Software Projects
Making The Case For FMEA In Managing Software Projects
By Six Sigma Training Assistant | Published  10/5/2008 | Six Sigma Implementation , Six Sigma Software | Unrated
Making The Case For FMEA In Managing Software Projects
For this, what is required is a proactive approach - which means that tests are undertaken such that most of the risks involved in the software project are considered thoroughly and corrective steps taken before the launch of the software.

Failure Mode and Effects Analysis (FMEA) can provide a robust plan which will help organizations to find possible areas where there may be mistakes and errors, and focus on improving them.

This will lead to reduction in rework and provide value to the customer project.

Using FMEA in Software Projects

The utility of FMEA for software projects starts off with finding areas that have the risk of failure. They undertake to study each part of the process to understand what could go wrong at any given point.

The possibility of occurrence of failure, the damage it may cause and the detection of such problem areas is studied. These are ranked on a scale of 1 to 10, and those items or areas which need immediate attention are identified.

When this is done, the team can brainstorm to decide on efforts for reduction of the occurrence.

When Can FMEA Be Used

FMEA can be done at any time in a software project. However, it is preferable to undertake FMEA at the beginning of the software project. By understanding the risks involved in various areas of the project, ways can be found to eliminate them.

When projects go over a longer period of time and involve complex maintenance and development features, it is beneficial to have FMEA, as it will help in reviewing the work done up until that stage - so that if any problem areas are identified, they can be sorted out on a timely basis.

If the risk is taken further to the next steps, it may lead to many more defects at the end of the project. FMEA has to be a team effort. Though it would be mainly the process owner and the managers who will be involved, it is better to involve everyone in this activity for better results.

Each process owner should also update the FMEA.

Benefits of FMEA

FMEA is very powerful in assisting teams to identify risk areas in a software project, so that the teams can work toward elimination of those. The teams can create proactive plans so that the problems, if they actually arise, may be sorted out quickly.

Additionally, being a team effort, the knowledge of everyone in the various areas of concern and probable failure of project is needed, and steps can be taken for addressing those concerns. Having multiple views on the problems can be useful to find the maximum areas where the project may go wrong.

Tracking the risks and documenting them can prove to be helpful in further projects.

Some managers argue that FMEA may not be needed to be used separately. However, unless a FMEA is done, teams will find it difficult to focus their efforts on risk areas and planning, such that their project schedules do not go haywire.

FMEA helps reduce risk, and thus the rework and waste which is necessary for the ultimate goal of timely project completion and customer satisfaction.