Project Management - Quality Management


Project and Process Management
Topic: Quality Management

Recently, I submitted an assignment on Quality Management. Since some of the materials may be useful for someone who wants to study about the topic, this post will contain what I submitted. It includes some posters with short write up on Quality Management and a little more details on one of its practice, Root Cause Analysis.



When looking at quality management, it is a broad field with many processes and practices. Most of the time, it includes quality planning, quality assurance, and quality control. In every project, quality matters. You can map all these processes to happen concurrently within the SDLC process. When used extensively, QM methodology frameworks like Six Sigma, Lean, and Total Quality Management (TQM) helps to provide more structure to the process.

In this section, I will share my findings on one generic Quality Management Practice that can be applicable at many places - Root Cause Analysis (RCA).


Summary and Background
Overview
Root Cause Analysis (RCA) is a practice used during problem solving to identify the root cause of faults or problem[1]. A factor is considered a root cause if its removal prevents the undesirable event from recurring. The thinking is that problems are best solved by attempting to correct or eliminate root causes, as opposed to merely addressing the immediate obvious symptoms.
This is useful during Quality Management because when problems are identified, one of the prime challenge lies in identifying answers to “What is the main problem?”, “Why did it happen?”, “When did it occur?”, and “How to best avoid the problem in future?”. RCA is a mechanism of analyzing problems with methods that can answer these questions[2].


Diagram from “Simplified Tools and Techniques”[3]


General Principles
The primary aim of RCA is to identify factors that cause the result, to prevent recurrence of similar harmful outcomes, and to identify lessons that may promote the achievement of better consequences. With that in mind, RCA follows a few general principles.
Firstly, all problems arise from their root causes. The identification of the root causes will depend on the way the problem is defined. Effective problem statements that are well supported with data is helpful in the analysis.
Next, a high quality solution is one that is engineered to resolve the root cause of a problem. The purpose of identifying solutions to the problem is to prevent recurrence at the lowest cost in the simplest way. There is a need to monitor an implemented solution to ensure that it fundamentally resolves the identified problem. This is especially so because there may be more than one root cause for an event or problem.
Overall, the focus of RCA should be on a systematic process usually as part of an investigation to produce the right results. This process should be well defined and undergoes continuous process improvement to produce high quality solutions consistently, economically, and in short amounts of time.

History of RCA
The history of RCA can trace back all the way to our ancient ancestors who solved the problem of freezing during winter by taming fire. However, the more specific, consciously implemented systematic approach to problem-solving was only recently developed and spurred by industrial and engineering investigations[4].
In the field of engineering, RCA is commonly credited to the “King of Japanese Inventors”, the founder of Toyota Industries Co, Ltd., Sakichi Toyoda[5]. The most famous application of RCA uses a method called “The Five Whys” that asks “Why” five times or until the root cause(s) of a problem is found.
Further events saw RCA and quality control evolve into codified practices like Six Sigma, developed by Motorola beginning in 1986. This allowed Motorola reduce defect rates to 0.0015%[6], giving them a tremendous competitive edge.


Strengths of RCA
The strengths of RCA includes enabling an early identification of risks, reinforcing quality control, enabling continuous improvement, and enhancing project management[2]. RCA is useful because finding the root cause of problems helps to formulate solutions that can directly eradicate problems.

Weaknesses and Risks of RCA
One key weakness of RCA is that it generally assumes linearity and may not be able to handle more complex problems that emerge from a confluence of conditions and occurrences that in particular combinations trigger failure. As such, teams risks oversimplifying the root-cause of problems if the problem gets more complicated.
Another risk of RCA arises when not all information is accessible to the team that is doing the analysis. For example, in larger organizational contexts, some root causes may stem from the executive team that is not known to the staff as they are sensitive information that is not disclosed. This causes the root-cause to be unknown and any solutions could be only addressing the symptoms.
As such, for RCA to work well, there is a need for all stakeholders to be involved, and to work closely with Continuous Improvement practices to validate that the root cause is indeed found and addressed to solve the identified problem.

Contextual Analysis of RCA
For all Software Development Lifecycle methodologies regardless if it is Agile, Iterative, or Waterfall, Quality Management is an essential process that is integrated in it. This is because every software product needs to meet certain quality standards before it gets accepted by consumers who will be using the product.
As mentioned in the Quality Management process definition, three key activities include quality planning, quality assurance, and quality control. In order to ensure these activities are done effectively, the management team needs to know the process of testing for quality issues, the way to identify problems, and to quantify steps on how to resolve it. RCA comes into play at this point of time to facilitate in producing solutions that can resolve the identified problems. It also prevents the same problems from occurring again.
The section below elaborates on example ways to identify possible causal factors when practicing RCA.

Example in Context - 5 Whys Technique
The 5 Whys technique is useful to make decisions based on in-depth understanding of processes and conditions on the ground, as when compared to reflecting the thinking of someone at the boardroom. This method is most effective from people who have hands-on experience on the process that is being examined[7].
The way to implement this technique is to find a subject matter expert of the process whenever a problem occurs, then uncover its nature and root cause by asking “why” no fewer than five times. This method is best for simple or moderately difficult problems as it leads to a single track of enquiry when there could in essence be multiple causes of the problem.
The simplicity of this tool gives it great flexibility and is often associated with lean manufacturing. It is also used in the analysis phase of the Six Sigma quality improvement methodology.

