As demands on product development teams increase and product complexity grows, it becomes increasingly difficult to maintain quality while keeping costs down—which is especially true if the same defects recur across several development cycles. Finding the root causes of these defects and taking corrective actions to fix them permanently is one of the most effective ways to reduce development costs.

Many product development teams use root cause analysis (RCA) and root cause corrective action (RCCA) to identify the origin of defects in their development processes and prevent them from recurring. RCA and RCCA can be complicated and time-consuming processes when done manually. However, an automated product development solutions can help reduce the time spent on RCA, RCCA, code reviews, and other quality improvement efforts. This white paper provides an overview of RCA and its benefits for product development.

What is Root Cause Analysis?

At the most basic level, root cause analysis is a process used to identify the underlying cause of a defect or failure. As it relates to product development, RCA is a systematic process for categorizing and analyzing defects that have occurred pre-release, post-release, or both. When done properly, RCA reveals the points in the development process that are causing significant and recurring defects.

RCCA is where corrective actions are put in place to address problems identified during RCA. These corrective actions are placed as far upstream in the process as possible, because catching failures upstream saves rework, time, and money by preventing the problem from happening. A critical part of implementing the corrective action is to assess the effectivity of the correction. This assessment provides information about whether the action corrected the underlying problem partially, completely, or not at all.

For example, if a software development team is repeatedly discovering defects after their application is released to the customer, they might learn from a root cause analysis that the defects stem from vaguely worded requirements. They could then take the corrective action of adding a step to their process to review requirements for vague language. It is important to note that the purpose of RCA isn’t to assign blame, but rather to identify the source of problems so that they may be corrected. If RCA is perceived as an attempt to assign blame, it will be met with resistance and won’t be as effective in identifying the root cause of issues.

Many organizations use manual methods to perform root cause analyses, but automated solutions can help make the RCA process faster while exposing gaps and errors that might otherwise have been missed.

What is the value of RCA?

The primary benefit of root cause analysis is that it identifies fundamental problems in the development process, allowing teams to enact corrective measures that fix those problems and prevent them from recurring in the future. As a result, there is less rework and fewer defects in the released product.

• Reduce cost

  A study by the National Institute of Standards and Technology (NIST) showed that the cost of fixing defects increases exponentially the later in the development process they are found. If a defect is caught in the implementation stage, it will cost five times more than it would cost to fix it in the design stage. If the defect isn’t caught until after release, it will cost 30 times more. Skyrocketing development costs aren’t the only financial impact that defects can have. If a defect makes it into the release, customers may lose faith in the product and perhaps even the company, resulting in lost revenue. And if a defect results in harm or violates industry regulations, the company could face substantial fines, lawsuit damages, and other deleterious financial effects.

  To go back to our earlier example, if the root cause of a defect is poorly written requirements, adding a step that reviews requirements for vague language will save development time and provide testable requirements. Instead of a requirement that states, “the application must load in a timely manner,” which is not measurable, the requirement would be clarified in the new review step to state, “the application must load in five seconds or less.” The added specificity helps the developer create the right product, and tells the tester exactly how it should perform. The product gets to market faster, and is a better quality product as a result of the additional review step.

• Identify failure

  Points RCA is especially helpful for teams that believe they have a good development and QA process, but still have recurring defects in every release. Clearly, something is broken, but what is it, why is it happening, and where does it occur in the development cycle? RCA helps answer these questions and identify the real (root) cause and not just the obvious (direct) cause. For example, management might assume defects are getting into releases because the testing team isn’t doing its job well. Perhaps the defects are in a module for which one specific tester was responsible, so the tester is identified as the direct cause of the problem. Without RCA, it would seem that replacing the tester would solve the issue. But if the root cause is the way the requirement or test case was written, then replacing the tester won’t help.

• Improve safety and reliability

  Because root cause analysis helps significantly reduce the number of defects in future releases, it can be particularly beneficial to companies in quality-critical industries, where product safety and reliability are especially important. Establishing and maintaining a good RCA process can strengthen the defect prevention processes and help avoid costly product recalls, regulatory actions, and user harm.

• Accelerate time to market

  When the root cause of a defect is identified and corrective action is taken, subsequent releases of the product spend less time in testing, and the product goes to market sooner with fewer uncaught defects. In this way, companies can reduce their time to market and extend their competitive advantage. The higher the product’s quality is early in the development cycle, the fewer defects will exist to be found and fixed later.

This article has been adapted from a white paper by Seapine Software.