The 4 W's are an important guide to a full exploration of the possible root causes to a problem.

Transcription

1 Tools for Analysis Fishbone Diagram (CE Diagram) Introduction: The use of this particular tool, so named because it looks like a fishbone, is an effective way to organize and display the various theories about what the root causes of a problem may be. It is a particularly effective tool for bringing together divergent ideas in a group. Once a fishbone or, as it would be more formally called, a cause-effect (CE) diagram has been completed, other tools such as Pareto Analysis may be used to analyze data to establish causality by empirical methods. The CE diagram is primarily used during the diagnostic part of the analysis. There are three basic features to a CE diagram. These are: The visual representation of the factors that might contribute to an observed effect that is being examined The inter-relationships among the possible causal features The inter-relationships are generally qualitative and hypothetical. The most important consideration in the construction of the CE diagram is to have a clear understanding of the cause-effect relationship. All possible sources of causation need to be considered. There are several useful tools in considering the sources of causation. Tools used in building the CE diagram: 4 W s There are at least four classes of causes that may apply to a particular problem and the 4 W s characterize these classes. The 4 W's of cause and effect should always be considered. The 4 W's are: What Why When Where The 4 W's are an important guide to a full exploration of the possible root causes to a problem. 5 P s For Software Industry, the 5 P's can be used to develop the CE diagram. The 5 P's are People (employees) Product (Software Tools) Process (Methodologies used for SDLC) Place (Operating System or Server environment) Patrons (customers) There are several advantages that the CE diagram offers to the users. 1. The diagram focuses the attention of the team on the specific problem in a structured and systematic method. 2. The diagram allows very complex situations to be presented by showing a clear relationship between the elements and gives a list of all known or suspected causes, which potentially contribute to the effect.

2 The effect being analyzed should be very well defined and limited to focus on the precise areas in the search for potential causes. For instance: The statement, Poor Product Quality, is a poor description of the effect being analyzed. The statement is too broad and open to various interpretations by the group. The statement should read, Reasons for the filing of High Priority bugs from the Customer site. This is a much more clear and focused statement of the effect being analyzed. How to Construct the Fishbone or Cause Effect Diagram The first step involves a clear definition of the effect or symptom for which the causes must be identified. The second step involves the use of brainstorming or a rational step-by-step approach to identify the possible causes of the problem being analyzed. This involves the use of the 4 W s, and the 5 P s. After identifying the major causes, the group selects one of the causes and work on it systematically, identifying as many secondary causes of the major causes as possible. The group then takes all of these secondary causes and checks them to see if there is any relevant tertiary causes for each of them. The group then work systematically down each of the causal chains. The group continues adding all possible causes to the diagram until each branch reaches a root cause. A root cause has three characteristics that will help the group to know when the process is over. These characteristics are: It causes the event we are seeking to explain It is directly controllable The elimination of that potential root cause will result in the elimination or reduction of the problem Lets take a real life example to see how it can be used in a real life scenario: Reason for the new and re-submitted bugs after 100% coverage for CWIS: 4W s: What Resources (the P s) are under-utilized or over-utilized? Why - Too many changes? Late Changes? Wrong implementation? When Requirements frozen too soon? Implementation too late? Too many bugs filed? Where - At the Requirements stage? At the Design stage? At the Implementation stage? 5 P s: People (employees) - Need more Training? Work needs more review? Product (Software Tools) Improvement in inputs? specification? Change in the Tools used? Process (Methodologies used for SDLC) Processes need change? Need better information feedback? Methodologies used needs change? Place (Operating System or Server environment) - Wrong selection? maintenance? Patrons (customers) Communication? Early Interpretation of Ideas?