Example in Context - Cause and Effect Analysis (Fishbone Technique)
Cause and effect analysis (or fishbone technique because the completed diagram looks like the skeleton of a fish) is a method to brainstorm and draw out a cause and effect diagram to discover and identify what contributes to a problem. It also allows one to clearly see where and why a process is not working[8].
The diagram below is an example template of the fishbone diagram. It starts off by first identifying the problem, then identify the major factors involved in causing the problem. Factors could come from McKinsey 7S Framework (Strategy, Structure, Systems, Shared Values, Skills, Style, and Staff), 4Ps of Marketing (Product, Place, Price, and Promotion), or any brainstormed results (e.g. Equipment, Process, People etc). Next, identify primary and secondary reasons the factors causes the problem. Finally, analyse the diagram to investigate on the causes problem till a more complete picture is formed.


Figure from Wikimedia[9]

This method of analysis is useful for more complex problems that have multiple causes.

Example in Context - System Improvement Process (SIP)
Another way to work on complex, big problems, is to apply the System Improvement Process[10]. This divide and conquer method works by decomposing one big problem into subproblems. These subproblems may in turn need further division till a point that the RCA can be performed on each subproblem.
There are four main steps in the SIP. First, define the problem and sub problems. Next, spend about 80% of the time to analyse and find the root causes. Formulate solutions, implement them, and work closely with the Continuous Improvement practice as the foundation to contribute to the overall quality of the software. The diagram below is a template to apply SIP.


Figure from thwink.org

This method of analysis, similar to the affinity diagram, is useful when there are several inter-related sub causes that can be grouped together to see the major causes which contributes to the subproblems that makes up the main problem.

Tailoring a RCA Practice
RCA is generally a proactive approach used to prevent a problem from occurring. When RCA is applied as a reactive tool tailored to fix failures, it becomes a Root Cause Failure Analysis (RCFA)[11]. This is one important approach to RCA as it emphasizes that most problems in complex systems can rarely be attributed to a single specific cause. Rather, they are often the result of a series of interlinked “causal factors” [4].

Metrics and Measurement for RCA
The measurement of the effectiveness of RCA can be done with matrices that observe the eradication of identified problem based on the solutions from identified the root cause[12], the time it takes to resolve, and monitors that no new problems are created.
One metric that can facilitate in this measurement is the, Goal-Question-Metric (GQM). When defining the GQM, the goal would be to solve the identified problem. The question is a list of questions to identify the symptoms of the identified problem, and to verify that they can be resolved by the solutions formulated during RCA. The questions should refine, articulate, and determine if the goal of solving the problem can be achieved. Finally, the metrics or measurements that are collected are then used to answer the questions in a quantifiable manner[13]. For example, if RCA is used in the form of RCFA, one quantifiable metric is that the number of bugs are eradicated after exercising the practice.



Conclusion
RCA is useful to find the root cause of a problem to ensure that it is addressed to eventually resolve problem. There are some limitations to this method once the problem is more complex, thus for such scenarios, it is recommended to combine RCA with other practises like the Failure Mode and Effects Analysis (FMEA), or Kaizen (Continuous Improvement) to create a more wholesome problem solving process. 


Bonus

I have gathered some QM quotes that I find interesting, and placed them in square blocks. If you like them, feel free to print it out and make it a coaster for your cup. :)

 

 

 
References
[1] Wilson, Paul F., Larry D. Dell, and Gaylord F. Anderson. Root cause analysis: a tool for total quality management. Milwaukee, WI: ASQC Quality Press, 1993.
[2] "Root Cause Analysis – Perfect Approach to Software Testing." Software Testing Solution Blog. October 09, 2015. Accessed January 21, 2017. http://softwaretestingsolution.com/blog/root-cause-analysis-perfect-approach-software-testing/.
[3] Andersen, Bjorn. Root cause analysis: simplified tools and techniques. Milwaukee, Wisc.: ASQ Quality Press, 2006.
[4] "What is Root Cause Analysis?" SmartBear. Accessed January 29, 2017. https://smartbear.com/learn/performance-monitoring/what-is-root-cause-analysis/.
[5] A., Fatima. "A Brief History of Root Cause Analysis." Brighthub Project Management. February 28, 2015. Accessed January 21, 2017. http://www.brighthubpm.com/risk-management/123244-how-has-the-root-cause-analysis-evolved-since-ince ption/.

[6] Erwin, Jane. "Achieving Total Customer Satisfaction Through Six Sigma." Quality Digest Article. July 1998. Accessed January 29, 2017. http://www.qualitydigest.com/july98/html/sixsigma.html.
[7] "5 Whys: Getting to the Root of a Problem Quickly." Problem-Solving Skills From MindTools.com. Accessed January 29, 2017. https://www.mindtools.com/pages/article/newTMC_5W.htm.
[8] "The Cause and Effect (a.k.a. Fishbone) Diagram." ISixSigma. Accessed January 29, 2017. https://www.isixsigma.com/tools-templates/cause-effect/cause-and-effect-aka-fishbone-diagram
[9] Wikipedia. Accessed January 29, 2017. https://en.wikipedia.org/wiki/File:Ishikawa_Fishbone_Diagram.svg.
[10] "Index of /sustain/publications/brochures/04_RCA_At_Thwink." Index of 
/sustain/publications/brochures/04_RCA_At_Thwink. Accessed January 29, 2017. http://www.thwink.org/sustain/publications/brochures/04_RCA_At_Thwink/.
[11] "Root Cause Analysis: Tracing a Problem to Its Origins." Problem Solving From MindTools.com. Accessed January 29, 2017. https://www.mindtools.com/pages/article/newTMC_80.htm.
[12] Nielsen, Dave. "Root Cause Analysis." Project Smart. December 16, 2009. Accessed January 21, 2017. https://www.projectsmart.co.uk/root-cause-analysis.php.

[13] "How Do You Know Your Metrics Are Any Good -." LeadingAgile. April 23, 2015. Accessed January 29, 2017. https://www.leadingagile.com/2013/07/how-do-you-know-your-metrics-are-any-good/ .


No comments

Powered by Blogger.