We have recently had a discussion on what it takes to quality assure software. The discussion focused on FMEA and the role it plays in quality assurance.  The discussion began to sound as if the FMEA was the panacea for poor quality. There is no silver bullet.

To be sure the FMEA (which is essentially a design review) helps, but is not the only thing we can or should do to secure the quality of the software product.  Like many things, you get out what you put into it.  A poorly executed FMEA (the amount of time, rigor, and skill that we put into it) will produce poor results and likely be a time consuming activity with little return.

While FMEA’s are typically more focused upon the hardware (DFMEA) or process (PFMEA) the tool can also be used on Systems level and even Software application.  We have even turned the FMEA methodology into a Project Management Risk Evaluation tool (see our download section https://valuetransform.com/downloads) extending beyond the system, product hardware or the manufacturing processes we use to achieve our objectives.

The FMEA is not the only tool.  In football, we do not abruptly start coaching the high-tech plays like the double reverse.  We start with the fundamentals like running, catching, and tackling. In product development we have fundamentals also, and we have been and will continue to write about that in the blog, however, we provide a list below of some of those fundamentals

The things we should be doing to improve the quality are:

1. Requirements Management (which includes – identifying, writing, and critical reviews)
2. Configuration Management
3. Define iterative systems / component package content (iterations and part of configuration management)
4. Sufficient time and rigorous testing (whether model based requirement otherwise)
5. Feedback from the testing and evaluations back into the system (both the project system and the product system)
6. Project planning that recognizes the dependencies and delivery qualities (what attributes of the delivery means the delivery is ”good” quality)
7. Monitoring the detailed project plan for imminent negative impacts
8. When we cut corners – know the impact of the shortcut on our project and product quality

I think we would be well served from the FMEA when we perform it closer to correct. Even for software or systems level critique the method can improve our design and help us understand the risks.

The point is, there is no one silver bullet.  A weak FMEA is part of the problem; a good FMEA is helpful but only address part of the areas of risk. The poor requirements handling and configuration management for example, have nothing to do with the FMEA, and really cause great harm in our work if these are lacking.  We waste time, deliver poor quality and add risks when these things are “broken”.  We would be better served by focusing on the fundamentals (of which an FMEA would be part) than developing new ways.