3 The Primary Causes are: People (employees) Product (Software Tools) Process (Methodologies used for SDLC) Place (Operating System or Server environment) Patrons (customers) The Secondary Causes are: Need more Training? Work needs more review? Improvement in inputs? specification? Change in the Tools used? Processes need change? Need better information feedback? Methodologies used needs change? Wrong selection? maintenance? Communication? Early Interpretation of Ideas? The Root Causes are: Implementation Errors, Late Change in Requirement, Spec Changes not done, Review not effective, Missed in Testing, Dependency on PostScript, Dependency on the Testing Environment, Intermittent problem, Inadequate Test Planning and Execution People Product Process Process needs to be changed?? Need more Training? Work needs more Review? Wrong Selection? Place Improvements in Input? Specifications? Maintenance? Change in Tools Used? Early Interpretation of Ideas? Patrons Information feedback? Methodologies need Change? Communication? Reasons for the New and Resubmitted Bugs after 100% Testing

4 Pareto Analysis Introduction: Pareto analysis was developed from an observation by the Italian-born economist Vilfredo Pareto in the late 19 th Century that a relatively few people held the majority of the wealth. Logarithmic mathematical models were developed which described this nonlinear distribution. This was extended by Joseph Duran to be applicable to a variety of situations and appeared to hold without exception in problems related to quality in general. In simple terms, the Pareto principle would suggest that in any group of factors or causes contributing to a common effect, a relative few, the "vital few" account for the bulk of the effect while the "useful many" account for a smaller portion of the effect. Lets look at some real life examples, which gives this theory a better perspective: The top 5 products or services account for 75% of sales. In a typical code/document review, a few employees tend to make the majority of comments, while most remain relatively quiet. 10% of the employees create 90% of the problems. 10% of the employees take 90% of the manager s time. 10% of the software code results in 90% of the bugs A few employees account for the majority of absences. Steps to do the Pareto Analysis: 1. Use the Fishbone Analysis to identify the Root Causes for the problem at hand 2. Express the magnitude of each of the Root Causes numerically 3. Rank the Root Causes by numerical contribution 4. Determine the cumulative effect of the ranked Root Causes 5. Use tables and graphs to visually illustrate the effect and identify the vital few Goals of Pareto Analysis: To separate the "vital few" from the "useful many". To provide the management/quality deployment team with the data to help them focus on the elimination of the major Root Causes To reduce or eliminate the effect of the "vital few" which would probably result in some of the "useful many" becoming the new "vital few". In some cases however the Pareto analysis may appear to be not applicable such as: When more than 50% of the Root Causes/categories accounts for 60% of the effect. In such a scenario, it is more likely that the Root Causes/categories were not appropriate and the data needs to be stratified in new ways. Case Study: Lets take a real life example to see how Pareto Analysis can be used in a real life scenario:

5 Reason for the new and re-submitted bugs after 100% coverage for CWIS: 1. From the Fishbone (CE) Diagram we have the Root Causes as follows: Implementation Errors Late Change in Requirement Spec Changes not done Review not effective Missed in Testing Dependency on PostScript Dependency on the Testing Environment Intermittent problem Inadequate Test Planning and Execution 2. Magnitude of the Root Causes expressed numerically (in % of the number of Bugs which it resulted in) and their corresponding Ranking 1.Implementation Errors 41.6% 2.Missed in Testing 12.5% 3.Late Change in Request 8.3% 4.Spec Changes not done- 8.3% 5.Dependency on PostScript- 8.3% 6.Inadequate Test Planning and Execution- 8.3% 7.Dependency on the Testing Environment-4.1% 8.Intermittent problem-4.1% 9.Review not effective-4.1% 3. Analysis, Ranking and Displaying by Root Causes/Categories Ranking of Root Causes Root Causes Percentage of Bugs Here the Root Causes are numbered from 1 to 9 on the X-Axis and the corresponding % of the bugs that it caused on the Y-Axis. Conclusion: The Vital Few Root Causes are identified as Implementation Errors and Missed in Testing. So the focus of attention should be on these Vital few and an action plan should be put in place to eliminate or reduce the effect of these Root Causes in the future Printer programs.