<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en-GB">
	<id>http://13.50.150.85/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Williamvoss</id>
	<title>DTU ProjectLab - User contributions [en-gb]</title>
	<link rel="self" type="application/atom+xml" href="http://13.50.150.85/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Williamvoss"/>
	<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php/Special:Contributions/Williamvoss"/>
	<updated>2026-07-14T09:02:53Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.43.3</generator>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122483</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122483"/>
		<updated>2022-03-27T18:38:05Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;Developed by William Vossgård&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
==== Abstract ====&lt;br /&gt;
Root Cause Analysis (RCA) is a method of problem solving that can be used in a project, program or portfolio (PPP) to identify root causes of faults and problems in order to find appropriate solutions. It is broadly used in several industries, among the health care, infrastructure and information technology industry. A Root Cause Analysis supposes that it is more effective to go in-depth of occurring problems, so that the underlaying issue can be treated, instead of only treating ad hoc symptoms. Root Cause Analyses can be performed with several different methodologies, principles and techniques together to identify the root causes of a defect or problem. The goal is to find out where processes or systems failed or caused an issue in the first place. In this article, the most common and broadly used techniques will be covered.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
To be able to fully understand what a root cause analysis is and what it is used for, it is easier to relate it to something we are entirely acknowledged with. If your arm hurts considerably after an accident, you will go to the doctor to find the root cause of your pain. Also, if your computer stops working, you will try to find the root cause of its malfunction, either by yourself or by a professional technician. For these examples, a simple remedy could be found for the symptoms. To stop your arm from hurting, you could put ice on it to relive pain. To get work done with a broken computer, you could use your phone or tablet instead. Unfortunately, this would only consider the symptoms, and not the underlaying issue that caused the problem. The injured arm may need surgery to entirely recover from the sustained injury, and the broken computer may need to have a new battery to function again. The best way to solve a fault or problem would therefore be to perform a Root Cause Analysis. By doing this, the exact root cause can be found so that the correct remedy of the fault or problem will be accomplished. There are a number of techniques and strategies that can be used for root cause analyses. In this article, the most commonly and widely used techniques will be covered.&lt;br /&gt;
&lt;br /&gt;
== Conducting a root cause analysis ==&lt;br /&gt;
&lt;br /&gt;
===== Goals and benefits =====&lt;br /&gt;
&lt;br /&gt;
Related to the root cause analysis, there are three goals that should be realised. &#039;&#039;&#039;The first&#039;&#039;&#039; one being to discover the root cause of a failure or problem. &#039;&#039;&#039;The&#039;&#039;&#039; second is to develop an understanding on how to fix and learn from the underlaying issues relating the root cause. &#039;&#039;&#039;The third&#039;&#039;&#039; and final is to apply the findings from the root cause analysis, to systematically prevent future issues or problems. This goal is especially important as this is what gives the analysis a reason to be performed. Root cause analyses can be used for increasing the productiveness in several core processes as well, with the goal to prevent any issues occurring in the future [https://www.tableau.com/learn/articles/root-cause-analysis [1]].&lt;br /&gt;
&lt;br /&gt;
===== General principles =====&lt;br /&gt;
&lt;br /&gt;
To achieve an effective root cause analysis process, there are some general principles that should be taken into consideration. These principles will increase the quality of the analysis and will help the analysis get trust from clients and stakeholders [https://www.geeksforgeeks.org/basic-principle-of-root-cause-analysis/[2]].&lt;br /&gt;
&lt;br /&gt;
*Root cause analyses gives the best effect when a team is gathered, to do the analysis together. In particular, it should be done with those employees, who are directly involved in the problem-causing processes.&lt;br /&gt;
*Consider to actually correct and remedy the root causes, not only the symptoms.&lt;br /&gt;
*While performing the root cause analysis, also remember to treat symptoms for short term fixing.&lt;br /&gt;
*Avoid focus on who was responsible of the failure or problem, instead focus on how and why.&lt;br /&gt;
*Find and document ways to prevent similar root causes in the future.&lt;br /&gt;
*When finding root causes, provide cause-effect evidence to back it up.&lt;br /&gt;
*Often there are multiple root causes, therefore search for several.&lt;br /&gt;
&lt;br /&gt;
As it can be understood from the principles above, it is important to take a comprehensive and holistic approach in this type of analysis. As the root causes have no importance if no action is taken afterwards, it should be strived to provide information and context that can solve the failure or problem.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Fishbone Diagram ===&lt;br /&gt;
A Fishbone diagram, which also is called an Ishikawa diagram, is like the other root cause analysis tools used to identify root causes of defects or problems. The fishbone diagram provides an organised way of looking at effects and causes, and can therefore be referred to as a cause-and-effect diagram. It generally represents a model of indicative presentation for the correlations between an event, which is an effect, and its several causes. This helps the team members get the same understanding of the problem, so that they can think systematically. The root causes of a problem can by using this structured approach be found, while encouraging group participation, utilising group knowledge and identifying areas where data should be collected for future studies. Hence the name, the diagram has the same structure as the skeleton of a fish. While it most often is used in a simple representation, with segments leaning on a horizontal axis, it can also be done with a more extensive approach. An example of this is by naming and coding of the risks which characterises the causes and sub-causes. This consists of elements that show the causes and sub-causes succession with different ways for risk treatment [https://www.researchgate.net/publication/46567642_Application_Of_Fishbone_Diagram_To_Determine_The_Risk_Of_An_Event_With_Multiple_Causes[3]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:A-generic-representation-of-the-Ishikawa-diagram-aka-Fishbone-diagram.png|400px|thumb|centre|Figure 1: Illustration of a Fishbone diagram]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Five steps should be followed to successful use the Fishbone diagram technique [https://www.ionos.ca/startupguide/productivity/fishbone-diagram/[4]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#The first step is to state the problem precisely. This problem statement must be carefully chosen, and it is important that it is specific enough.&lt;br /&gt;
#Define the main influencing factors. This is the factors are put in the horizontal category segments in the fishbone diagram. Different defects or problems have different influencing, which means that these should be chosen after what is relevant. Examples of these is seen in the figure 1.&lt;br /&gt;
#State the causes into the diagram sorted after the different categories. This should be done with those employees that are directly involved in the problem causing processes. Also, the team should consist of a mix of different levels of expertise. When analysing the problem statement and finding causes, further sub-causes can be elaborated upon.&lt;br /&gt;
#Prioritise the causes. In the same team, make each person state their opinion as what is the most serious cause of the defect or problem. After a discussion about the causes, each person can give points to the causes that they believe are the most serious. The causes with the most points, should then be prioritised.&lt;br /&gt;
#Take measures. Tackle the defect or problem by eradicating the cause or causes. I it’s important that it is certain that the correct cause have been identified. To make sure of this, a significance test can be used for verifying, in order to select suitable methods for problem-solving.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== The 5 Whys ===&lt;br /&gt;
The 5 whys is a simple, yet powerful way of finding root causes. It works as an iterative interrogative technique used to explore cause-and-effect relationship underlaying a particular defect or problem. It is often used together with the a Fishbone diagram to find the root causes of the problems listed in the diagram. As the name of the technique implies, the primary goal is to find the root cause of a problem by asking “Why?” five times. Each answer of the “Whys” forms the basis for the next question, and when the fifth “Why?” have been answered, the root cause should be found. Five times is generally enough, but if the root cause still not is found, it could be repeated up to a total of six, seven or higher levels. For problems or defects that do not have one single root cause, the technique must be repeated asking a different sequence of questions each time [https://www.corship.eu/5-whys-method/[5]]. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:5-whys-example (1).png|500px|thumb|right|Figure 2: Example of a 5 whys analysis[https://www.corship.eu/5-whys-method/]]]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The five steps to conduct the 5 whys analysis, is to [https://www.adb.org/publications/five-whys-technique[6]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather a team who can develop a problem statement in agreement. At this point, it should be discussed whether additionally individuals are needed to resolve the problem. &lt;br /&gt;
#Make the team come with statements on “Why is this or that defect or problem taking place?”. This is the first “why” of the analysis. There are most probable multiple statements for this, and they should all be written down.&lt;br /&gt;
#Repeat the same process asking “why” four more times. This should be done for every statement from the first “why” in the structure like figure 2 shows. All plausible answers should be written down. When the “why” does not yield further useful information, you have found the root cause. This means that is sometimes may take more than five layers to find the root cause.&lt;br /&gt;
#Among the many answers to the last asked “why”, look for systematic causes of the defect or problem. This should be discussed in the group to be able to settle for the most likely systematic cause. The product from the team session should then be showed to others to confirm that they see the same logic in the analysis.&lt;br /&gt;
#The last and final step of the 5 why analysis is to develop appropriate corrective actions to remove the root cause from the system. Others can undertake these actions but planning and implementation will benefit from inputs from the team.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===Pareto Chart Analysis===&lt;br /&gt;
[[File:Pareto output.png|400px|thumb|right|Figure 3: The 20/80 principle]]&lt;br /&gt;
The Pareto chart combines a histogram (bar chart) and a line chart, where cost or frequency of defects or problems show their relative importance. Frequencies are shown in the histogram with descending order of the bars, and the line chart shows the totals or the cumulative percentages increasing from left to right. It is based on the Pareto principle, which states that “80% of the effects or consequences come from 20% of the causes”. This is not like the immutable laws of physics but on continuous observations. On those observations, it has showed to be applicable to many aspects of life and natural phenomena. In relation to a root cause analysis, the Pareto Chart Analysis helps identify the top 20% of the causes that needs to be addressed to resolve 80% of the problems [https://www.slideshare.net/himanshuhora/pareto-analysis-28873221[7]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;In order to perform a Pareto Chart Analysis, the following needs to be done [https://www.slideshare.net/himanshuhora/pareto-analysis-28873221[7]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather and collect data on the frequency of the causes of a defect or problem.&lt;br /&gt;
#Sort the causes after most to least important, and then calculate the cumulative percentage.&lt;br /&gt;
#Plot bars of the causes ordered from most to least frequent on the x-axis, and then plot the cumulative percentages on the y-axis. &lt;br /&gt;
#Finally, separate the 20% most important root causes from the rest by lifting the x-axis to the 80% cumulative percent on the y-axis.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:Pareto-chart-example.png|600px|thumb|left|Figure 4: An example of a Pareto Chart Analysis[https://www.whatissixsigma.net/pareto-chart-and-analysis/]]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Challenges and limitations ==&lt;br /&gt;
&lt;br /&gt;
For the Root Cause Analysis to give results, it is dependent on a larger problem-solving effort to improve the quality in a business. It therefore the managements responsibility to make the best use of the findings from the root cause analyses. The root cause analysis on itself would not provide any result. When it comes to the conduction of a root cause analysis, it is hard to fully know if you have taken every root cause into consideration. The reason for this is because there can be multiple root causes, and there is hard to tell when every root cause has been found. This can lead to too much time spent on irrelevant underlaying factors, which result in confusion and a waste of time. The 5 whys and the fishbone analysis does not rely on specific data, which can lead to less reliable results. The management can therefore have trouble trusting these analyses completely.&lt;br /&gt;
&lt;br /&gt;
==Annotated Bibliography==&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The 5 whys by Olivier Serrat&#039;&#039;&#039;&lt;br /&gt;
The article “The Five Whys Technique” by Olivier Serrat, provides powerful knowledge within the use of the five “why” technique. It provides sufficient information both in relation to the background and meaning of using this technique, but also a step by step guide on how to use it in practice. This is very useful both for current and upcoming managers who will stumble upon a need to use this technique in real life. The article is short, which makes it quick to read. But if there is a need for further knowledge within the subject, reading material of high quality is referred to at the end of the article.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Root Cause Analysis: The Core of Problem Solving and Corrective Action by Duke Okes&#039;&#039;&#039;&lt;br /&gt;
In the book Root Cause Analysis: The Core of Problem Solving and Corrective Action, the author Duke Okes goes in-depth of the importance of using and how to use root cause analyses to catch the actual root causes of problems, and not only the symptoms of them. Different techniques to be implemented into a business are presented in detail so that the management in a company can reduce the amount of reoccurring problems. The terminology in this book is also simpler than most articles and research books, which makes it easy to read for the management.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The Importance of Root Cause Analysis During Incident Investigation by the Occupational Safety and Health Administration (OSHA)&#039;&#039;&#039;&lt;br /&gt;
The factsheet supplied by the OSHA provides a hands-on guidance for conducting root cause analyses in general. Different from most other articles this factsheet provides clear instructions for the whole root cause analysis process, both on a low level where problems are easy to find the causes for, but also for more complex problems. This gives the employees a good understanding of when to actually contact the upper management, which is very useful to achieve optimal efficiency in a company.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
[https://www.tableau.com/learn/articles/root-cause-analysis [1]] Root Cause Analysis Explained: Definition, Examples, and Methods by Tableau&lt;br /&gt;
&lt;br /&gt;
[https://www.geeksforgeeks.org/basic-principle-of-root-cause-analysis/ [2]] Basic Principle of Root cause analysis by GeeksforGeeks&lt;br /&gt;
&lt;br /&gt;
[https://www.researchgate.net/publication/46567642_Application_Of_Fishbone_Diagram_To_Determine_The_Risk_Of_An_Event_With_Multiple_Causes [3]] Application Of Fishbone Diagram To Determine The Risk Of An Event With Multiple Causes by the UTI Grup SRL and the Academy of Economic Studies&lt;br /&gt;
&lt;br /&gt;
[https://www.ionos.ca/startupguide/productivity/fishbone-diagram/[4]] Fishbone diagram: Solving problems properly by IONOS&lt;br /&gt;
&lt;br /&gt;
[https://www.corship.eu/5-whys-method/ [5]] 5 Whys Method by CORSHIP – CORPORATE EDUPRENEURSHIP&lt;br /&gt;
&lt;br /&gt;
[https://www.adb.org/publications/five-whys-technique [6]] The Five Whys Technique by Olivier Serrat&lt;br /&gt;
&lt;br /&gt;
[https://www.slideshare.net/himanshuhora/pareto-analysis-28873221 [7]]Pareto Analysis by Dr. Himanshu Hora, SRMS College of Engineering &amp;amp; Technology Bareilly&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122481</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122481"/>
		<updated>2022-03-27T18:37:38Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;Developed by William Vossgård&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
==== Abstract ====&lt;br /&gt;
Root Cause Analysis (RCA) is a method of problem solving that can be used in a project, program or portfolio (PPP) to identify root causes of faults and problems in order to find appropriate solutions. It is broadly used in several industries, among the health care, infrastructure and information technology industry. A Root Cause Analysis supposes that it is more effective to go in-depth of occurring problems, so that the underlaying issue can be treated, instead of only treating ad hoc symptoms. Root Cause Analyses can be performed with several different methodologies, principles and techniques together to identify the root causes of a defect or problem. The goal is to find out where processes or systems failed or caused an issue in the first place. In this article, the most common and broadly used techniques will be covered.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
To be able to fully understand what a root cause analysis is and what it is used for, it is easier to relate it to something we are entirely acknowledged with. If your arm hurts considerably after an accident, you will go to the doctor to find the root cause of your pain. Also, if your computer stops working, you will try to find the root cause of its malfunction, either by yourself or by a professional technician. For these examples, a simple remedy could be found for the symptoms. To stop your arm from hurting, you could put ice on it to relive pain. To get work done with a broken computer, you could use your phone or tablet instead. Unfortunately, this would only consider the symptoms, and not the underlaying issue that caused the problem. The injured arm may need surgery to entirely recover from the sustained injury, and the broken computer may need to have a new battery to function again. The best way to solve a fault or problem would therefore be to perform a Root Cause Analysis. By doing this, the exact root cause can be found so that the correct remedy of the fault or problem will be accomplished. There are a number of techniques and strategies that can be used for root cause analyses. In this article, the most commonly and widely used techniques will be covered.&lt;br /&gt;
&lt;br /&gt;
== Conducting a root cause analysis ==&lt;br /&gt;
&lt;br /&gt;
===== Goals and benefits =====&lt;br /&gt;
&lt;br /&gt;
Related to the root cause analysis, there are three goals that should be realised. &#039;&#039;&#039;The first&#039;&#039;&#039; one being to discover the root cause of a failure or problem. &#039;&#039;&#039;The&#039;&#039;&#039; second is to develop an understanding on how to fix and learn from the underlaying issues relating the root cause. &#039;&#039;&#039;The third&#039;&#039;&#039; and final is to apply the findings from the root cause analysis, to systematically prevent future issues or problems. This goal is especially important as this is what gives the analysis a reason to be performed. Root cause analyses can be used for increasing the productiveness in several core processes as well, with the goal to prevent any issues occurring in the future [https://www.tableau.com/learn/articles/root-cause-analysis [1]].&lt;br /&gt;
&lt;br /&gt;
===== General principles =====&lt;br /&gt;
&lt;br /&gt;
To achieve an effective root cause analysis process, there are some general principles that should be taken into consideration. These principles will increase the quality of the analysis and will help the analysis get trust from clients and stakeholders [https://www.geeksforgeeks.org/basic-principle-of-root-cause-analysis/[2]].&lt;br /&gt;
&lt;br /&gt;
*Root cause analyses gives the best effect when a team is gathered, to do the analysis together. In particular, it should be done with those employees, who are directly involved in the problem-causing processes.&lt;br /&gt;
*Consider to actually correct and remedy the root causes, not only the symptoms.&lt;br /&gt;
*While performing the root cause analysis, also remember to treat symptoms for short term fixing.&lt;br /&gt;
*Avoid focus on who was responsible of the failure or problem, instead focus on how and why.&lt;br /&gt;
*Find and document ways to prevent similar root causes in the future.&lt;br /&gt;
*When finding root causes, provide cause-effect evidence to back it up.&lt;br /&gt;
*Often there are multiple root causes, therefore search for several.&lt;br /&gt;
&lt;br /&gt;
As it can be understood from the principles above, it is important to take a comprehensive and holistic approach in this type of analysis. As the root causes have no importance if no action is taken afterwards, it should be strived to provide information and context that can solve the failure or problem.&lt;br /&gt;
&lt;br /&gt;
=== Fishbone Diagram ===&lt;br /&gt;
A Fishbone diagram, which also is called an Ishikawa diagram, is like the other root cause analysis tools used to identify root causes of defects or problems. The fishbone diagram provides an organised way of looking at effects and causes, and can therefore be referred to as a cause-and-effect diagram. It generally represents a model of indicative presentation for the correlations between an event, which is an effect, and its several causes. This helps the team members get the same understanding of the problem, so that they can think systematically. The root causes of a problem can by using this structured approach be found, while encouraging group participation, utilising group knowledge and identifying areas where data should be collected for future studies. Hence the name, the diagram has the same structure as the skeleton of a fish. While it most often is used in a simple representation, with segments leaning on a horizontal axis, it can also be done with a more extensive approach. An example of this is by naming and coding of the risks which characterises the causes and sub-causes. This consists of elements that show the causes and sub-causes succession with different ways for risk treatment [https://www.researchgate.net/publication/46567642_Application_Of_Fishbone_Diagram_To_Determine_The_Risk_Of_An_Event_With_Multiple_Causes[3]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:A-generic-representation-of-the-Ishikawa-diagram-aka-Fishbone-diagram.png|400px|thumb|centre|Figure 1: Illustration of a Fishbone diagram]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Five steps should be followed to successful use the Fishbone diagram technique [https://www.ionos.ca/startupguide/productivity/fishbone-diagram/[4]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#The first step is to state the problem precisely. This problem statement must be carefully chosen, and it is important that it is specific enough.&lt;br /&gt;
#Define the main influencing factors. This is the factors are put in the horizontal category segments in the fishbone diagram. Different defects or problems have different influencing, which means that these should be chosen after what is relevant. Examples of these is seen in the figure 1.&lt;br /&gt;
#State the causes into the diagram sorted after the different categories. This should be done with those employees that are directly involved in the problem causing processes. Also, the team should consist of a mix of different levels of expertise. When analysing the problem statement and finding causes, further sub-causes can be elaborated upon.&lt;br /&gt;
#Prioritise the causes. In the same team, make each person state their opinion as what is the most serious cause of the defect or problem. After a discussion about the causes, each person can give points to the causes that they believe are the most serious. The causes with the most points, should then be prioritised.&lt;br /&gt;
#Take measures. Tackle the defect or problem by eradicating the cause or causes. I it’s important that it is certain that the correct cause have been identified. To make sure of this, a significance test can be used for verifying, in order to select suitable methods for problem-solving.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== The 5 Whys ===&lt;br /&gt;
The 5 whys is a simple, yet powerful way of finding root causes. It works as an iterative interrogative technique used to explore cause-and-effect relationship underlaying a particular defect or problem. It is often used together with the a Fishbone diagram to find the root causes of the problems listed in the diagram. As the name of the technique implies, the primary goal is to find the root cause of a problem by asking “Why?” five times. Each answer of the “Whys” forms the basis for the next question, and when the fifth “Why?” have been answered, the root cause should be found. Five times is generally enough, but if the root cause still not is found, it could be repeated up to a total of six, seven or higher levels. For problems or defects that do not have one single root cause, the technique must be repeated asking a different sequence of questions each time [https://www.corship.eu/5-whys-method/[5]]. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:5-whys-example (1).png|500px|thumb|right|Figure 2: Example of a 5 whys analysis[https://www.corship.eu/5-whys-method/]]]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The five steps to conduct the 5 whys analysis, is to [https://www.adb.org/publications/five-whys-technique[6]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather a team who can develop a problem statement in agreement. At this point, it should be discussed whether additionally individuals are needed to resolve the problem. &lt;br /&gt;
#Make the team come with statements on “Why is this or that defect or problem taking place?”. This is the first “why” of the analysis. There are most probable multiple statements for this, and they should all be written down.&lt;br /&gt;
#Repeat the same process asking “why” four more times. This should be done for every statement from the first “why” in the structure like figure 2 shows. All plausible answers should be written down. When the “why” does not yield further useful information, you have found the root cause. This means that is sometimes may take more than five layers to find the root cause.&lt;br /&gt;
#Among the many answers to the last asked “why”, look for systematic causes of the defect or problem. This should be discussed in the group to be able to settle for the most likely systematic cause. The product from the team session should then be showed to others to confirm that they see the same logic in the analysis.&lt;br /&gt;
#The last and final step of the 5 why analysis is to develop appropriate corrective actions to remove the root cause from the system. Others can undertake these actions but planning and implementation will benefit from inputs from the team.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===Pareto Chart Analysis===&lt;br /&gt;
[[File:Pareto output.png|400px|thumb|right|Figure 3: The 20/80 principle]]&lt;br /&gt;
The Pareto chart combines a histogram (bar chart) and a line chart, where cost or frequency of defects or problems show their relative importance. Frequencies are shown in the histogram with descending order of the bars, and the line chart shows the totals or the cumulative percentages increasing from left to right. It is based on the Pareto principle, which states that “80% of the effects or consequences come from 20% of the causes”. This is not like the immutable laws of physics but on continuous observations. On those observations, it has showed to be applicable to many aspects of life and natural phenomena. In relation to a root cause analysis, the Pareto Chart Analysis helps identify the top 20% of the causes that needs to be addressed to resolve 80% of the problems [https://www.slideshare.net/himanshuhora/pareto-analysis-28873221[7]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;In order to perform a Pareto Chart Analysis, the following needs to be done [https://www.slideshare.net/himanshuhora/pareto-analysis-28873221[7]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather and collect data on the frequency of the causes of a defect or problem.&lt;br /&gt;
#Sort the causes after most to least important, and then calculate the cumulative percentage.&lt;br /&gt;
#Plot bars of the causes ordered from most to least frequent on the x-axis, and then plot the cumulative percentages on the y-axis. &lt;br /&gt;
#Finally, separate the 20% most important root causes from the rest by lifting the x-axis to the 80% cumulative percent on the y-axis.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:Pareto-chart-example.png|600px|thumb|left|Figure 4: An example of a Pareto Chart Analysis[https://www.whatissixsigma.net/pareto-chart-and-analysis/]]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Challenges and limitations ==&lt;br /&gt;
&lt;br /&gt;
For the Root Cause Analysis to give results, it is dependent on a larger problem-solving effort to improve the quality in a business. It therefore the managements responsibility to make the best use of the findings from the root cause analyses. The root cause analysis on itself would not provide any result. When it comes to the conduction of a root cause analysis, it is hard to fully know if you have taken every root cause into consideration. The reason for this is because there can be multiple root causes, and there is hard to tell when every root cause has been found. This can lead to too much time spent on irrelevant underlaying factors, which result in confusion and a waste of time. The 5 whys and the fishbone analysis does not rely on specific data, which can lead to less reliable results. The management can therefore have trouble trusting these analyses completely.&lt;br /&gt;
&lt;br /&gt;
==Annotated Bibliography==&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The 5 whys by Olivier Serrat&#039;&#039;&#039;&lt;br /&gt;
The article “The Five Whys Technique” by Olivier Serrat, provides powerful knowledge within the use of the five “why” technique. It provides sufficient information both in relation to the background and meaning of using this technique, but also a step by step guide on how to use it in practice. This is very useful both for current and upcoming managers who will stumble upon a need to use this technique in real life. The article is short, which makes it quick to read. But if there is a need for further knowledge within the subject, reading material of high quality is referred to at the end of the article.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Root Cause Analysis: The Core of Problem Solving and Corrective Action by Duke Okes&#039;&#039;&#039;&lt;br /&gt;
In the book Root Cause Analysis: The Core of Problem Solving and Corrective Action, the author Duke Okes goes in-depth of the importance of using and how to use root cause analyses to catch the actual root causes of problems, and not only the symptoms of them. Different techniques to be implemented into a business are presented in detail so that the management in a company can reduce the amount of reoccurring problems. The terminology in this book is also simpler than most articles and research books, which makes it easy to read for the management.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The Importance of Root Cause Analysis During Incident Investigation by the Occupational Safety and Health Administration (OSHA)&#039;&#039;&#039;&lt;br /&gt;
The factsheet supplied by the OSHA provides a hands-on guidance for conducting root cause analyses in general. Different from most other articles this factsheet provides clear instructions for the whole root cause analysis process, both on a low level where problems are easy to find the causes for, but also for more complex problems. This gives the employees a good understanding of when to actually contact the upper management, which is very useful to achieve optimal efficiency in a company.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
[https://www.tableau.com/learn/articles/root-cause-analysis [1]] Root Cause Analysis Explained: Definition, Examples, and Methods by Tableau&lt;br /&gt;
&lt;br /&gt;
[https://www.geeksforgeeks.org/basic-principle-of-root-cause-analysis/ [2]] Basic Principle of Root cause analysis by GeeksforGeeks&lt;br /&gt;
&lt;br /&gt;
[https://www.researchgate.net/publication/46567642_Application_Of_Fishbone_Diagram_To_Determine_The_Risk_Of_An_Event_With_Multiple_Causes [3]] Application Of Fishbone Diagram To Determine The Risk Of An Event With Multiple Causes by the UTI Grup SRL and the Academy of Economic Studies&lt;br /&gt;
&lt;br /&gt;
[https://www.ionos.ca/startupguide/productivity/fishbone-diagram/[4]] Fishbone diagram: Solving problems properly by IONOS&lt;br /&gt;
&lt;br /&gt;
[https://www.corship.eu/5-whys-method/ [5]] 5 Whys Method by CORSHIP – CORPORATE EDUPRENEURSHIP&lt;br /&gt;
&lt;br /&gt;
[https://www.adb.org/publications/five-whys-technique [6]] The Five Whys Technique by Olivier Serrat&lt;br /&gt;
&lt;br /&gt;
[https://www.slideshare.net/himanshuhora/pareto-analysis-28873221 [7]]Pareto Analysis by Dr. Himanshu Hora, SRMS College of Engineering &amp;amp; Technology Bareilly&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122470</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122470"/>
		<updated>2022-03-27T18:23:34Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;Developed by William Vossgård&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
==== Abstract ====&lt;br /&gt;
Root Cause Analysis (RCA) is a method of problem solving that can be used in a project, program or portfolio (PPP) to identify root causes of faults and problems in order to find appropriate solutions. It is broadly used in several industries, among the health care, infrastructure and information technology industry. A Root Cause Analysis supposes that it is more effective to go in-depth of occurring problems, so that the underlaying issue can be treated, instead of only treating ad hoc symptoms. Root Cause Analyses can be performed with several different methodologies, principles and techniques together to identify the root causes of a defect or problem. The goal is to find out where processes or systems failed or caused an issue in the first place. In this article, the most common and broadly used techniques will be covered.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
To be able to fully understand what a root cause analysis is and what it is used for, it is easier to relate it to something we are entirely acknowledged with. If your arm hurts considerably after an accident, you will go to the doctor to find the root cause of your pain. Also, if your computer stops working, you will try to find the root cause of its malfunction, either by yourself or by a professional technician. For these examples, a simple remedy could be found for the symptoms. To stop your arm from hurting, you could put ice on it to relive pain. To get work done with a broken computer, you could use your phone or tablet instead. Unfortunately, this would only consider the symptoms, and not the underlaying issue that caused the problem. The injured arm may need surgery to entirely recover from the sustained injury, and the broken computer may need to have a new battery to function again. The best way to solve a fault or problem would therefore be to perform a Root Cause Analysis. By doing this, the exact root cause can be found so that the correct remedy of the fault or problem will be accomplished. There are a number of techniques and strategies that can be used for root cause analyses. In this article, the most commonly and widely used techniques will be covered.&lt;br /&gt;
&lt;br /&gt;
== Conducting a root cause analysis ==&lt;br /&gt;
&lt;br /&gt;
===== Goals and benefits =====&lt;br /&gt;
&lt;br /&gt;
Related to the root cause analysis, there are three goals that should be realised. &#039;&#039;&#039;The first&#039;&#039;&#039; one being to discover the root cause of a failure or problem. &#039;&#039;&#039;The&#039;&#039;&#039; second is to develop an understanding on how to fix and learn from the underlaying issues relating the root cause. &#039;&#039;&#039;The third&#039;&#039;&#039; and final is to apply the findings from the root cause analysis, to systematically prevent future issues or problems. This goal is especially important as this is what gives the analysis a reason to be performed. Root cause analysis can be used for increasing the productiveness in several core processes as well, with the goal to prevent any issues in the future [https://www.tableau.com/learn/articles/root-cause-analysis [1]].&lt;br /&gt;
&lt;br /&gt;
===== General principles =====&lt;br /&gt;
&lt;br /&gt;
To achieve an effective root cause analysis process, there are some general principles that should be taken into consideration. These principles will increase the quality of the analysis and will help the analysis get trust from clients and stakeholders [https://www.geeksforgeeks.org/basic-principle-of-root-cause-analysis/[2]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
*Root cause analyses gives the best effect when a team is gathered, to do the analysis together. In particular, it should be done with those employees, who are directly involved in the problem-causing processes.&lt;br /&gt;
*Consider to actually correct and remedy the root causes, not only the symptoms.&lt;br /&gt;
*While performing the root cause analysis, also remember to treat symptoms for short term fixing.&lt;br /&gt;
*Avoid focus on who was responsible of the failure or problem, instead focus on how and why.&lt;br /&gt;
*Find and document ways to prevent similar root causes in the future.&lt;br /&gt;
*When finding root causes, provide cause-effect evidence to back it up.&lt;br /&gt;
*Often there are multiple root causes, therefore search for several.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
As it can be understood from the principles above, it is important to take a comprehensive and holistic approach in this type of analysis. As the root causes have no importance if no action is taken afterwards, it should be strived to provide information and context that can solve the failure or problem.&lt;br /&gt;
&lt;br /&gt;
=== Fishbone Diagram ===&lt;br /&gt;
A Fishbone diagram, which also is called an Ishikawa diagram, is used to identify root causes of quality problems. The fishbone diagram provides an organised way of looking at effects and causes. It can also be referred to as a cause-and-effect diagram. It generally represents a model of indicative presentation for the correlations between an event, which is an effect, and its several causes. This helps the team members get the same understanding of the problem, so that they can think systematically. The root causes of a problem can by using this structured approach be found, while encouraging group participation, utilising group knowledge and identifying areas where data should be collected for future studies. Hence the name, the diagram has the same structure as the skeleton of a fish. While it most often is used in a simple representation, with segments leaning on a horizontal axis, it can also be done with a more extensive approach. An example of this is by naming and coding of the risks which characterises the causes and sub-causes. This consists of elements that show the causes and sub-causes succession with different ways for risk treatment [https://www.researchgate.net/publication/46567642_Application_Of_Fishbone_Diagram_To_Determine_The_Risk_Of_An_Event_With_Multiple_Causes[3]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:A-generic-representation-of-the-Ishikawa-diagram-aka-Fishbone-diagram.png|400px|thumb|centre|Figure 1: Illustration of a Fishbone diagram]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Five steps should be followed to successful use the Fishbone diagram technique [https://www.ionos.ca/startupguide/productivity/fishbone-diagram/[4]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#The first step is to state the problem precisely. This problem statement must be carefully chosen, and it is important that it is specific enough.&lt;br /&gt;
#Define the main influencing factors. This is the factors are put in the horizontal category segments in the fishbone diagram. Different defects or problems have different influencing, which means that these should be chosen after what is relevant. Examples of these is seen in the figure 1.&lt;br /&gt;
#State the causes into the diagram sorted after the different categories. This should be done with those employees that are directly involved in the problem causing processes. Also, the team should consist of a mix of different levels of expertise. When analysing the problem statement and finding causes, further sub-causes can be elaborated upon.&lt;br /&gt;
#Prioritise the causes. In the same team, make each person state their opinion as what is the most serious cause of the defect or problem. After a discussion about the causes, each person can give points to the causes that they believe are the most serious. The causes with the most points, should then be prioritised.&lt;br /&gt;
#Take measures. Tackle the defect or problem by eradicating the cause or causes. I it’s important that it is certain that the correct cause have been identified. To make sure of this, a significance test can be used for verifying, in order to select suitable methods for problem-solving.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== The 5 Whys ===&lt;br /&gt;
The 5 whys is a simple, yet powerful way of finding root causes. It works as an iterative interrogative technique to explore cause-and-effect relationship underlaying a particular problem. It is often used together with the a Fishbone diagram to find the root causes for the causes on the diagram.  As the name of technique implies, the primary goal is to find the root cause of a problem by asking “Why?” five times. Each answer of the “Whys” forms the basis for the next question, and when the fifth “Why?” have been answered, the root cause should be found. Five times is generally enough, but if the root cause still not is found, it could be repeated up to a total of six, seven or higher levels. For problems or defects that do not have one single root cause, the technique must be repeated asking a different sequence of questions each time [https://www.corship.eu/5-whys-method/[5]]. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:5-whys-example (1).png|500px|thumb|right|Figure 2: Example of a 5 whys analysis[https://www.corship.eu/5-whys-method/]]]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The five steps to conduct the 5 whys analysis, is to [https://www.adb.org/publications/five-whys-technique[6]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather a team who can develop a problem statement in agreement. At this point, it should be discussed whether additionally individuals are needed to resolve the problem. &lt;br /&gt;
#Make the team come with statements on “Why is this or that defect or problem taking place?”. This is the first “why” of the analysis. There are most probable multiple statements for this, and they should all be written down.&lt;br /&gt;
#Repeat the same process asking “why” four more times. This should be done for every statement from the first “why” in the structure like figure 2 shows. All plausible answers should be written down. When the “why” does not yield further useful information, you have found the root cause. This means that is sometimes may take more than five layers to find the root cause.&lt;br /&gt;
#Among the many answers to the last asked “why”, look for systematic causes of the defect or problem. This should be discussed in the group to be able to settle for the most likely systematic cause. The product from the team session should then be showed to others to confirm that they see the same logic in the analysis.&lt;br /&gt;
#The last and final step of the 5 why analysis is to develop appropriate corrective actions to remove the root cause from the system. Others can undertake these actions but planning and implementation will benefit from inputs from the team.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===Pareto Chart Analysis===&lt;br /&gt;
[[File:Pareto output.png|400px|thumb|right|Figure 3: The 20/80 principle]]&lt;br /&gt;
The Pareto chart combines a histogram (bar chart) and a line chart, where cost or frequency of defects or problems show their relative importance. Frequencies are shown in the histogram with descending order of the bars, and the line chart shows the totals or the cumulative percentages increasing from left to right. It is based on the Pareto principle, which states that “80% of the effects or consequences come from 20% of the causes”. This is not like the immutable laws of physics but based on continuous observations. On those observations, it has showed to be applicable to many aspects of life and natural phenomena. In relation to a root cause analysis, the Pareto Chart Analysis helps identify the top 20% of the causes that needs to be addressed to resolve 80% of the problems [https://www.slideshare.net/himanshuhora/pareto-analysis-28873221[7]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;In order to perform a Pareto Chart Analysis, the following needs to be done [https://www.slideshare.net/himanshuhora/pareto-analysis-28873221[7]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather and collect data on the frequency of the causes of a defect or problem.&lt;br /&gt;
#Sort the causes after most to least important, and then calculate the cumulative percentage.&lt;br /&gt;
#Plot bars of the causes ordered from most to least frequent on the x-axis, and then plot the cumulative percentages on the y-axis. &lt;br /&gt;
#Finally, separate the 20% most important root causes from the rest by lifting the x-axis to the 80% cumulative percent on the y-axis.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:Pareto-chart-example.png|600px|thumb|left|Figure 4: An example of a Pareto Chart Analysis[https://www.whatissixsigma.net/pareto-chart-and-analysis/]]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Challenges and limitations ==&lt;br /&gt;
&lt;br /&gt;
For the Root Cause Analysis to give results, it is dependent on a larger problem-solving effort to improve the quality in a business. It therefore the managements responsibility to make the best use of the findings from the root cause analyses. The root cause analysis on itself would not provide the correct result. When it comes to the conduction of a root cause analysis, it is hard to fully know if you have taken every root cause into consideration. The reason for this is because there can be multiple root causes, and there is hard to tell when every root cause has been found. This can lead to too much time spent on irrelevant underlaying factors, which result in confusion and a waste of time. The 5 whys and the fishbone analysis does not rely on specific data, which can lead to less reliable results. The management can therefore have trouble entirely trusting these analyses.&lt;br /&gt;
&lt;br /&gt;
==Annotated Bibliography==&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The 5 whys by Olivier Serrat&#039;&#039;&#039;&lt;br /&gt;
The article “The Five Whys Technique” by Olivier Serrat, provides powerful knowledge within the use of the five “why” technique. It provides sufficient information both in relation to the background and meaning of using this technique, but also a step by step guide on how to use it in practice. This is very useful both for current and upcoming managers who will stumble upon a need to use this technique in real life. The article is short, which makes it quick to read. But if there is a need for further knowledge within the subject, reading material of high quality is referred to at the end of the article.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Root Cause Analysis: The Core of Problem Solving and Corrective Action by Duke Okes&#039;&#039;&#039;&lt;br /&gt;
In the book Root Cause Analysis: The Core of Problem Solving and Corrective Action, the author Duke Okes goes in-depth of the importance of using and how to use root cause analyses to catch the actual root causes of problems, and not only the symptoms of them. Different techniques to be implemented into a business are presented in detail so that the management in a company can reduce the amount of reoccurring problems. The terminology in this book is also simpler than most articles and research books, which makes it easy to read for the management.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The Importance of Root Cause Analysis During Incident Investigation by the Occupational Safety and Health Administration (OSHA)&#039;&#039;&#039;&lt;br /&gt;
The factsheet supplied by the OSHA provides a hands-on guidance for conducting root cause analyses in general. Different from most other articles this factsheet provides clear instructions for the whole root cause analysis process, both on a low level where problems are easy to find the causes for, but also for more complex problems. This gives the employees a good understanding of when to actually contact the upper management, which is very useful to achieve optimal efficiency in a company.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
[https://www.tableau.com/learn/articles/root-cause-analysis [1]] Root Cause Analysis Explained: Definition, Examples, and Methods by Tableau&lt;br /&gt;
&lt;br /&gt;
[https://www.geeksforgeeks.org/basic-principle-of-root-cause-analysis/ [2]] Basic Principle of Root cause analysis by GeeksforGeeks&lt;br /&gt;
&lt;br /&gt;
[https://www.researchgate.net/publication/46567642_Application_Of_Fishbone_Diagram_To_Determine_The_Risk_Of_An_Event_With_Multiple_Causes [3]] Application Of Fishbone Diagram To Determine The Risk Of An Event With Multiple Causes by the UTI Grup SRL and the Academy of Economic Studies&lt;br /&gt;
&lt;br /&gt;
[https://www.ionos.ca/startupguide/productivity/fishbone-diagram/[4]] Fishbone diagram: Solving problems properly by IONOS&lt;br /&gt;
&lt;br /&gt;
[https://www.corship.eu/5-whys-method/ [5]] 5 Whys Method by CORSHIP – CORPORATE EDUPRENEURSHIP&lt;br /&gt;
&lt;br /&gt;
[https://www.adb.org/publications/five-whys-technique [6]] The Five Whys Technique by Olivier Serrat&lt;br /&gt;
&lt;br /&gt;
[https://www.slideshare.net/himanshuhora/pareto-analysis-28873221 [7]]Pareto Analysis by Dr. Himanshu Hora, SRMS College of Engineering &amp;amp; Technology Bareilly&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122464</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122464"/>
		<updated>2022-03-27T18:20:15Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: /* Introduction */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;Developed by William Vossgård&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
==== Abstract ====&lt;br /&gt;
Root Cause Analysis (RCA) is a method of problem solving that can be used in a project, program or portfolio (PPP) to identify root causes of faults and problems in order to find appropriate solutions. It is broadly used in several industries, among the health care, infrastructure and information technology industry. A Root Cause Analysis supposes that it is more effective to go in-depth of occurring problems, so that the underlaying issue can be treated, instead of only treating ad hoc symptoms. Root Cause Analyses can be performed with several different methodologies, principles and techniques together to identify the root causes of a defect or problem. The goal is to find out where processes or systems failed or caused an issue in the first place. In this article, the most common and broadly used techniques will be covered.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
To be able to fully understand what a root cause analysis is and what it is used for, it is easier to relate it to something we are entirely acknowledged with. If your arm hurts considerably after an accident, you will go to the doctor to find the root cause of your pain. Also, if your computer stops working, you will try to find the root cause of its malfunction, either by yourself or by a professional technician. For these examples, a simple remedy could be found for the symptoms. To stop your arm from hurting, you could put ice on it to relive pain. To get work done with a broken computer, you could use your phone or tablet instead. Unfortunately, this would only consider the symptoms, and not the underlaying issue that caused the problem. The injured arm may need surgery to entirely recover from the sustained injury, and the broken computer may need to have a new battery to function again. The best way to solve a fault or problem would therefore be to perform a Root Cause Analysis. By doing this, the exact root cause can be found so that the correct remedy of the fault or problem will be accomplished. There are a number of techniques and strategies that can be used for root cause analyses. In this article, the most commonly and widely used techniques will be covered.&lt;br /&gt;
&lt;br /&gt;
== Conducting a root cause analysis ==&lt;br /&gt;
&lt;br /&gt;
===== Goals and benefits =====&lt;br /&gt;
&lt;br /&gt;
Related to the root cause analysis, there are three goals that should be realised. The first one being to discover the root cause of a failure or problem. The second is to develop an understanding on how to fix and learn from the underlaying issues relating the root cause. The third and final is to apply the findings from the root cause analysis, to systematically prevent future issues or problems. The third goal is especially important as this is what gives the analysis a reason to be performed. Root cause analysis can be used for increasing the productiveness in several core processes as well, with the goal to prevent problems in the future. Instead of replacing punctured bike tires on rental bikes, puncture proof tires could be installed instead if the problem persists [https://www.tableau.com/learn/articles/root-cause-analysis [1]].&lt;br /&gt;
&lt;br /&gt;
===== General principles =====&lt;br /&gt;
&lt;br /&gt;
To achieve an effective root cause analysis process, there are some general principles that should be taken into consideration. These principles will increase the quality of the analysis and will help the analysis get trust from clients and stakeholders [https://www.geeksforgeeks.org/basic-principle-of-root-cause-analysis/[2]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
*Root cause analyses gives the best effect when a team is gathered, to do the analysis together. In particular, it should be done with those employees, who are directly involved in the problem-causing processes.&lt;br /&gt;
*Consider to actually correct and remedy the root causes, not only the symptoms.&lt;br /&gt;
*While performing the root cause analysis, also remember to treat symptoms for short term fixing.&lt;br /&gt;
*Avoid focus on who was responsible of the failure or problem, instead focus on how and why.&lt;br /&gt;
*Find and document ways to prevent similar root causes in the future.&lt;br /&gt;
*When finding root causes, provide cause-effect evidence to back it up.&lt;br /&gt;
*Often there are multiple root causes, therefore search for several.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
As it can be understood from the principles above, it is important to take a comprehensive and holistic approach in this type of analysis. As the root causes have no importance if no action is taken afterwards, it should be strived to provide information and context that can solve the failure or problem.&lt;br /&gt;
&lt;br /&gt;
=== Fishbone Diagram ===&lt;br /&gt;
A Fishbone diagram, which also is called an Ishikawa diagram, is used to identify root causes of quality problems. The fishbone diagram provides an organised way of looking at effects and causes. It can also be referred to as a cause-and-effect diagram. It generally represents a model of indicative presentation for the correlations between an event, which is an effect, and its several causes. This helps the team members get the same understanding of the problem, so that they can think systematically. The root causes of a problem can by using this structured approach be found, while encouraging group participation, utilising group knowledge and identifying areas where data should be collected for future studies. Hence the name, the diagram has the same structure as the skeleton of a fish. While it most often is used in a simple representation, with segments leaning on a horizontal axis, it can also be done with a more extensive approach. An example of this is by naming and coding of the risks which characterises the causes and sub-causes. This consists of elements that show the causes and sub-causes succession with different ways for risk treatment [https://www.researchgate.net/publication/46567642_Application_Of_Fishbone_Diagram_To_Determine_The_Risk_Of_An_Event_With_Multiple_Causes[3]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:A-generic-representation-of-the-Ishikawa-diagram-aka-Fishbone-diagram.png|400px|thumb|centre|Figure 1: Illustration of a Fishbone diagram]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Five steps should be followed to successful use the Fishbone diagram technique [https://www.ionos.ca/startupguide/productivity/fishbone-diagram/[4]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#The first step is to state the problem precisely. This problem statement must be carefully chosen, and it is important that it is specific enough.&lt;br /&gt;
#Define the main influencing factors. This is the factors are put in the horizontal category segments in the fishbone diagram. Different defects or problems have different influencing, which means that these should be chosen after what is relevant. Examples of these is seen in the figure 1.&lt;br /&gt;
#State the causes into the diagram sorted after the different categories. This should be done with those employees that are directly involved in the problem causing processes. Also, the team should consist of a mix of different levels of expertise. When analysing the problem statement and finding causes, further sub-causes can be elaborated upon.&lt;br /&gt;
#Prioritise the causes. In the same team, make each person state their opinion as what is the most serious cause of the defect or problem. After a discussion about the causes, each person can give points to the causes that they believe are the most serious. The causes with the most points, should then be prioritised.&lt;br /&gt;
#Take measures. Tackle the defect or problem by eradicating the cause or causes. I it’s important that it is certain that the correct cause have been identified. To make sure of this, a significance test can be used for verifying, in order to select suitable methods for problem-solving.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== The 5 Whys ===&lt;br /&gt;
The 5 whys is a simple, yet powerful way of finding root causes. It works as an iterative interrogative technique to explore cause-and-effect relationship underlaying a particular problem. It is often used together with the a Fishbone diagram to find the root causes for the causes on the diagram.  As the name of technique implies, the primary goal is to find the root cause of a problem by asking “Why?” five times. Each answer of the “Whys” forms the basis for the next question, and when the fifth “Why?” have been answered, the root cause should be found. Five times is generally enough, but if the root cause still not is found, it could be repeated up to a total of six, seven or higher levels. For problems or defects that do not have one single root cause, the technique must be repeated asking a different sequence of questions each time [https://www.corship.eu/5-whys-method/[5]]. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:5-whys-example (1).png|500px|thumb|right|Figure 2: Example of a 5 whys analysis[https://www.corship.eu/5-whys-method/]]]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The five steps to conduct the 5 whys analysis, is to [https://www.adb.org/publications/five-whys-technique[6]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather a team who can develop a problem statement in agreement. At this point, it should be discussed whether additionally individuals are needed to resolve the problem. &lt;br /&gt;
#Make the team come with statements on “Why is this or that defect or problem taking place?”. This is the first “why” of the analysis. There are most probable multiple statements for this, and they should all be written down.&lt;br /&gt;
#Repeat the same process asking “why” four more times. This should be done for every statement from the first “why” in the structure like figure 2 shows. All plausible answers should be written down. When the “why” does not yield further useful information, you have found the root cause. This means that is sometimes may take more than five layers to find the root cause.&lt;br /&gt;
#Among the many answers to the last asked “why”, look for systematic causes of the defect or problem. This should be discussed in the group to be able to settle for the most likely systematic cause. The product from the team session should then be showed to others to confirm that they see the same logic in the analysis.&lt;br /&gt;
#The last and final step of the 5 why analysis is to develop appropriate corrective actions to remove the root cause from the system. Others can undertake these actions but planning and implementation will benefit from inputs from the team.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===Pareto Chart Analysis===&lt;br /&gt;
[[File:Pareto output.png|400px|thumb|right|Figure 3: The 20/80 principle]]&lt;br /&gt;
The Pareto chart combines a histogram (bar chart) and a line chart, where cost or frequency of defects or problems show their relative importance. Frequencies are shown in the histogram with descending order of the bars, and the line chart shows the totals or the cumulative percentages increasing from left to right. It is based on the Pareto principle, which states that “80% of the effects or consequences come from 20% of the causes”. This is not like the immutable laws of physics but based on continuous observations. On those observations, it has showed to be applicable to many aspects of life and natural phenomena. In relation to a root cause analysis, the Pareto Chart Analysis helps identify the top 20% of the causes that needs to be addressed to resolve 80% of the problems [https://www.slideshare.net/himanshuhora/pareto-analysis-28873221[7]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;In order to perform a Pareto Chart Analysis, the following needs to be done [https://www.slideshare.net/himanshuhora/pareto-analysis-28873221[7]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather and collect data on the frequency of the causes of a defect or problem.&lt;br /&gt;
#Sort the causes after most to least important, and then calculate the cumulative percentage.&lt;br /&gt;
#Plot bars of the causes ordered from most to least frequent on the x-axis, and then plot the cumulative percentages on the y-axis. &lt;br /&gt;
#Finally, separate the 20% most important root causes from the rest by lifting the x-axis to the 80% cumulative percent on the y-axis.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:Pareto-chart-example.png|600px|thumb|left|Figure 4: An example of a Pareto Chart Analysis[https://www.whatissixsigma.net/pareto-chart-and-analysis/]]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Challenges and limitations ==&lt;br /&gt;
&lt;br /&gt;
For the Root Cause Analysis to give results, it is dependent on a larger problem-solving effort to improve the quality in a business. It therefore the managements responsibility to make the best use of the findings from the root cause analyses. The root cause analysis on itself would not provide the correct result. When it comes to the conduction of a root cause analysis, it is hard to fully know if you have taken every root cause into consideration. The reason for this is because there can be multiple root causes, and there is hard to tell when every root cause has been found. This can lead to too much time spent on irrelevant underlaying factors, which result in confusion and a waste of time. The 5 whys and the fishbone analysis does not rely on specific data, which can lead to less reliable results. The management can therefore have trouble entirely trusting these analyses.&lt;br /&gt;
&lt;br /&gt;
==Annotated Bibliography==&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The 5 whys by Olivier Serrat&#039;&#039;&#039;&lt;br /&gt;
The article “The Five Whys Technique” by Olivier Serrat, provides powerful knowledge within the use of the five “why” technique. It provides sufficient information both in relation to the background and meaning of using this technique, but also a step by step guide on how to use it in practice. This is very useful both for current and upcoming managers who will stumble upon a need to use this technique in real life. The article is short, which makes it quick to read. But if there is a need for further knowledge within the subject, reading material of high quality is referred to at the end of the article.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Root Cause Analysis: The Core of Problem Solving and Corrective Action by Duke Okes&#039;&#039;&#039;&lt;br /&gt;
In the book Root Cause Analysis: The Core of Problem Solving and Corrective Action, the author Duke Okes goes in-depth of the importance of using and how to use root cause analyses to catch the actual root causes of problems, and not only the symptoms of them. Different techniques to be implemented into a business are presented in detail so that the management in a company can reduce the amount of reoccurring problems. The terminology in this book is also simpler than most articles and research books, which makes it easy to read for the management.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The Importance of Root Cause Analysis During Incident Investigation by the Occupational Safety and Health Administration (OSHA)&#039;&#039;&#039;&lt;br /&gt;
The factsheet supplied by the OSHA provides a hands-on guidance for conducting root cause analyses in general. Different from most other articles this factsheet provides clear instructions for the whole root cause analysis process, both on a low level where problems are easy to find the causes for, but also for more complex problems. This gives the employees a good understanding of when to actually contact the upper management, which is very useful to achieve optimal efficiency in a company.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
[https://www.tableau.com/learn/articles/root-cause-analysis [1]] Root Cause Analysis Explained: Definition, Examples, and Methods by Tableau&lt;br /&gt;
&lt;br /&gt;
[https://www.geeksforgeeks.org/basic-principle-of-root-cause-analysis/ [2]] Basic Principle of Root cause analysis by GeeksforGeeks&lt;br /&gt;
&lt;br /&gt;
[https://www.researchgate.net/publication/46567642_Application_Of_Fishbone_Diagram_To_Determine_The_Risk_Of_An_Event_With_Multiple_Causes [3]] Application Of Fishbone Diagram To Determine The Risk Of An Event With Multiple Causes by the UTI Grup SRL and the Academy of Economic Studies&lt;br /&gt;
&lt;br /&gt;
[https://www.ionos.ca/startupguide/productivity/fishbone-diagram/[4]] Fishbone diagram: Solving problems properly by IONOS&lt;br /&gt;
&lt;br /&gt;
[https://www.corship.eu/5-whys-method/ [5]] 5 Whys Method by CORSHIP – CORPORATE EDUPRENEURSHIP&lt;br /&gt;
&lt;br /&gt;
[https://www.adb.org/publications/five-whys-technique [6]] The Five Whys Technique by Olivier Serrat&lt;br /&gt;
&lt;br /&gt;
[https://www.slideshare.net/himanshuhora/pareto-analysis-28873221 [7]]Pareto Analysis by Dr. Himanshu Hora, SRMS College of Engineering &amp;amp; Technology Bareilly&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122462</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122462"/>
		<updated>2022-03-27T18:19:14Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: /* Introduction */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;Developed by William Vossgård&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
==== Abstract ====&lt;br /&gt;
Root Cause Analysis (RCA) is a method of problem solving that can be used in a project, program or portfolio (PPP) to identify root causes of faults and problems in order to find appropriate solutions. It is broadly used in several industries, among the health care, infrastructure and information technology industry. A Root Cause Analysis supposes that it is more effective to go in-depth of occurring problems, so that the underlaying issue can be treated, instead of only treating ad hoc symptoms. Root Cause Analyses can be performed with several different methodologies, principles and techniques together to identify the root causes of a defect or problem. The goal is to find out where processes or systems failed or caused an issue in the first place. In this article, the most common and broadly used techniques will be covered.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
To be able to fully understand what a root cause analysis is and what it is used for, it is easier to relate it to something we are entirely acknowledged with. If your arm hurts considerably after an accident, you will go to the doctor to find the root cause of your pain. Also, if your computer stops working, you will try to find the root cause of its malfunction, either by yourself or by a professional technician. For these examples, a simple remedy could be found for the symptoms. To stop your arm from hurting, you could put ice on it to relive pain. To get work done with a broken computer, you could use your phone or tablet instead. Unfortunately, this would only consider the symptoms, and not the underlaying issue that caused the problem. The injured arm may need surgery to entirely recover from the sustained injury, and the broken computer may need to have a new battery to function again. The best way to solve a fault or problem would therefore be to perform a Root Cause Analysis. By doing this, the exact root cause can be found so that the correct management of the fault or problem will be accomplished.&lt;br /&gt;
There are a number of techniques and strategies that can be used for root cause analyses. In this article, the most commonly and widely used techniques will be covered.&lt;br /&gt;
&lt;br /&gt;
== Conducting a root cause analysis ==&lt;br /&gt;
&lt;br /&gt;
===== Goals and benefits =====&lt;br /&gt;
&lt;br /&gt;
Related to the root cause analysis, there are three goals that should be realised. The first one being to discover the root cause of a failure or problem. The second is to develop an understanding on how to fix and learn from the underlaying issues relating the root cause. The third and final is to apply the findings from the root cause analysis, to systematically prevent future issues or problems. The third goal is especially important as this is what gives the analysis a reason to be performed. Root cause analysis can be used for increasing the productiveness in several core processes as well, with the goal to prevent problems in the future. Instead of replacing punctured bike tires on rental bikes, puncture proof tires could be installed instead if the problem persists [https://www.tableau.com/learn/articles/root-cause-analysis [1]].&lt;br /&gt;
&lt;br /&gt;
===== General principles =====&lt;br /&gt;
&lt;br /&gt;
To achieve an effective root cause analysis process, there are some general principles that should be taken into consideration. These principles will increase the quality of the analysis and will help the analysis get trust from clients and stakeholders [https://www.geeksforgeeks.org/basic-principle-of-root-cause-analysis/[2]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
*Root cause analyses gives the best effect when a team is gathered, to do the analysis together. In particular, it should be done with those employees, who are directly involved in the problem-causing processes.&lt;br /&gt;
*Consider to actually correct and remedy the root causes, not only the symptoms.&lt;br /&gt;
*While performing the root cause analysis, also remember to treat symptoms for short term fixing.&lt;br /&gt;
*Avoid focus on who was responsible of the failure or problem, instead focus on how and why.&lt;br /&gt;
*Find and document ways to prevent similar root causes in the future.&lt;br /&gt;
*When finding root causes, provide cause-effect evidence to back it up.&lt;br /&gt;
*Often there are multiple root causes, therefore search for several.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
As it can be understood from the principles above, it is important to take a comprehensive and holistic approach in this type of analysis. As the root causes have no importance if no action is taken afterwards, it should be strived to provide information and context that can solve the failure or problem.&lt;br /&gt;
&lt;br /&gt;
=== Fishbone Diagram ===&lt;br /&gt;
A Fishbone diagram, which also is called an Ishikawa diagram, is used to identify root causes of quality problems. The fishbone diagram provides an organised way of looking at effects and causes. It can also be referred to as a cause-and-effect diagram. It generally represents a model of indicative presentation for the correlations between an event, which is an effect, and its several causes. This helps the team members get the same understanding of the problem, so that they can think systematically. The root causes of a problem can by using this structured approach be found, while encouraging group participation, utilising group knowledge and identifying areas where data should be collected for future studies. Hence the name, the diagram has the same structure as the skeleton of a fish. While it most often is used in a simple representation, with segments leaning on a horizontal axis, it can also be done with a more extensive approach. An example of this is by naming and coding of the risks which characterises the causes and sub-causes. This consists of elements that show the causes and sub-causes succession with different ways for risk treatment [https://www.researchgate.net/publication/46567642_Application_Of_Fishbone_Diagram_To_Determine_The_Risk_Of_An_Event_With_Multiple_Causes[3]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:A-generic-representation-of-the-Ishikawa-diagram-aka-Fishbone-diagram.png|400px|thumb|centre|Figure 1: Illustration of a Fishbone diagram]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Five steps should be followed to successful use the Fishbone diagram technique [https://www.ionos.ca/startupguide/productivity/fishbone-diagram/[4]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#The first step is to state the problem precisely. This problem statement must be carefully chosen, and it is important that it is specific enough.&lt;br /&gt;
#Define the main influencing factors. This is the factors are put in the horizontal category segments in the fishbone diagram. Different defects or problems have different influencing, which means that these should be chosen after what is relevant. Examples of these is seen in the figure 1.&lt;br /&gt;
#State the causes into the diagram sorted after the different categories. This should be done with those employees that are directly involved in the problem causing processes. Also, the team should consist of a mix of different levels of expertise. When analysing the problem statement and finding causes, further sub-causes can be elaborated upon.&lt;br /&gt;
#Prioritise the causes. In the same team, make each person state their opinion as what is the most serious cause of the defect or problem. After a discussion about the causes, each person can give points to the causes that they believe are the most serious. The causes with the most points, should then be prioritised.&lt;br /&gt;
#Take measures. Tackle the defect or problem by eradicating the cause or causes. I it’s important that it is certain that the correct cause have been identified. To make sure of this, a significance test can be used for verifying, in order to select suitable methods for problem-solving.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== The 5 Whys ===&lt;br /&gt;
The 5 whys is a simple, yet powerful way of finding root causes. It works as an iterative interrogative technique to explore cause-and-effect relationship underlaying a particular problem. It is often used together with the a Fishbone diagram to find the root causes for the causes on the diagram.  As the name of technique implies, the primary goal is to find the root cause of a problem by asking “Why?” five times. Each answer of the “Whys” forms the basis for the next question, and when the fifth “Why?” have been answered, the root cause should be found. Five times is generally enough, but if the root cause still not is found, it could be repeated up to a total of six, seven or higher levels. For problems or defects that do not have one single root cause, the technique must be repeated asking a different sequence of questions each time [https://www.corship.eu/5-whys-method/[5]]. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:5-whys-example (1).png|500px|thumb|right|Figure 2: Example of a 5 whys analysis[https://www.corship.eu/5-whys-method/]]]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The five steps to conduct the 5 whys analysis, is to [https://www.adb.org/publications/five-whys-technique[6]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather a team who can develop a problem statement in agreement. At this point, it should be discussed whether additionally individuals are needed to resolve the problem. &lt;br /&gt;
#Make the team come with statements on “Why is this or that defect or problem taking place?”. This is the first “why” of the analysis. There are most probable multiple statements for this, and they should all be written down.&lt;br /&gt;
#Repeat the same process asking “why” four more times. This should be done for every statement from the first “why” in the structure like figure 2 shows. All plausible answers should be written down. When the “why” does not yield further useful information, you have found the root cause. This means that is sometimes may take more than five layers to find the root cause.&lt;br /&gt;
#Among the many answers to the last asked “why”, look for systematic causes of the defect or problem. This should be discussed in the group to be able to settle for the most likely systematic cause. The product from the team session should then be showed to others to confirm that they see the same logic in the analysis.&lt;br /&gt;
#The last and final step of the 5 why analysis is to develop appropriate corrective actions to remove the root cause from the system. Others can undertake these actions but planning and implementation will benefit from inputs from the team.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===Pareto Chart Analysis===&lt;br /&gt;
[[File:Pareto output.png|400px|thumb|right|Figure 3: The 20/80 principle]]&lt;br /&gt;
The Pareto chart combines a histogram (bar chart) and a line chart, where cost or frequency of defects or problems show their relative importance. Frequencies are shown in the histogram with descending order of the bars, and the line chart shows the totals or the cumulative percentages increasing from left to right. It is based on the Pareto principle, which states that “80% of the effects or consequences come from 20% of the causes”. This is not like the immutable laws of physics but based on continuous observations. On those observations, it has showed to be applicable to many aspects of life and natural phenomena. In relation to a root cause analysis, the Pareto Chart Analysis helps identify the top 20% of the causes that needs to be addressed to resolve 80% of the problems [https://www.slideshare.net/himanshuhora/pareto-analysis-28873221[7]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;In order to perform a Pareto Chart Analysis, the following needs to be done [https://www.slideshare.net/himanshuhora/pareto-analysis-28873221[7]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather and collect data on the frequency of the causes of a defect or problem.&lt;br /&gt;
#Sort the causes after most to least important, and then calculate the cumulative percentage.&lt;br /&gt;
#Plot bars of the causes ordered from most to least frequent on the x-axis, and then plot the cumulative percentages on the y-axis. &lt;br /&gt;
#Finally, separate the 20% most important root causes from the rest by lifting the x-axis to the 80% cumulative percent on the y-axis.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:Pareto-chart-example.png|600px|thumb|left|Figure 4: An example of a Pareto Chart Analysis[https://www.whatissixsigma.net/pareto-chart-and-analysis/]]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Challenges and limitations ==&lt;br /&gt;
&lt;br /&gt;
For the Root Cause Analysis to give results, it is dependent on a larger problem-solving effort to improve the quality in a business. It therefore the managements responsibility to make the best use of the findings from the root cause analyses. The root cause analysis on itself would not provide the correct result. When it comes to the conduction of a root cause analysis, it is hard to fully know if you have taken every root cause into consideration. The reason for this is because there can be multiple root causes, and there is hard to tell when every root cause has been found. This can lead to too much time spent on irrelevant underlaying factors, which result in confusion and a waste of time. The 5 whys and the fishbone analysis does not rely on specific data, which can lead to less reliable results. The management can therefore have trouble entirely trusting these analyses.&lt;br /&gt;
&lt;br /&gt;
==Annotated Bibliography==&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The 5 whys by Olivier Serrat&#039;&#039;&#039;&lt;br /&gt;
The article “The Five Whys Technique” by Olivier Serrat, provides powerful knowledge within the use of the five “why” technique. It provides sufficient information both in relation to the background and meaning of using this technique, but also a step by step guide on how to use it in practice. This is very useful both for current and upcoming managers who will stumble upon a need to use this technique in real life. The article is short, which makes it quick to read. But if there is a need for further knowledge within the subject, reading material of high quality is referred to at the end of the article.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Root Cause Analysis: The Core of Problem Solving and Corrective Action by Duke Okes&#039;&#039;&#039;&lt;br /&gt;
In the book Root Cause Analysis: The Core of Problem Solving and Corrective Action, the author Duke Okes goes in-depth of the importance of using and how to use root cause analyses to catch the actual root causes of problems, and not only the symptoms of them. Different techniques to be implemented into a business are presented in detail so that the management in a company can reduce the amount of reoccurring problems. The terminology in this book is also simpler than most articles and research books, which makes it easy to read for the management.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The Importance of Root Cause Analysis During Incident Investigation by the Occupational Safety and Health Administration (OSHA)&#039;&#039;&#039;&lt;br /&gt;
The factsheet supplied by the OSHA provides a hands-on guidance for conducting root cause analyses in general. Different from most other articles this factsheet provides clear instructions for the whole root cause analysis process, both on a low level where problems are easy to find the causes for, but also for more complex problems. This gives the employees a good understanding of when to actually contact the upper management, which is very useful to achieve optimal efficiency in a company.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
[https://www.tableau.com/learn/articles/root-cause-analysis [1]] Root Cause Analysis Explained: Definition, Examples, and Methods by Tableau&lt;br /&gt;
&lt;br /&gt;
[https://www.geeksforgeeks.org/basic-principle-of-root-cause-analysis/ [2]] Basic Principle of Root cause analysis by GeeksforGeeks&lt;br /&gt;
&lt;br /&gt;
[https://www.researchgate.net/publication/46567642_Application_Of_Fishbone_Diagram_To_Determine_The_Risk_Of_An_Event_With_Multiple_Causes [3]] Application Of Fishbone Diagram To Determine The Risk Of An Event With Multiple Causes by the UTI Grup SRL and the Academy of Economic Studies&lt;br /&gt;
&lt;br /&gt;
[https://www.ionos.ca/startupguide/productivity/fishbone-diagram/[4]] Fishbone diagram: Solving problems properly by IONOS&lt;br /&gt;
&lt;br /&gt;
[https://www.corship.eu/5-whys-method/ [5]] 5 Whys Method by CORSHIP – CORPORATE EDUPRENEURSHIP&lt;br /&gt;
&lt;br /&gt;
[https://www.adb.org/publications/five-whys-technique [6]] The Five Whys Technique by Olivier Serrat&lt;br /&gt;
&lt;br /&gt;
[https://www.slideshare.net/himanshuhora/pareto-analysis-28873221 [7]]Pareto Analysis by Dr. Himanshu Hora, SRMS College of Engineering &amp;amp; Technology Bareilly&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122460</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122460"/>
		<updated>2022-03-27T18:17:41Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: /* Abstract */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;Developed by William Vossgård&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
==== Abstract ====&lt;br /&gt;
Root Cause Analysis (RCA) is a method of problem solving that can be used in a project, program or portfolio (PPP) to identify root causes of faults and problems in order to find appropriate solutions. It is broadly used in several industries, among the health care, infrastructure and information technology industry. A Root Cause Analysis supposes that it is more effective to go in-depth of occurring problems, so that the underlaying issue can be treated, instead of only treating ad hoc symptoms. Root Cause Analyses can be performed with several different methodologies, principles and techniques together to identify the root causes of a defect or problem. The goal is to find out where processes or systems failed or caused an issue in the first place. In this article, the most common and broadly used techniques will be covered.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
To be able to fully understand what a root cause analysis is and what it is used for, it is easier to relate it to something we are entirely acknowledged with. If your arm hurts considerably after an accident, you will go to the doctor to find the root cause of your pain. Also, if your computer stops working, you will try to find the root cause of its malfunction, either by yourself or by a professional technician. For these examples, a simple remedy could be found for the symptoms. To stop your arm from hurting, you could put ice on it to relive pain. To get work done with a broken computer, you could use your phone or tablet instead. Unfortunately, this would only consider the symptoms and not the underlaying issue that caused the problem. The injured arm may need surgery to entirely recover from the sustained injury, and the broken computer may need to have a new battery to function again. The best way to solve a fault or problem would therefore be to perform a Root Cause Analysis. By doing this, the exact root cause can be found so that the correct management of the fault or problem will be accomplished.&lt;br /&gt;
There are a number of techniques and strategies that can be used for root cause analyses. In this article, the most commonly and widely used techniques will be covered.&lt;br /&gt;
&lt;br /&gt;
== Conducting a root cause analysis ==&lt;br /&gt;
&lt;br /&gt;
===== Goals and benefits =====&lt;br /&gt;
&lt;br /&gt;
Related to the root cause analysis, there are three goals that should be realised. The first one being to discover the root cause of a failure or problem. The second is to develop an understanding on how to fix and learn from the underlaying issues relating the root cause. The third and final is to apply the findings from the root cause analysis, to systematically prevent future issues or problems. The third goal is especially important as this is what gives the analysis a reason to be performed. Root cause analysis can be used for increasing the productiveness in several core processes as well, with the goal to prevent problems in the future. Instead of replacing punctured bike tires on rental bikes, puncture proof tires could be installed instead if the problem persists [https://www.tableau.com/learn/articles/root-cause-analysis [1]].&lt;br /&gt;
&lt;br /&gt;
===== General principles =====&lt;br /&gt;
&lt;br /&gt;
To achieve an effective root cause analysis process, there are some general principles that should be taken into consideration. These principles will increase the quality of the analysis and will help the analysis get trust from clients and stakeholders [https://www.geeksforgeeks.org/basic-principle-of-root-cause-analysis/[2]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
*Root cause analyses gives the best effect when a team is gathered, to do the analysis together. In particular, it should be done with those employees, who are directly involved in the problem-causing processes.&lt;br /&gt;
*Consider to actually correct and remedy the root causes, not only the symptoms.&lt;br /&gt;
*While performing the root cause analysis, also remember to treat symptoms for short term fixing.&lt;br /&gt;
*Avoid focus on who was responsible of the failure or problem, instead focus on how and why.&lt;br /&gt;
*Find and document ways to prevent similar root causes in the future.&lt;br /&gt;
*When finding root causes, provide cause-effect evidence to back it up.&lt;br /&gt;
*Often there are multiple root causes, therefore search for several.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
As it can be understood from the principles above, it is important to take a comprehensive and holistic approach in this type of analysis. As the root causes have no importance if no action is taken afterwards, it should be strived to provide information and context that can solve the failure or problem.&lt;br /&gt;
&lt;br /&gt;
=== Fishbone Diagram ===&lt;br /&gt;
A Fishbone diagram, which also is called an Ishikawa diagram, is used to identify root causes of quality problems. The fishbone diagram provides an organised way of looking at effects and causes. It can also be referred to as a cause-and-effect diagram. It generally represents a model of indicative presentation for the correlations between an event, which is an effect, and its several causes. This helps the team members get the same understanding of the problem, so that they can think systematically. The root causes of a problem can by using this structured approach be found, while encouraging group participation, utilising group knowledge and identifying areas where data should be collected for future studies. Hence the name, the diagram has the same structure as the skeleton of a fish. While it most often is used in a simple representation, with segments leaning on a horizontal axis, it can also be done with a more extensive approach. An example of this is by naming and coding of the risks which characterises the causes and sub-causes. This consists of elements that show the causes and sub-causes succession with different ways for risk treatment [https://www.researchgate.net/publication/46567642_Application_Of_Fishbone_Diagram_To_Determine_The_Risk_Of_An_Event_With_Multiple_Causes[3]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:A-generic-representation-of-the-Ishikawa-diagram-aka-Fishbone-diagram.png|400px|thumb|centre|Figure 1: Illustration of a Fishbone diagram]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Five steps should be followed to successful use the Fishbone diagram technique [https://www.ionos.ca/startupguide/productivity/fishbone-diagram/[4]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#The first step is to state the problem precisely. This problem statement must be carefully chosen, and it is important that it is specific enough.&lt;br /&gt;
#Define the main influencing factors. This is the factors are put in the horizontal category segments in the fishbone diagram. Different defects or problems have different influencing, which means that these should be chosen after what is relevant. Examples of these is seen in the figure 1.&lt;br /&gt;
#State the causes into the diagram sorted after the different categories. This should be done with those employees that are directly involved in the problem causing processes. Also, the team should consist of a mix of different levels of expertise. When analysing the problem statement and finding causes, further sub-causes can be elaborated upon.&lt;br /&gt;
#Prioritise the causes. In the same team, make each person state their opinion as what is the most serious cause of the defect or problem. After a discussion about the causes, each person can give points to the causes that they believe are the most serious. The causes with the most points, should then be prioritised.&lt;br /&gt;
#Take measures. Tackle the defect or problem by eradicating the cause or causes. I it’s important that it is certain that the correct cause have been identified. To make sure of this, a significance test can be used for verifying, in order to select suitable methods for problem-solving.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== The 5 Whys ===&lt;br /&gt;
The 5 whys is a simple, yet powerful way of finding root causes. It works as an iterative interrogative technique to explore cause-and-effect relationship underlaying a particular problem. It is often used together with the a Fishbone diagram to find the root causes for the causes on the diagram.  As the name of technique implies, the primary goal is to find the root cause of a problem by asking “Why?” five times. Each answer of the “Whys” forms the basis for the next question, and when the fifth “Why?” have been answered, the root cause should be found. Five times is generally enough, but if the root cause still not is found, it could be repeated up to a total of six, seven or higher levels. For problems or defects that do not have one single root cause, the technique must be repeated asking a different sequence of questions each time [https://www.corship.eu/5-whys-method/[5]]. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:5-whys-example (1).png|500px|thumb|right|Figure 2: Example of a 5 whys analysis[https://www.corship.eu/5-whys-method/]]]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The five steps to conduct the 5 whys analysis, is to [https://www.adb.org/publications/five-whys-technique[6]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather a team who can develop a problem statement in agreement. At this point, it should be discussed whether additionally individuals are needed to resolve the problem. &lt;br /&gt;
#Make the team come with statements on “Why is this or that defect or problem taking place?”. This is the first “why” of the analysis. There are most probable multiple statements for this, and they should all be written down.&lt;br /&gt;
#Repeat the same process asking “why” four more times. This should be done for every statement from the first “why” in the structure like figure 2 shows. All plausible answers should be written down. When the “why” does not yield further useful information, you have found the root cause. This means that is sometimes may take more than five layers to find the root cause.&lt;br /&gt;
#Among the many answers to the last asked “why”, look for systematic causes of the defect or problem. This should be discussed in the group to be able to settle for the most likely systematic cause. The product from the team session should then be showed to others to confirm that they see the same logic in the analysis.&lt;br /&gt;
#The last and final step of the 5 why analysis is to develop appropriate corrective actions to remove the root cause from the system. Others can undertake these actions but planning and implementation will benefit from inputs from the team.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===Pareto Chart Analysis===&lt;br /&gt;
[[File:Pareto output.png|400px|thumb|right|Figure 3: The 20/80 principle]]&lt;br /&gt;
The Pareto chart combines a histogram (bar chart) and a line chart, where cost or frequency of defects or problems show their relative importance. Frequencies are shown in the histogram with descending order of the bars, and the line chart shows the totals or the cumulative percentages increasing from left to right. It is based on the Pareto principle, which states that “80% of the effects or consequences come from 20% of the causes”. This is not like the immutable laws of physics but based on continuous observations. On those observations, it has showed to be applicable to many aspects of life and natural phenomena. In relation to a root cause analysis, the Pareto Chart Analysis helps identify the top 20% of the causes that needs to be addressed to resolve 80% of the problems [https://www.slideshare.net/himanshuhora/pareto-analysis-28873221[7]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;In order to perform a Pareto Chart Analysis, the following needs to be done [https://www.slideshare.net/himanshuhora/pareto-analysis-28873221[7]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather and collect data on the frequency of the causes of a defect or problem.&lt;br /&gt;
#Sort the causes after most to least important, and then calculate the cumulative percentage.&lt;br /&gt;
#Plot bars of the causes ordered from most to least frequent on the x-axis, and then plot the cumulative percentages on the y-axis. &lt;br /&gt;
#Finally, separate the 20% most important root causes from the rest by lifting the x-axis to the 80% cumulative percent on the y-axis.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:Pareto-chart-example.png|600px|thumb|left|Figure 4: An example of a Pareto Chart Analysis[https://www.whatissixsigma.net/pareto-chart-and-analysis/]]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Challenges and limitations ==&lt;br /&gt;
&lt;br /&gt;
For the Root Cause Analysis to give results, it is dependent on a larger problem-solving effort to improve the quality in a business. It therefore the managements responsibility to make the best use of the findings from the root cause analyses. The root cause analysis on itself would not provide the correct result. When it comes to the conduction of a root cause analysis, it is hard to fully know if you have taken every root cause into consideration. The reason for this is because there can be multiple root causes, and there is hard to tell when every root cause has been found. This can lead to too much time spent on irrelevant underlaying factors, which result in confusion and a waste of time. The 5 whys and the fishbone analysis does not rely on specific data, which can lead to less reliable results. The management can therefore have trouble entirely trusting these analyses.&lt;br /&gt;
&lt;br /&gt;
==Annotated Bibliography==&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The 5 whys by Olivier Serrat&#039;&#039;&#039;&lt;br /&gt;
The article “The Five Whys Technique” by Olivier Serrat, provides powerful knowledge within the use of the five “why” technique. It provides sufficient information both in relation to the background and meaning of using this technique, but also a step by step guide on how to use it in practice. This is very useful both for current and upcoming managers who will stumble upon a need to use this technique in real life. The article is short, which makes it quick to read. But if there is a need for further knowledge within the subject, reading material of high quality is referred to at the end of the article.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Root Cause Analysis: The Core of Problem Solving and Corrective Action by Duke Okes&#039;&#039;&#039;&lt;br /&gt;
In the book Root Cause Analysis: The Core of Problem Solving and Corrective Action, the author Duke Okes goes in-depth of the importance of using and how to use root cause analyses to catch the actual root causes of problems, and not only the symptoms of them. Different techniques to be implemented into a business are presented in detail so that the management in a company can reduce the amount of reoccurring problems. The terminology in this book is also simpler than most articles and research books, which makes it easy to read for the management.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The Importance of Root Cause Analysis During Incident Investigation by the Occupational Safety and Health Administration (OSHA)&#039;&#039;&#039;&lt;br /&gt;
The factsheet supplied by the OSHA provides a hands-on guidance for conducting root cause analyses in general. Different from most other articles this factsheet provides clear instructions for the whole root cause analysis process, both on a low level where problems are easy to find the causes for, but also for more complex problems. This gives the employees a good understanding of when to actually contact the upper management, which is very useful to achieve optimal efficiency in a company.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
[https://www.tableau.com/learn/articles/root-cause-analysis [1]] Root Cause Analysis Explained: Definition, Examples, and Methods by Tableau&lt;br /&gt;
&lt;br /&gt;
[https://www.geeksforgeeks.org/basic-principle-of-root-cause-analysis/ [2]] Basic Principle of Root cause analysis by GeeksforGeeks&lt;br /&gt;
&lt;br /&gt;
[https://www.researchgate.net/publication/46567642_Application_Of_Fishbone_Diagram_To_Determine_The_Risk_Of_An_Event_With_Multiple_Causes [3]] Application Of Fishbone Diagram To Determine The Risk Of An Event With Multiple Causes by the UTI Grup SRL and the Academy of Economic Studies&lt;br /&gt;
&lt;br /&gt;
[https://www.ionos.ca/startupguide/productivity/fishbone-diagram/[4]] Fishbone diagram: Solving problems properly by IONOS&lt;br /&gt;
&lt;br /&gt;
[https://www.corship.eu/5-whys-method/ [5]] 5 Whys Method by CORSHIP – CORPORATE EDUPRENEURSHIP&lt;br /&gt;
&lt;br /&gt;
[https://www.adb.org/publications/five-whys-technique [6]] The Five Whys Technique by Olivier Serrat&lt;br /&gt;
&lt;br /&gt;
[https://www.slideshare.net/himanshuhora/pareto-analysis-28873221 [7]]Pareto Analysis by Dr. Himanshu Hora, SRMS College of Engineering &amp;amp; Technology Bareilly&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122456</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122456"/>
		<updated>2022-03-27T18:17:06Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;Developed by William Vossgård&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
==== Abstract ====&lt;br /&gt;
Root Cause Analysis (RCA) is a method of problem solving that can be used in a project, program or portfolio (PPP) to identify root causes of faults and problems in order to identify appropriate solutions. It is broadly used in several industries, among the health care, infrastructure and information technology industry. A Root Cause Analysis supposes that it is more effective to go in-depth of occurring problems, so that the underlaying issue can be treated, instead of only treating ad hoc symptoms. Root Cause Analyses can be performed with several different methodologies, principles and techniques together to identify the root causes of a defect or problem. The goal is to find out where processes or systems failed or caused an issue in the first place. In this article, the most common and broadly used techniques will be covered.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
To be able to fully understand what a root cause analysis is and what it is used for, it is easier to relate it to something we are entirely acknowledged with. If your arm hurts considerably after an accident, you will go to the doctor to find the root cause of your pain. Also, if your computer stops working, you will try to find the root cause of its malfunction, either by yourself or by a professional technician. For these examples, a simple remedy could be found for the symptoms. To stop your arm from hurting, you could put ice on it to relive pain. To get work done with a broken computer, you could use your phone or tablet instead. Unfortunately, this would only consider the symptoms and not the underlaying issue that caused the problem. The injured arm may need surgery to entirely recover from the sustained injury, and the broken computer may need to have a new battery to function again. The best way to solve a fault or problem would therefore be to perform a Root Cause Analysis. By doing this, the exact root cause can be found so that the correct management of the fault or problem will be accomplished.&lt;br /&gt;
There are a number of techniques and strategies that can be used for root cause analyses. In this article, the most commonly and widely used techniques will be covered.&lt;br /&gt;
&lt;br /&gt;
== Conducting a root cause analysis ==&lt;br /&gt;
&lt;br /&gt;
===== Goals and benefits =====&lt;br /&gt;
&lt;br /&gt;
Related to the root cause analysis, there are three goals that should be realised. The first one being to discover the root cause of a failure or problem. The second is to develop an understanding on how to fix and learn from the underlaying issues relating the root cause. The third and final is to apply the findings from the root cause analysis, to systematically prevent future issues or problems. The third goal is especially important as this is what gives the analysis a reason to be performed. Root cause analysis can be used for increasing the productiveness in several core processes as well, with the goal to prevent problems in the future. Instead of replacing punctured bike tires on rental bikes, puncture proof tires could be installed instead if the problem persists [https://www.tableau.com/learn/articles/root-cause-analysis [1]].&lt;br /&gt;
&lt;br /&gt;
===== General principles =====&lt;br /&gt;
&lt;br /&gt;
To achieve an effective root cause analysis process, there are some general principles that should be taken into consideration. These principles will increase the quality of the analysis and will help the analysis get trust from clients and stakeholders [https://www.geeksforgeeks.org/basic-principle-of-root-cause-analysis/[2]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
*Root cause analyses gives the best effect when a team is gathered, to do the analysis together. In particular, it should be done with those employees, who are directly involved in the problem-causing processes.&lt;br /&gt;
*Consider to actually correct and remedy the root causes, not only the symptoms.&lt;br /&gt;
*While performing the root cause analysis, also remember to treat symptoms for short term fixing.&lt;br /&gt;
*Avoid focus on who was responsible of the failure or problem, instead focus on how and why.&lt;br /&gt;
*Find and document ways to prevent similar root causes in the future.&lt;br /&gt;
*When finding root causes, provide cause-effect evidence to back it up.&lt;br /&gt;
*Often there are multiple root causes, therefore search for several.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
As it can be understood from the principles above, it is important to take a comprehensive and holistic approach in this type of analysis. As the root causes have no importance if no action is taken afterwards, it should be strived to provide information and context that can solve the failure or problem.&lt;br /&gt;
&lt;br /&gt;
=== Fishbone Diagram ===&lt;br /&gt;
A Fishbone diagram, which also is called an Ishikawa diagram, is used to identify root causes of quality problems. The fishbone diagram provides an organised way of looking at effects and causes. It can also be referred to as a cause-and-effect diagram. It generally represents a model of indicative presentation for the correlations between an event, which is an effect, and its several causes. This helps the team members get the same understanding of the problem, so that they can think systematically. The root causes of a problem can by using this structured approach be found, while encouraging group participation, utilising group knowledge and identifying areas where data should be collected for future studies. Hence the name, the diagram has the same structure as the skeleton of a fish. While it most often is used in a simple representation, with segments leaning on a horizontal axis, it can also be done with a more extensive approach. An example of this is by naming and coding of the risks which characterises the causes and sub-causes. This consists of elements that show the causes and sub-causes succession with different ways for risk treatment [https://www.researchgate.net/publication/46567642_Application_Of_Fishbone_Diagram_To_Determine_The_Risk_Of_An_Event_With_Multiple_Causes[3]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:A-generic-representation-of-the-Ishikawa-diagram-aka-Fishbone-diagram.png|400px|thumb|centre|Figure 1: Illustration of a Fishbone diagram]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Five steps should be followed to successful use the Fishbone diagram technique [https://www.ionos.ca/startupguide/productivity/fishbone-diagram/[4]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#The first step is to state the problem precisely. This problem statement must be carefully chosen, and it is important that it is specific enough.&lt;br /&gt;
#Define the main influencing factors. This is the factors are put in the horizontal category segments in the fishbone diagram. Different defects or problems have different influencing, which means that these should be chosen after what is relevant. Examples of these is seen in the figure 1.&lt;br /&gt;
#State the causes into the diagram sorted after the different categories. This should be done with those employees that are directly involved in the problem causing processes. Also, the team should consist of a mix of different levels of expertise. When analysing the problem statement and finding causes, further sub-causes can be elaborated upon.&lt;br /&gt;
#Prioritise the causes. In the same team, make each person state their opinion as what is the most serious cause of the defect or problem. After a discussion about the causes, each person can give points to the causes that they believe are the most serious. The causes with the most points, should then be prioritised.&lt;br /&gt;
#Take measures. Tackle the defect or problem by eradicating the cause or causes. I it’s important that it is certain that the correct cause have been identified. To make sure of this, a significance test can be used for verifying, in order to select suitable methods for problem-solving.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== The 5 Whys ===&lt;br /&gt;
The 5 whys is a simple, yet powerful way of finding root causes. It works as an iterative interrogative technique to explore cause-and-effect relationship underlaying a particular problem. It is often used together with the a Fishbone diagram to find the root causes for the causes on the diagram.  As the name of technique implies, the primary goal is to find the root cause of a problem by asking “Why?” five times. Each answer of the “Whys” forms the basis for the next question, and when the fifth “Why?” have been answered, the root cause should be found. Five times is generally enough, but if the root cause still not is found, it could be repeated up to a total of six, seven or higher levels. For problems or defects that do not have one single root cause, the technique must be repeated asking a different sequence of questions each time [https://www.corship.eu/5-whys-method/[5]]. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:5-whys-example (1).png|500px|thumb|right|Figure 2: Example of a 5 whys analysis[https://www.corship.eu/5-whys-method/]]]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The five steps to conduct the 5 whys analysis, is to [https://www.adb.org/publications/five-whys-technique[6]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather a team who can develop a problem statement in agreement. At this point, it should be discussed whether additionally individuals are needed to resolve the problem. &lt;br /&gt;
#Make the team come with statements on “Why is this or that defect or problem taking place?”. This is the first “why” of the analysis. There are most probable multiple statements for this, and they should all be written down.&lt;br /&gt;
#Repeat the same process asking “why” four more times. This should be done for every statement from the first “why” in the structure like figure 2 shows. All plausible answers should be written down. When the “why” does not yield further useful information, you have found the root cause. This means that is sometimes may take more than five layers to find the root cause.&lt;br /&gt;
#Among the many answers to the last asked “why”, look for systematic causes of the defect or problem. This should be discussed in the group to be able to settle for the most likely systematic cause. The product from the team session should then be showed to others to confirm that they see the same logic in the analysis.&lt;br /&gt;
#The last and final step of the 5 why analysis is to develop appropriate corrective actions to remove the root cause from the system. Others can undertake these actions but planning and implementation will benefit from inputs from the team.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===Pareto Chart Analysis===&lt;br /&gt;
[[File:Pareto output.png|400px|thumb|right|Figure 3: The 20/80 principle]]&lt;br /&gt;
The Pareto chart combines a histogram (bar chart) and a line chart, where cost or frequency of defects or problems show their relative importance. Frequencies are shown in the histogram with descending order of the bars, and the line chart shows the totals or the cumulative percentages increasing from left to right. It is based on the Pareto principle, which states that “80% of the effects or consequences come from 20% of the causes”. This is not like the immutable laws of physics but based on continuous observations. On those observations, it has showed to be applicable to many aspects of life and natural phenomena. In relation to a root cause analysis, the Pareto Chart Analysis helps identify the top 20% of the causes that needs to be addressed to resolve 80% of the problems [https://www.slideshare.net/himanshuhora/pareto-analysis-28873221[7]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;In order to perform a Pareto Chart Analysis, the following needs to be done [https://www.slideshare.net/himanshuhora/pareto-analysis-28873221[7]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather and collect data on the frequency of the causes of a defect or problem.&lt;br /&gt;
#Sort the causes after most to least important, and then calculate the cumulative percentage.&lt;br /&gt;
#Plot bars of the causes ordered from most to least frequent on the x-axis, and then plot the cumulative percentages on the y-axis. &lt;br /&gt;
#Finally, separate the 20% most important root causes from the rest by lifting the x-axis to the 80% cumulative percent on the y-axis.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:Pareto-chart-example.png|600px|thumb|left|Figure 4: An example of a Pareto Chart Analysis[https://www.whatissixsigma.net/pareto-chart-and-analysis/]]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Challenges and limitations ==&lt;br /&gt;
&lt;br /&gt;
For the Root Cause Analysis to give results, it is dependent on a larger problem-solving effort to improve the quality in a business. It therefore the managements responsibility to make the best use of the findings from the root cause analyses. The root cause analysis on itself would not provide the correct result. When it comes to the conduction of a root cause analysis, it is hard to fully know if you have taken every root cause into consideration. The reason for this is because there can be multiple root causes, and there is hard to tell when every root cause has been found. This can lead to too much time spent on irrelevant underlaying factors, which result in confusion and a waste of time. The 5 whys and the fishbone analysis does not rely on specific data, which can lead to less reliable results. The management can therefore have trouble entirely trusting these analyses.&lt;br /&gt;
&lt;br /&gt;
==Annotated Bibliography==&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The 5 whys by Olivier Serrat&#039;&#039;&#039;&lt;br /&gt;
The article “The Five Whys Technique” by Olivier Serrat, provides powerful knowledge within the use of the five “why” technique. It provides sufficient information both in relation to the background and meaning of using this technique, but also a step by step guide on how to use it in practice. This is very useful both for current and upcoming managers who will stumble upon a need to use this technique in real life. The article is short, which makes it quick to read. But if there is a need for further knowledge within the subject, reading material of high quality is referred to at the end of the article.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Root Cause Analysis: The Core of Problem Solving and Corrective Action by Duke Okes&#039;&#039;&#039;&lt;br /&gt;
In the book Root Cause Analysis: The Core of Problem Solving and Corrective Action, the author Duke Okes goes in-depth of the importance of using and how to use root cause analyses to catch the actual root causes of problems, and not only the symptoms of them. Different techniques to be implemented into a business are presented in detail so that the management in a company can reduce the amount of reoccurring problems. The terminology in this book is also simpler than most articles and research books, which makes it easy to read for the management.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The Importance of Root Cause Analysis During Incident Investigation by the Occupational Safety and Health Administration (OSHA)&#039;&#039;&#039;&lt;br /&gt;
The factsheet supplied by the OSHA provides a hands-on guidance for conducting root cause analyses in general. Different from most other articles this factsheet provides clear instructions for the whole root cause analysis process, both on a low level where problems are easy to find the causes for, but also for more complex problems. This gives the employees a good understanding of when to actually contact the upper management, which is very useful to achieve optimal efficiency in a company.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
[https://www.tableau.com/learn/articles/root-cause-analysis [1]] Root Cause Analysis Explained: Definition, Examples, and Methods by Tableau&lt;br /&gt;
&lt;br /&gt;
[https://www.geeksforgeeks.org/basic-principle-of-root-cause-analysis/ [2]] Basic Principle of Root cause analysis by GeeksforGeeks&lt;br /&gt;
&lt;br /&gt;
[https://www.researchgate.net/publication/46567642_Application_Of_Fishbone_Diagram_To_Determine_The_Risk_Of_An_Event_With_Multiple_Causes [3]] Application Of Fishbone Diagram To Determine The Risk Of An Event With Multiple Causes by the UTI Grup SRL and the Academy of Economic Studies&lt;br /&gt;
&lt;br /&gt;
[https://www.ionos.ca/startupguide/productivity/fishbone-diagram/[4]] Fishbone diagram: Solving problems properly by IONOS&lt;br /&gt;
&lt;br /&gt;
[https://www.corship.eu/5-whys-method/ [5]] 5 Whys Method by CORSHIP – CORPORATE EDUPRENEURSHIP&lt;br /&gt;
&lt;br /&gt;
[https://www.adb.org/publications/five-whys-technique [6]] The Five Whys Technique by Olivier Serrat&lt;br /&gt;
&lt;br /&gt;
[https://www.slideshare.net/himanshuhora/pareto-analysis-28873221 [7]]Pareto Analysis by Dr. Himanshu Hora, SRMS College of Engineering &amp;amp; Technology Bareilly&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122448</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122448"/>
		<updated>2022-03-27T18:14:14Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: /* Challenges and limitations */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;Developed by William Vossgård&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
==== Abstract ====&lt;br /&gt;
Root Cause Analysis (RCA) is a method of problem solving that can be used in a project, program or portfolio (PPP) to identify root causes of faults and problems in order to identify appropriate solutions. It is broadly used in several industries, among the health care, infrastructure and information technology industry. A Root Cause Analysis supposes that it is more effective to go in-depth of occurring problems, so that the underlaying issue can be treated, instead of only treating ad hoc symptoms. Root Cause Analyses can be performed with several different methodologies, principles and techniques together to identify the root causes of a defect or problem. The goal is to find out where processes or systems failed or caused an issue in the first place. In this article, the most common and broadly used techniques will be covered.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
To be able to fully understand what a root cause analysis is and what it is used for, it is easier to relate it to something we are entirely acknowledged with. If your arm hurts considerably after an accident, you will go to the doctor to find the root cause of your pain. Also, if your computer stops working, you will try to find the root cause of its malfunction, either by yourself or by a professional technician. For these examples, a simple remedy could be found for the symptoms. To stop your arm from hurting, you could put ice on it to relive pain. To get work done with a broken computer, you could use your phone or tablet instead. Unfortunately, this would only consider the symptoms and not the underlaying issue that caused the problem. The injured arm may need surgery to entirely recover from the sustained injury, and the broken computer may need to have a new battery to function again. The best way to solve a fault or problem would therefore be to perform a Root Cause Analysis. By doing this, the exact root cause can be found so that the correct management of the fault or problem will be accomplished.&lt;br /&gt;
There are a number of techniques and strategies that can be used for root cause analyses. In this article, the most commonly and widely used techniques will be covered.&lt;br /&gt;
&lt;br /&gt;
== Conducting a root cause analysis ==&lt;br /&gt;
&lt;br /&gt;
===== Goals and benefits =====&lt;br /&gt;
&lt;br /&gt;
Related to the root cause analysis, there are three goals that should be realised. The first one being to discover the root cause of a failure or problem. The second is to develop an understanding on how to fix and learn from the underlaying issues relating the root cause. The third and final is to apply the findings from the root cause analysis, to systematically prevent future issues or problems. The third goal is especially important as this is what gives the analysis a reason to be performed. Root cause analysis can be used for increasing the productiveness in several core processes as well, with the goal to prevent problems in the future. Instead of replacing punctured bike tires on rental bikes, puncture proof tires could be installed instead if the problem persists [https://www.tableau.com/learn/articles/root-cause-analysis [1]].&lt;br /&gt;
&lt;br /&gt;
===== General principles =====&lt;br /&gt;
&lt;br /&gt;
To achieve an effective root cause analysis process, there are some general principles that should be taken into consideration. These principles will increase the quality of the analysis and will help the analysis get trust from clients and stakeholders [https://www.geeksforgeeks.org/basic-principle-of-root-cause-analysis/[2]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
*Root cause analyses gives the best effect when a team is gathered, to do the analysis together. In particular, it should be done with those employees, who are directly involved in the problem-causing processes.&lt;br /&gt;
*Consider to actually correct and remedy the root causes, not only the symptoms.&lt;br /&gt;
*While performing the root cause analysis, also remember to treat symptoms for short term fixing.&lt;br /&gt;
*Avoid focus on who was responsible of the failure or problem, instead focus on how and why.&lt;br /&gt;
*Find and document ways to prevent similar root causes in the future.&lt;br /&gt;
*When finding root causes, provide cause-effect evidence to back it up.&lt;br /&gt;
*Often there are multiple root causes, therefore search for several.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
As it can be understood from the principles above, it is important to take a comprehensive and holistic approach in this type of analysis. As the root causes have no importance if no action is taken afterwards, it should be strived to provide information and context that can solve the failure or problem.&lt;br /&gt;
&lt;br /&gt;
=== Fishbone Diagram ===&lt;br /&gt;
A Fishbone diagram, which also is called an Ishikawa diagram, is used to identify root causes of quality problems. The fishbone diagram provides an organised way of looking at effects and causes. It can also be referred to as a cause-and-effect diagram. It generally represents a model of indicative presentation for the correlations between an event, which is an effect, and its several causes. This helps the team members get the same understanding of the problem, so that they can think systematically. The root causes of a problem can by using this structured approach be found, while encouraging group participation, utilising group knowledge and identifying areas where data should be collected for future studies. Hence the name, the diagram has the same structure as the skeleton of a fish. While it most often is used in a simple representation, with segments leaning on a horizontal axis, it can also be done with a more extensive approach. An example of this is by naming and coding of the risks which characterises the causes and sub-causes. This consists of elements that show the causes and sub-causes succession with different ways for risk treatment [https://www.researchgate.net/publication/46567642_Application_Of_Fishbone_Diagram_To_Determine_The_Risk_Of_An_Event_With_Multiple_Causes[3]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:A-generic-representation-of-the-Ishikawa-diagram-aka-Fishbone-diagram.png|400px|thumb|centre|Figure 1: Illustration of a Fishbone diagram]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Five steps should be followed to successful use the Fishbone diagram technique [https://www.ionos.ca/startupguide/productivity/fishbone-diagram/[4]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#The first step is to state the problem precisely. This problem statement must be carefully chosen, and it is important that it is specific enough.&lt;br /&gt;
#Define the main influencing factors. This is the factors are put in the horizontal category segments in the fishbone diagram. Different defects or problems have different influencing, which means that these should be chosen after what is relevant. Examples of these is seen in the figure 1.&lt;br /&gt;
#State the causes into the diagram sorted after the different categories. This should be done with those employees that are directly involved in the problem causing processes. Also, the team should consist of a mix of different levels of expertise. When analysing the problem statement and finding causes, further sub-causes can be elaborated upon.&lt;br /&gt;
#Prioritise the causes. In the same team, make each person state their opinion as what is the most serious cause of the defect or problem. After a discussion about the causes, each person can give points to the causes that they believe are the most serious. The causes with the most points, should then be prioritised.&lt;br /&gt;
#Take measures. Tackle the defect or problem by eradicating the cause or causes. I it’s important that it is certain that the correct cause have been identified. To make sure of this, a significance test can be used for verifying, in order to select suitable methods for problem-solving.&lt;br /&gt;
&lt;br /&gt;
=== The 5 Whys ===&lt;br /&gt;
The 5 whys is a simple, yet powerful way of finding root causes. It works as an iterative interrogative technique to explore cause-and-effect relationship underlaying a particular problem. It is often used together with the a Fishbone diagram to find the root causes for the causes on the diagram.  As the name of technique implies, the primary goal is to find the root cause of a problem by asking “Why?” five times. Each answer of the “Whys” forms the basis for the next question, and when the fifth “Why?” have been answered, the root cause should be found. Five times is generally enough, but if the root cause still not is found, it could be repeated up to a total of six, seven or higher levels. For problems or defects that do not have one single root cause, the technique must be repeated asking a different sequence of questions each time [https://www.corship.eu/5-whys-method/[5]]. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:5-whys-example (1).png|500px|thumb|right|Figure 2: Example of a 5 whys analysis[https://www.corship.eu/5-whys-method/]]]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The five steps to conduct the 5 whys analysis, is to [https://www.adb.org/publications/five-whys-technique[6]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather a team who can develop a problem statement in agreement. At this point, it should be discussed whether additionally individuals are needed to resolve the problem. &lt;br /&gt;
#Make the team come with statements on “Why is this or that defect or problem taking place?”. This is the first “why” of the analysis. There are most probable multiple statements for this, and they should all be written down.&lt;br /&gt;
#Repeat the same process asking “why” four more times. This should be done for every statement from the first “why” in the structure like figure 2 shows. All plausible answers should be written down. When the “why” does not yield further useful information, you have found the root cause. This means that is sometimes may take more than five layers to find the root cause.&lt;br /&gt;
#Among the many answers to the last asked “why”, look for systematic causes of the defect or problem. This should be discussed in the group to be able to settle for the most likely systematic cause. The product from the team session should then be showed to others to confirm that they see the same logic in the analysis.&lt;br /&gt;
#The last and final step of the 5 why analysis is to develop appropriate corrective actions to remove the root cause from the system. Others can undertake these actions but planning and implementation will benefit from inputs from the team.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===Pareto Chart Analysis===&lt;br /&gt;
[[File:Pareto output.png|400px|thumb|right|Figure 3: The 20/80 principle]]&lt;br /&gt;
The Pareto chart combines a histogram (bar chart) and a line chart, where cost or frequency of defects or problems show their relative importance. Frequencies are shown in the histogram with descending order of the bars, and the line chart shows the totals or the cumulative percentages increasing from left to right. It is based on the Pareto principle, which states that “80% of the effects or consequences come from 20% of the causes”. This is not like the immutable laws of physics but based on continuous observations. On those observations, it has showed to be applicable to many aspects of life and natural phenomena. In relation to a root cause analysis, the Pareto Chart Analysis helps identify the top 20% of the causes that needs to be addressed to resolve 80% of the problems [https://www.slideshare.net/himanshuhora/pareto-analysis-28873221[7]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;In order to perform a Pareto Chart Analysis, the following needs to be done [https://www.slideshare.net/himanshuhora/pareto-analysis-28873221[7]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather and collect data on the frequency of the causes of a defect or problem.&lt;br /&gt;
#Sort the causes after most to least important, and then calculate the cumulative percentage.&lt;br /&gt;
#Plot bars of the causes ordered from most to least frequent on the x-axis, and then plot the cumulative percentages on the y-axis. &lt;br /&gt;
#Finally, separate the 20% most important root causes from the rest by lifting the x-axis to the 80% cumulative percent on the y-axis.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:Pareto-chart-example.png|600px|thumb|left|Figure 4: An example of a Pareto Chart Analysis[https://www.whatissixsigma.net/pareto-chart-and-analysis/]]]&lt;br /&gt;
&lt;br /&gt;
== Challenges and limitations ==&lt;br /&gt;
&lt;br /&gt;
For the Root Cause Analysis to give results, it is dependent on a larger problem-solving effort to improve the quality in a business. It therefore the managements responsibility to make the best use of the findings from the root cause analyses. The root cause analysis on itself would not provide the correct result. When it comes to the conduction of a root cause analysis, it is hard to fully know if you have taken every root cause into consideration. The reason for this is because there can be multiple root causes, and there is hard to tell when every root cause has been found. This can lead to too much time spent on irrelevant underlaying factors, which result in confusion and a waste of time. The 5 whys and the fishbone analysis does not rely on specific data, which can lead to less reliable results. The management can therefore have trouble entirely trusting these analyses.&lt;br /&gt;
&lt;br /&gt;
==Annotated Bibliography==&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The 5 whys by Olivier Serrat&#039;&#039;&#039;&lt;br /&gt;
The article “The Five Whys Technique” by Olivier Serrat, provides powerful knowledge within the use of the five “why” technique. It provides sufficient information both in relation to the background and meaning of using this technique, but also a step by step guide on how to use it in practice. This is very useful both for current and upcoming managers who will stumble upon a need to use this technique in real life. The article is short, which makes it quick to read. But if there is a need for further knowledge within the subject, reading material of high quality is referred to at the end of the article.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Root Cause Analysis: The Core of Problem Solving and Corrective Action by Duke Okes&#039;&#039;&#039;&lt;br /&gt;
In the book Root Cause Analysis: The Core of Problem Solving and Corrective Action, the author Duke Okes goes in-depth of the importance of using and how to use root cause analyses to catch the actual root causes of problems, and not only the symptoms of them. Different techniques to be implemented into a business are presented in detail so that the management in a company can reduce the amount of reoccurring problems. The terminology in this book is also simpler than most articles and research books, which makes it easy to read for the management.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The Importance of Root Cause Analysis During Incident Investigation by the Occupational Safety and Health Administration (OSHA)&#039;&#039;&#039;&lt;br /&gt;
The factsheet supplied by the OSHA provides a hands-on guidance for conducting root cause analyses in general. Different from most other articles this factsheet provides clear instructions for the whole root cause analysis process, both on a low level where problems are easy to find the causes for, but also for more complex problems. This gives the employees a good understanding of when to actually contact the upper management, which is very useful to achieve optimal efficiency in a company.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
[https://www.tableau.com/learn/articles/root-cause-analysis [1]] Root Cause Analysis Explained: Definition, Examples, and Methods by Tableau&lt;br /&gt;
&lt;br /&gt;
[https://www.geeksforgeeks.org/basic-principle-of-root-cause-analysis/ [2]] Basic Principle of Root cause analysis by GeeksforGeeks&lt;br /&gt;
&lt;br /&gt;
[https://www.researchgate.net/publication/46567642_Application_Of_Fishbone_Diagram_To_Determine_The_Risk_Of_An_Event_With_Multiple_Causes [3]] Application Of Fishbone Diagram To Determine The Risk Of An Event With Multiple Causes by the UTI Grup SRL and the Academy of Economic Studies&lt;br /&gt;
&lt;br /&gt;
[https://www.ionos.ca/startupguide/productivity/fishbone-diagram/[4]] Fishbone diagram: Solving problems properly by IONOS&lt;br /&gt;
&lt;br /&gt;
[https://www.corship.eu/5-whys-method/ [5]] 5 Whys Method by CORSHIP – CORPORATE EDUPRENEURSHIP&lt;br /&gt;
&lt;br /&gt;
[https://www.adb.org/publications/five-whys-technique [6]] The Five Whys Technique by Olivier Serrat&lt;br /&gt;
&lt;br /&gt;
[https://www.slideshare.net/himanshuhora/pareto-analysis-28873221 [7]]Pareto Analysis by Dr. Himanshu Hora, SRMS College of Engineering &amp;amp; Technology Bareilly&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122446</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122446"/>
		<updated>2022-03-27T18:13:39Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: /* Conducting a root cause analysis */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;Developed by William Vossgård&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
==== Abstract ====&lt;br /&gt;
Root Cause Analysis (RCA) is a method of problem solving that can be used in a project, program or portfolio (PPP) to identify root causes of faults and problems in order to identify appropriate solutions. It is broadly used in several industries, among the health care, infrastructure and information technology industry. A Root Cause Analysis supposes that it is more effective to go in-depth of occurring problems, so that the underlaying issue can be treated, instead of only treating ad hoc symptoms. Root Cause Analyses can be performed with several different methodologies, principles and techniques together to identify the root causes of a defect or problem. The goal is to find out where processes or systems failed or caused an issue in the first place. In this article, the most common and broadly used techniques will be covered.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
To be able to fully understand what a root cause analysis is and what it is used for, it is easier to relate it to something we are entirely acknowledged with. If your arm hurts considerably after an accident, you will go to the doctor to find the root cause of your pain. Also, if your computer stops working, you will try to find the root cause of its malfunction, either by yourself or by a professional technician. For these examples, a simple remedy could be found for the symptoms. To stop your arm from hurting, you could put ice on it to relive pain. To get work done with a broken computer, you could use your phone or tablet instead. Unfortunately, this would only consider the symptoms and not the underlaying issue that caused the problem. The injured arm may need surgery to entirely recover from the sustained injury, and the broken computer may need to have a new battery to function again. The best way to solve a fault or problem would therefore be to perform a Root Cause Analysis. By doing this, the exact root cause can be found so that the correct management of the fault or problem will be accomplished.&lt;br /&gt;
There are a number of techniques and strategies that can be used for root cause analyses. In this article, the most commonly and widely used techniques will be covered.&lt;br /&gt;
&lt;br /&gt;
== Conducting a root cause analysis ==&lt;br /&gt;
&lt;br /&gt;
===== Goals and benefits =====&lt;br /&gt;
&lt;br /&gt;
Related to the root cause analysis, there are three goals that should be realised. The first one being to discover the root cause of a failure or problem. The second is to develop an understanding on how to fix and learn from the underlaying issues relating the root cause. The third and final is to apply the findings from the root cause analysis, to systematically prevent future issues or problems. The third goal is especially important as this is what gives the analysis a reason to be performed. Root cause analysis can be used for increasing the productiveness in several core processes as well, with the goal to prevent problems in the future. Instead of replacing punctured bike tires on rental bikes, puncture proof tires could be installed instead if the problem persists [https://www.tableau.com/learn/articles/root-cause-analysis [1]].&lt;br /&gt;
&lt;br /&gt;
===== General principles =====&lt;br /&gt;
&lt;br /&gt;
To achieve an effective root cause analysis process, there are some general principles that should be taken into consideration. These principles will increase the quality of the analysis and will help the analysis get trust from clients and stakeholders [https://www.geeksforgeeks.org/basic-principle-of-root-cause-analysis/[2]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
*Root cause analyses gives the best effect when a team is gathered, to do the analysis together. In particular, it should be done with those employees, who are directly involved in the problem-causing processes.&lt;br /&gt;
*Consider to actually correct and remedy the root causes, not only the symptoms.&lt;br /&gt;
*While performing the root cause analysis, also remember to treat symptoms for short term fixing.&lt;br /&gt;
*Avoid focus on who was responsible of the failure or problem, instead focus on how and why.&lt;br /&gt;
*Find and document ways to prevent similar root causes in the future.&lt;br /&gt;
*When finding root causes, provide cause-effect evidence to back it up.&lt;br /&gt;
*Often there are multiple root causes, therefore search for several.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
As it can be understood from the principles above, it is important to take a comprehensive and holistic approach in this type of analysis. As the root causes have no importance if no action is taken afterwards, it should be strived to provide information and context that can solve the failure or problem.&lt;br /&gt;
&lt;br /&gt;
=== Fishbone Diagram ===&lt;br /&gt;
A Fishbone diagram, which also is called an Ishikawa diagram, is used to identify root causes of quality problems. The fishbone diagram provides an organised way of looking at effects and causes. It can also be referred to as a cause-and-effect diagram. It generally represents a model of indicative presentation for the correlations between an event, which is an effect, and its several causes. This helps the team members get the same understanding of the problem, so that they can think systematically. The root causes of a problem can by using this structured approach be found, while encouraging group participation, utilising group knowledge and identifying areas where data should be collected for future studies. Hence the name, the diagram has the same structure as the skeleton of a fish. While it most often is used in a simple representation, with segments leaning on a horizontal axis, it can also be done with a more extensive approach. An example of this is by naming and coding of the risks which characterises the causes and sub-causes. This consists of elements that show the causes and sub-causes succession with different ways for risk treatment [https://www.researchgate.net/publication/46567642_Application_Of_Fishbone_Diagram_To_Determine_The_Risk_Of_An_Event_With_Multiple_Causes[3]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:A-generic-representation-of-the-Ishikawa-diagram-aka-Fishbone-diagram.png|400px|thumb|centre|Figure 1: Illustration of a Fishbone diagram]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Five steps should be followed to successful use the Fishbone diagram technique [https://www.ionos.ca/startupguide/productivity/fishbone-diagram/[4]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#The first step is to state the problem precisely. This problem statement must be carefully chosen, and it is important that it is specific enough.&lt;br /&gt;
#Define the main influencing factors. This is the factors are put in the horizontal category segments in the fishbone diagram. Different defects or problems have different influencing, which means that these should be chosen after what is relevant. Examples of these is seen in the figure 1.&lt;br /&gt;
#State the causes into the diagram sorted after the different categories. This should be done with those employees that are directly involved in the problem causing processes. Also, the team should consist of a mix of different levels of expertise. When analysing the problem statement and finding causes, further sub-causes can be elaborated upon.&lt;br /&gt;
#Prioritise the causes. In the same team, make each person state their opinion as what is the most serious cause of the defect or problem. After a discussion about the causes, each person can give points to the causes that they believe are the most serious. The causes with the most points, should then be prioritised.&lt;br /&gt;
#Take measures. Tackle the defect or problem by eradicating the cause or causes. I it’s important that it is certain that the correct cause have been identified. To make sure of this, a significance test can be used for verifying, in order to select suitable methods for problem-solving.&lt;br /&gt;
&lt;br /&gt;
=== The 5 Whys ===&lt;br /&gt;
The 5 whys is a simple, yet powerful way of finding root causes. It works as an iterative interrogative technique to explore cause-and-effect relationship underlaying a particular problem. It is often used together with the a Fishbone diagram to find the root causes for the causes on the diagram.  As the name of technique implies, the primary goal is to find the root cause of a problem by asking “Why?” five times. Each answer of the “Whys” forms the basis for the next question, and when the fifth “Why?” have been answered, the root cause should be found. Five times is generally enough, but if the root cause still not is found, it could be repeated up to a total of six, seven or higher levels. For problems or defects that do not have one single root cause, the technique must be repeated asking a different sequence of questions each time [https://www.corship.eu/5-whys-method/[5]]. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:5-whys-example (1).png|500px|thumb|right|Figure 2: Example of a 5 whys analysis[https://www.corship.eu/5-whys-method/]]]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The five steps to conduct the 5 whys analysis, is to [https://www.adb.org/publications/five-whys-technique[6]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather a team who can develop a problem statement in agreement. At this point, it should be discussed whether additionally individuals are needed to resolve the problem. &lt;br /&gt;
#Make the team come with statements on “Why is this or that defect or problem taking place?”. This is the first “why” of the analysis. There are most probable multiple statements for this, and they should all be written down.&lt;br /&gt;
#Repeat the same process asking “why” four more times. This should be done for every statement from the first “why” in the structure like figure 2 shows. All plausible answers should be written down. When the “why” does not yield further useful information, you have found the root cause. This means that is sometimes may take more than five layers to find the root cause.&lt;br /&gt;
#Among the many answers to the last asked “why”, look for systematic causes of the defect or problem. This should be discussed in the group to be able to settle for the most likely systematic cause. The product from the team session should then be showed to others to confirm that they see the same logic in the analysis.&lt;br /&gt;
#The last and final step of the 5 why analysis is to develop appropriate corrective actions to remove the root cause from the system. Others can undertake these actions but planning and implementation will benefit from inputs from the team.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===Pareto Chart Analysis===&lt;br /&gt;
[[File:Pareto output.png|400px|thumb|right|Figure 3: The 20/80 principle]]&lt;br /&gt;
The Pareto chart combines a histogram (bar chart) and a line chart, where cost or frequency of defects or problems show their relative importance. Frequencies are shown in the histogram with descending order of the bars, and the line chart shows the totals or the cumulative percentages increasing from left to right. It is based on the Pareto principle, which states that “80% of the effects or consequences come from 20% of the causes”. This is not like the immutable laws of physics but based on continuous observations. On those observations, it has showed to be applicable to many aspects of life and natural phenomena. In relation to a root cause analysis, the Pareto Chart Analysis helps identify the top 20% of the causes that needs to be addressed to resolve 80% of the problems [https://www.slideshare.net/himanshuhora/pareto-analysis-28873221[7]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;In order to perform a Pareto Chart Analysis, the following needs to be done [https://www.slideshare.net/himanshuhora/pareto-analysis-28873221[7]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather and collect data on the frequency of the causes of a defect or problem.&lt;br /&gt;
#Sort the causes after most to least important, and then calculate the cumulative percentage.&lt;br /&gt;
#Plot bars of the causes ordered from most to least frequent on the x-axis, and then plot the cumulative percentages on the y-axis. &lt;br /&gt;
#Finally, separate the 20% most important root causes from the rest by lifting the x-axis to the 80% cumulative percent on the y-axis.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:Pareto-chart-example.png|600px|thumb|left|Figure 4: An example of a Pareto Chart Analysis[https://www.whatissixsigma.net/pareto-chart-and-analysis/]]]&lt;br /&gt;
&lt;br /&gt;
== Challenges and limitations ==&lt;br /&gt;
&lt;br /&gt;
For the Root Cause Analysis to give results, it is dependent on a larger problem-solving effort to improve the quality in a business. It therefore the managements responsibility to make the best use of the findings from the root cause analyses. The root cause analysis on itself would not provide the correct result. When it comes to the conduction of a root cause analysis, it is hard to fully know if you have taken every root cause into consideration. The reason for this is because there can be multiple root causes, and there is hard to tell when every root cause has been found. This can lead to too much time spent on irrelevant underlaying factors, which result in confusion and a waste of time. The 5 whys and the fishbone analysis does not rely on specific data, which can lead to less reliable results. The management can therefore have trouble entirely trusting these analyses. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Annotated Bibliography==&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The 5 whys by Olivier Serrat&#039;&#039;&#039;&lt;br /&gt;
The article “The Five Whys Technique” by Olivier Serrat, provides powerful knowledge within the use of the five “why” technique. It provides sufficient information both in relation to the background and meaning of using this technique, but also a step by step guide on how to use it in practice. This is very useful both for current and upcoming managers who will stumble upon a need to use this technique in real life. The article is short, which makes it quick to read. But if there is a need for further knowledge within the subject, reading material of high quality is referred to at the end of the article.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Root Cause Analysis: The Core of Problem Solving and Corrective Action by Duke Okes&#039;&#039;&#039;&lt;br /&gt;
In the book Root Cause Analysis: The Core of Problem Solving and Corrective Action, the author Duke Okes goes in-depth of the importance of using and how to use root cause analyses to catch the actual root causes of problems, and not only the symptoms of them. Different techniques to be implemented into a business are presented in detail so that the management in a company can reduce the amount of reoccurring problems. The terminology in this book is also simpler than most articles and research books, which makes it easy to read for the management.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The Importance of Root Cause Analysis During Incident Investigation by the Occupational Safety and Health Administration (OSHA)&#039;&#039;&#039;&lt;br /&gt;
The factsheet supplied by the OSHA provides a hands-on guidance for conducting root cause analyses in general. Different from most other articles this factsheet provides clear instructions for the whole root cause analysis process, both on a low level where problems are easy to find the causes for, but also for more complex problems. This gives the employees a good understanding of when to actually contact the upper management, which is very useful to achieve optimal efficiency in a company.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
[https://www.tableau.com/learn/articles/root-cause-analysis [1]] Root Cause Analysis Explained: Definition, Examples, and Methods by Tableau&lt;br /&gt;
&lt;br /&gt;
[https://www.geeksforgeeks.org/basic-principle-of-root-cause-analysis/ [2]] Basic Principle of Root cause analysis by GeeksforGeeks&lt;br /&gt;
&lt;br /&gt;
[https://www.researchgate.net/publication/46567642_Application_Of_Fishbone_Diagram_To_Determine_The_Risk_Of_An_Event_With_Multiple_Causes [3]] Application Of Fishbone Diagram To Determine The Risk Of An Event With Multiple Causes by the UTI Grup SRL and the Academy of Economic Studies&lt;br /&gt;
&lt;br /&gt;
[https://www.ionos.ca/startupguide/productivity/fishbone-diagram/[4]] Fishbone diagram: Solving problems properly by IONOS&lt;br /&gt;
&lt;br /&gt;
[https://www.corship.eu/5-whys-method/ [5]] 5 Whys Method by CORSHIP – CORPORATE EDUPRENEURSHIP&lt;br /&gt;
&lt;br /&gt;
[https://www.adb.org/publications/five-whys-technique [6]] The Five Whys Technique by Olivier Serrat&lt;br /&gt;
&lt;br /&gt;
[https://www.slideshare.net/himanshuhora/pareto-analysis-28873221 [7]]Pareto Analysis by Dr. Himanshu Hora, SRMS College of Engineering &amp;amp; Technology Bareilly&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122445</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122445"/>
		<updated>2022-03-27T18:13:23Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: /* General principles */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;Developed by William Vossgård&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
==== Abstract ====&lt;br /&gt;
Root Cause Analysis (RCA) is a method of problem solving that can be used in a project, program or portfolio (PPP) to identify root causes of faults and problems in order to identify appropriate solutions. It is broadly used in several industries, among the health care, infrastructure and information technology industry. A Root Cause Analysis supposes that it is more effective to go in-depth of occurring problems, so that the underlaying issue can be treated, instead of only treating ad hoc symptoms. Root Cause Analyses can be performed with several different methodologies, principles and techniques together to identify the root causes of a defect or problem. The goal is to find out where processes or systems failed or caused an issue in the first place. In this article, the most common and broadly used techniques will be covered.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
To be able to fully understand what a root cause analysis is and what it is used for, it is easier to relate it to something we are entirely acknowledged with. If your arm hurts considerably after an accident, you will go to the doctor to find the root cause of your pain. Also, if your computer stops working, you will try to find the root cause of its malfunction, either by yourself or by a professional technician. For these examples, a simple remedy could be found for the symptoms. To stop your arm from hurting, you could put ice on it to relive pain. To get work done with a broken computer, you could use your phone or tablet instead. Unfortunately, this would only consider the symptoms and not the underlaying issue that caused the problem. The injured arm may need surgery to entirely recover from the sustained injury, and the broken computer may need to have a new battery to function again. The best way to solve a fault or problem would therefore be to perform a Root Cause Analysis. By doing this, the exact root cause can be found so that the correct management of the fault or problem will be accomplished.&lt;br /&gt;
There are a number of techniques and strategies that can be used for root cause analyses. In this article, the most commonly and widely used techniques will be covered.&lt;br /&gt;
&lt;br /&gt;
== Conducting a root cause analysis ==&lt;br /&gt;
&lt;br /&gt;
There is not one specific way of performing a root cause analysis as there are many different techniques and strategies that can be used. In this chapter, the most common and broadly used techniques will be covered. Root cause analyses gives the best effect when a team is gathered, to do the analysis together. In particular, it should be done with those employees, who are directly involved in the problem-causing processes.&lt;br /&gt;
&lt;br /&gt;
===== Goals and benefits =====&lt;br /&gt;
&lt;br /&gt;
Related to the root cause analysis, there are three goals that should be realised. The first one being to discover the root cause of a failure or problem. The second is to develop an understanding on how to fix and learn from the underlaying issues relating the root cause. The third and final is to apply the findings from the root cause analysis, to systematically prevent future issues or problems. The third goal is especially important as this is what gives the analysis a reason to be performed. Root cause analysis can be used for increasing the productiveness in several core processes as well, with the goal to prevent problems in the future. Instead of replacing punctured bike tires on rental bikes, puncture proof tires could be installed instead if the problem persists [https://www.tableau.com/learn/articles/root-cause-analysis [1]].&lt;br /&gt;
&lt;br /&gt;
===== General principles =====&lt;br /&gt;
&lt;br /&gt;
To achieve an effective root cause analysis process, there are some general principles that should be taken into consideration. These principles will increase the quality of the analysis and will help the analysis get trust from clients and stakeholders [https://www.geeksforgeeks.org/basic-principle-of-root-cause-analysis/[2]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
*Root cause analyses gives the best effect when a team is gathered, to do the analysis together. In particular, it should be done with those employees, who are directly involved in the problem-causing processes.&lt;br /&gt;
*Consider to actually correct and remedy the root causes, not only the symptoms.&lt;br /&gt;
*While performing the root cause analysis, also remember to treat symptoms for short term fixing.&lt;br /&gt;
*Avoid focus on who was responsible of the failure or problem, instead focus on how and why.&lt;br /&gt;
*Find and document ways to prevent similar root causes in the future.&lt;br /&gt;
*When finding root causes, provide cause-effect evidence to back it up.&lt;br /&gt;
*Often there are multiple root causes, therefore search for several.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
As it can be understood from the principles above, it is important to take a comprehensive and holistic approach in this type of analysis. As the root causes have no importance if no action is taken afterwards, it should be strived to provide information and context that can solve the failure or problem.&lt;br /&gt;
&lt;br /&gt;
=== Fishbone Diagram ===&lt;br /&gt;
A Fishbone diagram, which also is called an Ishikawa diagram, is used to identify root causes of quality problems. The fishbone diagram provides an organised way of looking at effects and causes. It can also be referred to as a cause-and-effect diagram. It generally represents a model of indicative presentation for the correlations between an event, which is an effect, and its several causes. This helps the team members get the same understanding of the problem, so that they can think systematically. The root causes of a problem can by using this structured approach be found, while encouraging group participation, utilising group knowledge and identifying areas where data should be collected for future studies. Hence the name, the diagram has the same structure as the skeleton of a fish. While it most often is used in a simple representation, with segments leaning on a horizontal axis, it can also be done with a more extensive approach. An example of this is by naming and coding of the risks which characterises the causes and sub-causes. This consists of elements that show the causes and sub-causes succession with different ways for risk treatment [https://www.researchgate.net/publication/46567642_Application_Of_Fishbone_Diagram_To_Determine_The_Risk_Of_An_Event_With_Multiple_Causes[3]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:A-generic-representation-of-the-Ishikawa-diagram-aka-Fishbone-diagram.png|400px|thumb|centre|Figure 1: Illustration of a Fishbone diagram]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Five steps should be followed to successful use the Fishbone diagram technique [https://www.ionos.ca/startupguide/productivity/fishbone-diagram/[4]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#The first step is to state the problem precisely. This problem statement must be carefully chosen, and it is important that it is specific enough.&lt;br /&gt;
#Define the main influencing factors. This is the factors are put in the horizontal category segments in the fishbone diagram. Different defects or problems have different influencing, which means that these should be chosen after what is relevant. Examples of these is seen in the figure 1.&lt;br /&gt;
#State the causes into the diagram sorted after the different categories. This should be done with those employees that are directly involved in the problem causing processes. Also, the team should consist of a mix of different levels of expertise. When analysing the problem statement and finding causes, further sub-causes can be elaborated upon.&lt;br /&gt;
#Prioritise the causes. In the same team, make each person state their opinion as what is the most serious cause of the defect or problem. After a discussion about the causes, each person can give points to the causes that they believe are the most serious. The causes with the most points, should then be prioritised.&lt;br /&gt;
#Take measures. Tackle the defect or problem by eradicating the cause or causes. I it’s important that it is certain that the correct cause have been identified. To make sure of this, a significance test can be used for verifying, in order to select suitable methods for problem-solving.&lt;br /&gt;
&lt;br /&gt;
=== The 5 Whys ===&lt;br /&gt;
The 5 whys is a simple, yet powerful way of finding root causes. It works as an iterative interrogative technique to explore cause-and-effect relationship underlaying a particular problem. It is often used together with the a Fishbone diagram to find the root causes for the causes on the diagram.  As the name of technique implies, the primary goal is to find the root cause of a problem by asking “Why?” five times. Each answer of the “Whys” forms the basis for the next question, and when the fifth “Why?” have been answered, the root cause should be found. Five times is generally enough, but if the root cause still not is found, it could be repeated up to a total of six, seven or higher levels. For problems or defects that do not have one single root cause, the technique must be repeated asking a different sequence of questions each time [https://www.corship.eu/5-whys-method/[5]]. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:5-whys-example (1).png|500px|thumb|right|Figure 2: Example of a 5 whys analysis[https://www.corship.eu/5-whys-method/]]]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The five steps to conduct the 5 whys analysis, is to [https://www.adb.org/publications/five-whys-technique[6]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather a team who can develop a problem statement in agreement. At this point, it should be discussed whether additionally individuals are needed to resolve the problem. &lt;br /&gt;
#Make the team come with statements on “Why is this or that defect or problem taking place?”. This is the first “why” of the analysis. There are most probable multiple statements for this, and they should all be written down.&lt;br /&gt;
#Repeat the same process asking “why” four more times. This should be done for every statement from the first “why” in the structure like figure 2 shows. All plausible answers should be written down. When the “why” does not yield further useful information, you have found the root cause. This means that is sometimes may take more than five layers to find the root cause.&lt;br /&gt;
#Among the many answers to the last asked “why”, look for systematic causes of the defect or problem. This should be discussed in the group to be able to settle for the most likely systematic cause. The product from the team session should then be showed to others to confirm that they see the same logic in the analysis.&lt;br /&gt;
#The last and final step of the 5 why analysis is to develop appropriate corrective actions to remove the root cause from the system. Others can undertake these actions but planning and implementation will benefit from inputs from the team.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===Pareto Chart Analysis===&lt;br /&gt;
[[File:Pareto output.png|400px|thumb|right|Figure 3: The 20/80 principle]]&lt;br /&gt;
The Pareto chart combines a histogram (bar chart) and a line chart, where cost or frequency of defects or problems show their relative importance. Frequencies are shown in the histogram with descending order of the bars, and the line chart shows the totals or the cumulative percentages increasing from left to right. It is based on the Pareto principle, which states that “80% of the effects or consequences come from 20% of the causes”. This is not like the immutable laws of physics but based on continuous observations. On those observations, it has showed to be applicable to many aspects of life and natural phenomena. In relation to a root cause analysis, the Pareto Chart Analysis helps identify the top 20% of the causes that needs to be addressed to resolve 80% of the problems [https://www.slideshare.net/himanshuhora/pareto-analysis-28873221[7]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;In order to perform a Pareto Chart Analysis, the following needs to be done [https://www.slideshare.net/himanshuhora/pareto-analysis-28873221[7]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather and collect data on the frequency of the causes of a defect or problem.&lt;br /&gt;
#Sort the causes after most to least important, and then calculate the cumulative percentage.&lt;br /&gt;
#Plot bars of the causes ordered from most to least frequent on the x-axis, and then plot the cumulative percentages on the y-axis. &lt;br /&gt;
#Finally, separate the 20% most important root causes from the rest by lifting the x-axis to the 80% cumulative percent on the y-axis.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:Pareto-chart-example.png|600px|thumb|left|Figure 4: An example of a Pareto Chart Analysis[https://www.whatissixsigma.net/pareto-chart-and-analysis/]]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Challenges and limitations ==&lt;br /&gt;
&lt;br /&gt;
For the Root Cause Analysis to give results, it is dependent on a larger problem-solving effort to improve the quality in a business. It therefore the managements responsibility to make the best use of the findings from the root cause analyses. The root cause analysis on itself would not provide the correct result. When it comes to the conduction of a root cause analysis, it is hard to fully know if you have taken every root cause into consideration. The reason for this is because there can be multiple root causes, and there is hard to tell when every root cause has been found. This can lead to too much time spent on irrelevant underlaying factors, which result in confusion and a waste of time. The 5 whys and the fishbone analysis does not rely on specific data, which can lead to less reliable results. The management can therefore have trouble entirely trusting these analyses. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Annotated Bibliography==&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The 5 whys by Olivier Serrat&#039;&#039;&#039;&lt;br /&gt;
The article “The Five Whys Technique” by Olivier Serrat, provides powerful knowledge within the use of the five “why” technique. It provides sufficient information both in relation to the background and meaning of using this technique, but also a step by step guide on how to use it in practice. This is very useful both for current and upcoming managers who will stumble upon a need to use this technique in real life. The article is short, which makes it quick to read. But if there is a need for further knowledge within the subject, reading material of high quality is referred to at the end of the article.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Root Cause Analysis: The Core of Problem Solving and Corrective Action by Duke Okes&#039;&#039;&#039;&lt;br /&gt;
In the book Root Cause Analysis: The Core of Problem Solving and Corrective Action, the author Duke Okes goes in-depth of the importance of using and how to use root cause analyses to catch the actual root causes of problems, and not only the symptoms of them. Different techniques to be implemented into a business are presented in detail so that the management in a company can reduce the amount of reoccurring problems. The terminology in this book is also simpler than most articles and research books, which makes it easy to read for the management.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The Importance of Root Cause Analysis During Incident Investigation by the Occupational Safety and Health Administration (OSHA)&#039;&#039;&#039;&lt;br /&gt;
The factsheet supplied by the OSHA provides a hands-on guidance for conducting root cause analyses in general. Different from most other articles this factsheet provides clear instructions for the whole root cause analysis process, both on a low level where problems are easy to find the causes for, but also for more complex problems. This gives the employees a good understanding of when to actually contact the upper management, which is very useful to achieve optimal efficiency in a company.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
[https://www.tableau.com/learn/articles/root-cause-analysis [1]] Root Cause Analysis Explained: Definition, Examples, and Methods by Tableau&lt;br /&gt;
&lt;br /&gt;
[https://www.geeksforgeeks.org/basic-principle-of-root-cause-analysis/ [2]] Basic Principle of Root cause analysis by GeeksforGeeks&lt;br /&gt;
&lt;br /&gt;
[https://www.researchgate.net/publication/46567642_Application_Of_Fishbone_Diagram_To_Determine_The_Risk_Of_An_Event_With_Multiple_Causes [3]] Application Of Fishbone Diagram To Determine The Risk Of An Event With Multiple Causes by the UTI Grup SRL and the Academy of Economic Studies&lt;br /&gt;
&lt;br /&gt;
[https://www.ionos.ca/startupguide/productivity/fishbone-diagram/[4]] Fishbone diagram: Solving problems properly by IONOS&lt;br /&gt;
&lt;br /&gt;
[https://www.corship.eu/5-whys-method/ [5]] 5 Whys Method by CORSHIP – CORPORATE EDUPRENEURSHIP&lt;br /&gt;
&lt;br /&gt;
[https://www.adb.org/publications/five-whys-technique [6]] The Five Whys Technique by Olivier Serrat&lt;br /&gt;
&lt;br /&gt;
[https://www.slideshare.net/himanshuhora/pareto-analysis-28873221 [7]]Pareto Analysis by Dr. Himanshu Hora, SRMS College of Engineering &amp;amp; Technology Bareilly&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122444</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122444"/>
		<updated>2022-03-27T18:12:45Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: /* Abstract */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;Developed by William Vossgård&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
==== Abstract ====&lt;br /&gt;
Root Cause Analysis (RCA) is a method of problem solving that can be used in a project, program or portfolio (PPP) to identify root causes of faults and problems in order to identify appropriate solutions. It is broadly used in several industries, among the health care, infrastructure and information technology industry. A Root Cause Analysis supposes that it is more effective to go in-depth of occurring problems, so that the underlaying issue can be treated, instead of only treating ad hoc symptoms. Root Cause Analyses can be performed with several different methodologies, principles and techniques together to identify the root causes of a defect or problem. The goal is to find out where processes or systems failed or caused an issue in the first place. In this article, the most common and broadly used techniques will be covered.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
To be able to fully understand what a root cause analysis is and what it is used for, it is easier to relate it to something we are entirely acknowledged with. If your arm hurts considerably after an accident, you will go to the doctor to find the root cause of your pain. Also, if your computer stops working, you will try to find the root cause of its malfunction, either by yourself or by a professional technician. For these examples, a simple remedy could be found for the symptoms. To stop your arm from hurting, you could put ice on it to relive pain. To get work done with a broken computer, you could use your phone or tablet instead. Unfortunately, this would only consider the symptoms and not the underlaying issue that caused the problem. The injured arm may need surgery to entirely recover from the sustained injury, and the broken computer may need to have a new battery to function again. The best way to solve a fault or problem would therefore be to perform a Root Cause Analysis. By doing this, the exact root cause can be found so that the correct management of the fault or problem will be accomplished.&lt;br /&gt;
There are a number of techniques and strategies that can be used for root cause analyses. In this article, the most commonly and widely used techniques will be covered.&lt;br /&gt;
&lt;br /&gt;
== Conducting a root cause analysis ==&lt;br /&gt;
&lt;br /&gt;
There is not one specific way of performing a root cause analysis as there are many different techniques and strategies that can be used. In this chapter, the most common and broadly used techniques will be covered. Root cause analyses gives the best effect when a team is gathered, to do the analysis together. In particular, it should be done with those employees, who are directly involved in the problem-causing processes.&lt;br /&gt;
&lt;br /&gt;
===== Goals and benefits =====&lt;br /&gt;
&lt;br /&gt;
Related to the root cause analysis, there are three goals that should be realised. The first one being to discover the root cause of a failure or problem. The second is to develop an understanding on how to fix and learn from the underlaying issues relating the root cause. The third and final is to apply the findings from the root cause analysis, to systematically prevent future issues or problems. The third goal is especially important as this is what gives the analysis a reason to be performed. Root cause analysis can be used for increasing the productiveness in several core processes as well, with the goal to prevent problems in the future. Instead of replacing punctured bike tires on rental bikes, puncture proof tires could be installed instead if the problem persists [https://www.tableau.com/learn/articles/root-cause-analysis [1]].&lt;br /&gt;
&lt;br /&gt;
===== General principles =====&lt;br /&gt;
&lt;br /&gt;
To achieve an effective root cause analysis process, there are some general principles that should be taken into consideration. These principles will increase the quality of the analysis and will help the analysis get trust from clients and stakeholders [https://www.geeksforgeeks.org/basic-principle-of-root-cause-analysis/[2]].&lt;br /&gt;
&lt;br /&gt;
*Consider to actually correct and remedy the root causes, not only the symptoms.&lt;br /&gt;
*While performing the root cause analysis, also remember to treat symptoms for short term fixing.&lt;br /&gt;
*Avoid focus on who was responsible of the failure or problem, instead focus on how and why.&lt;br /&gt;
*Find and document ways to prevent similar root causes in the future.&lt;br /&gt;
*When finding root causes, provide cause-effect evidence to back it up.&lt;br /&gt;
*Often there are multiple root causes, therefore search for several.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
As it can be understood from the principles above, it is important to take a comprehensive and holistic approach in this type of analysis. As the root causes have no importance if no action is taken afterwards, it should be strived to provide information and context that can solve the failure or problem.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Fishbone Diagram ===&lt;br /&gt;
A Fishbone diagram, which also is called an Ishikawa diagram, is used to identify root causes of quality problems. The fishbone diagram provides an organised way of looking at effects and causes. It can also be referred to as a cause-and-effect diagram. It generally represents a model of indicative presentation for the correlations between an event, which is an effect, and its several causes. This helps the team members get the same understanding of the problem, so that they can think systematically. The root causes of a problem can by using this structured approach be found, while encouraging group participation, utilising group knowledge and identifying areas where data should be collected for future studies. Hence the name, the diagram has the same structure as the skeleton of a fish. While it most often is used in a simple representation, with segments leaning on a horizontal axis, it can also be done with a more extensive approach. An example of this is by naming and coding of the risks which characterises the causes and sub-causes. This consists of elements that show the causes and sub-causes succession with different ways for risk treatment [https://www.researchgate.net/publication/46567642_Application_Of_Fishbone_Diagram_To_Determine_The_Risk_Of_An_Event_With_Multiple_Causes[3]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:A-generic-representation-of-the-Ishikawa-diagram-aka-Fishbone-diagram.png|400px|thumb|centre|Figure 1: Illustration of a Fishbone diagram]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Five steps should be followed to successful use the Fishbone diagram technique [https://www.ionos.ca/startupguide/productivity/fishbone-diagram/[4]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#The first step is to state the problem precisely. This problem statement must be carefully chosen, and it is important that it is specific enough.&lt;br /&gt;
#Define the main influencing factors. This is the factors are put in the horizontal category segments in the fishbone diagram. Different defects or problems have different influencing, which means that these should be chosen after what is relevant. Examples of these is seen in the figure 1.&lt;br /&gt;
#State the causes into the diagram sorted after the different categories. This should be done with those employees that are directly involved in the problem causing processes. Also, the team should consist of a mix of different levels of expertise. When analysing the problem statement and finding causes, further sub-causes can be elaborated upon.&lt;br /&gt;
#Prioritise the causes. In the same team, make each person state their opinion as what is the most serious cause of the defect or problem. After a discussion about the causes, each person can give points to the causes that they believe are the most serious. The causes with the most points, should then be prioritised.&lt;br /&gt;
#Take measures. Tackle the defect or problem by eradicating the cause or causes. I it’s important that it is certain that the correct cause have been identified. To make sure of this, a significance test can be used for verifying, in order to select suitable methods for problem-solving.&lt;br /&gt;
&lt;br /&gt;
=== The 5 Whys ===&lt;br /&gt;
The 5 whys is a simple, yet powerful way of finding root causes. It works as an iterative interrogative technique to explore cause-and-effect relationship underlaying a particular problem. It is often used together with the a Fishbone diagram to find the root causes for the causes on the diagram.  As the name of technique implies, the primary goal is to find the root cause of a problem by asking “Why?” five times. Each answer of the “Whys” forms the basis for the next question, and when the fifth “Why?” have been answered, the root cause should be found. Five times is generally enough, but if the root cause still not is found, it could be repeated up to a total of six, seven or higher levels. For problems or defects that do not have one single root cause, the technique must be repeated asking a different sequence of questions each time [https://www.corship.eu/5-whys-method/[5]]. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:5-whys-example (1).png|500px|thumb|right|Figure 2: Example of a 5 whys analysis[https://www.corship.eu/5-whys-method/]]]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The five steps to conduct the 5 whys analysis, is to [https://www.adb.org/publications/five-whys-technique[6]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather a team who can develop a problem statement in agreement. At this point, it should be discussed whether additionally individuals are needed to resolve the problem. &lt;br /&gt;
#Make the team come with statements on “Why is this or that defect or problem taking place?”. This is the first “why” of the analysis. There are most probable multiple statements for this, and they should all be written down.&lt;br /&gt;
#Repeat the same process asking “why” four more times. This should be done for every statement from the first “why” in the structure like figure 2 shows. All plausible answers should be written down. When the “why” does not yield further useful information, you have found the root cause. This means that is sometimes may take more than five layers to find the root cause.&lt;br /&gt;
#Among the many answers to the last asked “why”, look for systematic causes of the defect or problem. This should be discussed in the group to be able to settle for the most likely systematic cause. The product from the team session should then be showed to others to confirm that they see the same logic in the analysis.&lt;br /&gt;
#The last and final step of the 5 why analysis is to develop appropriate corrective actions to remove the root cause from the system. Others can undertake these actions but planning and implementation will benefit from inputs from the team.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===Pareto Chart Analysis===&lt;br /&gt;
[[File:Pareto output.png|400px|thumb|right|Figure 3: The 20/80 principle]]&lt;br /&gt;
The Pareto chart combines a histogram (bar chart) and a line chart, where cost or frequency of defects or problems show their relative importance. Frequencies are shown in the histogram with descending order of the bars, and the line chart shows the totals or the cumulative percentages increasing from left to right. It is based on the Pareto principle, which states that “80% of the effects or consequences come from 20% of the causes”. This is not like the immutable laws of physics but based on continuous observations. On those observations, it has showed to be applicable to many aspects of life and natural phenomena. In relation to a root cause analysis, the Pareto Chart Analysis helps identify the top 20% of the causes that needs to be addressed to resolve 80% of the problems [https://www.slideshare.net/himanshuhora/pareto-analysis-28873221[7]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;In order to perform a Pareto Chart Analysis, the following needs to be done [https://www.slideshare.net/himanshuhora/pareto-analysis-28873221[7]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather and collect data on the frequency of the causes of a defect or problem.&lt;br /&gt;
#Sort the causes after most to least important, and then calculate the cumulative percentage.&lt;br /&gt;
#Plot bars of the causes ordered from most to least frequent on the x-axis, and then plot the cumulative percentages on the y-axis. &lt;br /&gt;
#Finally, separate the 20% most important root causes from the rest by lifting the x-axis to the 80% cumulative percent on the y-axis.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:Pareto-chart-example.png|600px|thumb|left|Figure 4: An example of a Pareto Chart Analysis[https://www.whatissixsigma.net/pareto-chart-and-analysis/]]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Challenges and limitations ==&lt;br /&gt;
&lt;br /&gt;
For the Root Cause Analysis to give results, it is dependent on a larger problem-solving effort to improve the quality in a business. It therefore the managements responsibility to make the best use of the findings from the root cause analyses. The root cause analysis on itself would not provide the correct result. When it comes to the conduction of a root cause analysis, it is hard to fully know if you have taken every root cause into consideration. The reason for this is because there can be multiple root causes, and there is hard to tell when every root cause has been found. This can lead to too much time spent on irrelevant underlaying factors, which result in confusion and a waste of time. The 5 whys and the fishbone analysis does not rely on specific data, which can lead to less reliable results. The management can therefore have trouble entirely trusting these analyses. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Annotated Bibliography==&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The 5 whys by Olivier Serrat&#039;&#039;&#039;&lt;br /&gt;
The article “The Five Whys Technique” by Olivier Serrat, provides powerful knowledge within the use of the five “why” technique. It provides sufficient information both in relation to the background and meaning of using this technique, but also a step by step guide on how to use it in practice. This is very useful both for current and upcoming managers who will stumble upon a need to use this technique in real life. The article is short, which makes it quick to read. But if there is a need for further knowledge within the subject, reading material of high quality is referred to at the end of the article.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Root Cause Analysis: The Core of Problem Solving and Corrective Action by Duke Okes&#039;&#039;&#039;&lt;br /&gt;
In the book Root Cause Analysis: The Core of Problem Solving and Corrective Action, the author Duke Okes goes in-depth of the importance of using and how to use root cause analyses to catch the actual root causes of problems, and not only the symptoms of them. Different techniques to be implemented into a business are presented in detail so that the management in a company can reduce the amount of reoccurring problems. The terminology in this book is also simpler than most articles and research books, which makes it easy to read for the management.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The Importance of Root Cause Analysis During Incident Investigation by the Occupational Safety and Health Administration (OSHA)&#039;&#039;&#039;&lt;br /&gt;
The factsheet supplied by the OSHA provides a hands-on guidance for conducting root cause analyses in general. Different from most other articles this factsheet provides clear instructions for the whole root cause analysis process, both on a low level where problems are easy to find the causes for, but also for more complex problems. This gives the employees a good understanding of when to actually contact the upper management, which is very useful to achieve optimal efficiency in a company.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
[https://www.tableau.com/learn/articles/root-cause-analysis [1]] Root Cause Analysis Explained: Definition, Examples, and Methods by Tableau&lt;br /&gt;
&lt;br /&gt;
[https://www.geeksforgeeks.org/basic-principle-of-root-cause-analysis/ [2]] Basic Principle of Root cause analysis by GeeksforGeeks&lt;br /&gt;
&lt;br /&gt;
[https://www.researchgate.net/publication/46567642_Application_Of_Fishbone_Diagram_To_Determine_The_Risk_Of_An_Event_With_Multiple_Causes [3]] Application Of Fishbone Diagram To Determine The Risk Of An Event With Multiple Causes by the UTI Grup SRL and the Academy of Economic Studies&lt;br /&gt;
&lt;br /&gt;
[https://www.ionos.ca/startupguide/productivity/fishbone-diagram/[4]] Fishbone diagram: Solving problems properly by IONOS&lt;br /&gt;
&lt;br /&gt;
[https://www.corship.eu/5-whys-method/ [5]] 5 Whys Method by CORSHIP – CORPORATE EDUPRENEURSHIP&lt;br /&gt;
&lt;br /&gt;
[https://www.adb.org/publications/five-whys-technique [6]] The Five Whys Technique by Olivier Serrat&lt;br /&gt;
&lt;br /&gt;
[https://www.slideshare.net/himanshuhora/pareto-analysis-28873221 [7]]Pareto Analysis by Dr. Himanshu Hora, SRMS College of Engineering &amp;amp; Technology Bareilly&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122440</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122440"/>
		<updated>2022-03-27T18:10:23Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: /* Fishbone Diagram */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;Developed by William Vossgård&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
==== Abstract ====&lt;br /&gt;
Root Cause Analysis (RCA) is a method of problem solving that can be used in a project, program or portfolio (PPP) to identify root causes of faults and problems in order to identify appropriate solutions. It is broadly used in several industries, among the health care, infrastructure and information technology industry. A Root Cause Analysis supposes that it is more effective to go in-depth of occurring problems, so that the underlaying issue can be treated, instead of only treating ad hoc symptoms. Root Cause Analyses can be performed with several different methodologies, principles and techniques together to identify the root causes of a fault or problem. The goal is to find out where processes or systems failed or caused an issue in the first place.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
To be able to fully understand what a root cause analysis is and what it is used for, it is easier to relate it to something we are entirely acknowledged with. If your arm hurts considerably after an accident, you will go to the doctor to find the root cause of your pain. Also, if your computer stops working, you will try to find the root cause of its malfunction, either by yourself or by a professional technician. For these examples, a simple remedy could be found for the symptoms. To stop your arm from hurting, you could put ice on it to relive pain. To get work done with a broken computer, you could use your phone or tablet instead. Unfortunately, this would only consider the symptoms and not the underlaying issue that caused the problem. The injured arm may need surgery to entirely recover from the sustained injury, and the broken computer may need to have a new battery to function again. The best way to solve a fault or problem would therefore be to perform a Root Cause Analysis. By doing this, the exact root cause can be found so that the correct management of the fault or problem will be accomplished.&lt;br /&gt;
There are a number of techniques and strategies that can be used for root cause analyses. In this article, the most commonly and widely used techniques will be covered.&lt;br /&gt;
&lt;br /&gt;
== Conducting a root cause analysis ==&lt;br /&gt;
&lt;br /&gt;
There is not one specific way of performing a root cause analysis as there are many different techniques and strategies that can be used. In this chapter, the most common and broadly used techniques will be covered. Root cause analyses gives the best effect when a team is gathered, to do the analysis together. In particular, it should be done with those employees, who are directly involved in the problem-causing processes.&lt;br /&gt;
&lt;br /&gt;
===== Goals and benefits =====&lt;br /&gt;
&lt;br /&gt;
Related to the root cause analysis, there are three goals that should be realised. The first one being to discover the root cause of a failure or problem. The second is to develop an understanding on how to fix and learn from the underlaying issues relating the root cause. The third and final is to apply the findings from the root cause analysis, to systematically prevent future issues or problems. The third goal is especially important as this is what gives the analysis a reason to be performed. Root cause analysis can be used for increasing the productiveness in several core processes as well, with the goal to prevent problems in the future. Instead of replacing punctured bike tires on rental bikes, puncture proof tires could be installed instead if the problem persists [https://www.tableau.com/learn/articles/root-cause-analysis [1]].&lt;br /&gt;
&lt;br /&gt;
===== General principles =====&lt;br /&gt;
&lt;br /&gt;
To achieve an effective root cause analysis process, there are some general principles that should be taken into consideration. These principles will increase the quality of the analysis and will help the analysis get trust from clients and stakeholders [https://www.geeksforgeeks.org/basic-principle-of-root-cause-analysis/[2]].&lt;br /&gt;
&lt;br /&gt;
*Consider to actually correct and remedy the root causes, not only the symptoms.&lt;br /&gt;
*While performing the root cause analysis, also remember to treat symptoms for short term fixing.&lt;br /&gt;
*Avoid focus on who was responsible of the failure or problem, instead focus on how and why.&lt;br /&gt;
*Find and document ways to prevent similar root causes in the future.&lt;br /&gt;
*When finding root causes, provide cause-effect evidence to back it up.&lt;br /&gt;
*Often there are multiple root causes, therefore search for several.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
As it can be understood from the principles above, it is important to take a comprehensive and holistic approach in this type of analysis. As the root causes have no importance if no action is taken afterwards, it should be strived to provide information and context that can solve the failure or problem.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Fishbone Diagram ===&lt;br /&gt;
A Fishbone diagram, which also is called an Ishikawa diagram, is used to identify root causes of quality problems. The fishbone diagram provides an organised way of looking at effects and causes. It can also be referred to as a cause-and-effect diagram. It generally represents a model of indicative presentation for the correlations between an event, which is an effect, and its several causes. This helps the team members get the same understanding of the problem, so that they can think systematically. The root causes of a problem can by using this structured approach be found, while encouraging group participation, utilising group knowledge and identifying areas where data should be collected for future studies. Hence the name, the diagram has the same structure as the skeleton of a fish. While it most often is used in a simple representation, with segments leaning on a horizontal axis, it can also be done with a more extensive approach. An example of this is by naming and coding of the risks which characterises the causes and sub-causes. This consists of elements that show the causes and sub-causes succession with different ways for risk treatment [https://www.researchgate.net/publication/46567642_Application_Of_Fishbone_Diagram_To_Determine_The_Risk_Of_An_Event_With_Multiple_Causes[3]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:A-generic-representation-of-the-Ishikawa-diagram-aka-Fishbone-diagram.png|400px|thumb|centre|Figure 1: Illustration of a Fishbone diagram]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Five steps should be followed to successful use the Fishbone diagram technique [https://www.ionos.ca/startupguide/productivity/fishbone-diagram/[4]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#The first step is to state the problem precisely. This problem statement must be carefully chosen, and it is important that it is specific enough.&lt;br /&gt;
#Define the main influencing factors. This is the factors are put in the horizontal category segments in the fishbone diagram. Different defects or problems have different influencing, which means that these should be chosen after what is relevant. Examples of these is seen in the figure 1.&lt;br /&gt;
#State the causes into the diagram sorted after the different categories. This should be done with those employees that are directly involved in the problem causing processes. Also, the team should consist of a mix of different levels of expertise. When analysing the problem statement and finding causes, further sub-causes can be elaborated upon.&lt;br /&gt;
#Prioritise the causes. In the same team, make each person state their opinion as what is the most serious cause of the defect or problem. After a discussion about the causes, each person can give points to the causes that they believe are the most serious. The causes with the most points, should then be prioritised.&lt;br /&gt;
#Take measures. Tackle the defect or problem by eradicating the cause or causes. I it’s important that it is certain that the correct cause have been identified. To make sure of this, a significance test can be used for verifying, in order to select suitable methods for problem-solving.&lt;br /&gt;
&lt;br /&gt;
=== The 5 Whys ===&lt;br /&gt;
The 5 whys is a simple, yet powerful way of finding root causes. It works as an iterative interrogative technique to explore cause-and-effect relationship underlaying a particular problem. It is often used together with the a Fishbone diagram to find the root causes for the causes on the diagram.  As the name of technique implies, the primary goal is to find the root cause of a problem by asking “Why?” five times. Each answer of the “Whys” forms the basis for the next question, and when the fifth “Why?” have been answered, the root cause should be found. Five times is generally enough, but if the root cause still not is found, it could be repeated up to a total of six, seven or higher levels. For problems or defects that do not have one single root cause, the technique must be repeated asking a different sequence of questions each time [https://www.corship.eu/5-whys-method/[5]]. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:5-whys-example (1).png|500px|thumb|right|Figure 2: Example of a 5 whys analysis[https://www.corship.eu/5-whys-method/]]]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The five steps to conduct the 5 whys analysis, is to [https://www.adb.org/publications/five-whys-technique[6]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather a team who can develop a problem statement in agreement. At this point, it should be discussed whether additionally individuals are needed to resolve the problem. &lt;br /&gt;
#Make the team come with statements on “Why is this or that defect or problem taking place?”. This is the first “why” of the analysis. There are most probable multiple statements for this, and they should all be written down.&lt;br /&gt;
#Repeat the same process asking “why” four more times. This should be done for every statement from the first “why” in the structure like figure 2 shows. All plausible answers should be written down. When the “why” does not yield further useful information, you have found the root cause. This means that is sometimes may take more than five layers to find the root cause.&lt;br /&gt;
#Among the many answers to the last asked “why”, look for systematic causes of the defect or problem. This should be discussed in the group to be able to settle for the most likely systematic cause. The product from the team session should then be showed to others to confirm that they see the same logic in the analysis.&lt;br /&gt;
#The last and final step of the 5 why analysis is to develop appropriate corrective actions to remove the root cause from the system. Others can undertake these actions but planning and implementation will benefit from inputs from the team.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===Pareto Chart Analysis===&lt;br /&gt;
[[File:Pareto output.png|400px|thumb|right|Figure 3: The 20/80 principle]]&lt;br /&gt;
The Pareto chart combines a histogram (bar chart) and a line chart, where cost or frequency of defects or problems show their relative importance. Frequencies are shown in the histogram with descending order of the bars, and the line chart shows the totals or the cumulative percentages increasing from left to right. It is based on the Pareto principle, which states that “80% of the effects or consequences come from 20% of the causes”. This is not like the immutable laws of physics but based on continuous observations. On those observations, it has showed to be applicable to many aspects of life and natural phenomena. In relation to a root cause analysis, the Pareto Chart Analysis helps identify the top 20% of the causes that needs to be addressed to resolve 80% of the problems [https://www.slideshare.net/himanshuhora/pareto-analysis-28873221[7]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;In order to perform a Pareto Chart Analysis, the following needs to be done [https://www.slideshare.net/himanshuhora/pareto-analysis-28873221[7]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather and collect data on the frequency of the causes of a defect or problem.&lt;br /&gt;
#Sort the causes after most to least important, and then calculate the cumulative percentage.&lt;br /&gt;
#Plot bars of the causes ordered from most to least frequent on the x-axis, and then plot the cumulative percentages on the y-axis. &lt;br /&gt;
#Finally, separate the 20% most important root causes from the rest by lifting the x-axis to the 80% cumulative percent on the y-axis.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:Pareto-chart-example.png|600px|thumb|left|Figure 4: An example of a Pareto Chart Analysis[https://www.whatissixsigma.net/pareto-chart-and-analysis/]]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Challenges and limitations ==&lt;br /&gt;
&lt;br /&gt;
For the Root Cause Analysis to give results, it is dependent on a larger problem-solving effort to improve the quality in a business. It therefore the managements responsibility to make the best use of the findings from the root cause analyses. The root cause analysis on itself would not provide the correct result. When it comes to the conduction of a root cause analysis, it is hard to fully know if you have taken every root cause into consideration. The reason for this is because there can be multiple root causes, and there is hard to tell when every root cause has been found. This can lead to too much time spent on irrelevant underlaying factors, which result in confusion and a waste of time. The 5 whys and the fishbone analysis does not rely on specific data, which can lead to less reliable results. The management can therefore have trouble entirely trusting these analyses. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Annotated Bibliography==&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The 5 whys by Olivier Serrat&#039;&#039;&#039;&lt;br /&gt;
The article “The Five Whys Technique” by Olivier Serrat, provides powerful knowledge within the use of the five “why” technique. It provides sufficient information both in relation to the background and meaning of using this technique, but also a step by step guide on how to use it in practice. This is very useful both for current and upcoming managers who will stumble upon a need to use this technique in real life. The article is short, which makes it quick to read. But if there is a need for further knowledge within the subject, reading material of high quality is referred to at the end of the article.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Root Cause Analysis: The Core of Problem Solving and Corrective Action by Duke Okes&#039;&#039;&#039;&lt;br /&gt;
In the book Root Cause Analysis: The Core of Problem Solving and Corrective Action, the author Duke Okes goes in-depth of the importance of using and how to use root cause analyses to catch the actual root causes of problems, and not only the symptoms of them. Different techniques to be implemented into a business are presented in detail so that the management in a company can reduce the amount of reoccurring problems. The terminology in this book is also simpler than most articles and research books, which makes it easy to read for the management.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The Importance of Root Cause Analysis During Incident Investigation by the Occupational Safety and Health Administration (OSHA)&#039;&#039;&#039;&lt;br /&gt;
The factsheet supplied by the OSHA provides a hands-on guidance for conducting root cause analyses in general. Different from most other articles this factsheet provides clear instructions for the whole root cause analysis process, both on a low level where problems are easy to find the causes for, but also for more complex problems. This gives the employees a good understanding of when to actually contact the upper management, which is very useful to achieve optimal efficiency in a company.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
[https://www.tableau.com/learn/articles/root-cause-analysis [1]] Root Cause Analysis Explained: Definition, Examples, and Methods by Tableau&lt;br /&gt;
&lt;br /&gt;
[https://www.geeksforgeeks.org/basic-principle-of-root-cause-analysis/ [2]] Basic Principle of Root cause analysis by GeeksforGeeks&lt;br /&gt;
&lt;br /&gt;
[https://www.researchgate.net/publication/46567642_Application_Of_Fishbone_Diagram_To_Determine_The_Risk_Of_An_Event_With_Multiple_Causes [3]] Application Of Fishbone Diagram To Determine The Risk Of An Event With Multiple Causes by the UTI Grup SRL and the Academy of Economic Studies&lt;br /&gt;
&lt;br /&gt;
[https://www.ionos.ca/startupguide/productivity/fishbone-diagram/[4]] Fishbone diagram: Solving problems properly by IONOS&lt;br /&gt;
&lt;br /&gt;
[https://www.corship.eu/5-whys-method/ [5]] 5 Whys Method by CORSHIP – CORPORATE EDUPRENEURSHIP&lt;br /&gt;
&lt;br /&gt;
[https://www.adb.org/publications/five-whys-technique [6]] The Five Whys Technique by Olivier Serrat&lt;br /&gt;
&lt;br /&gt;
[https://www.slideshare.net/himanshuhora/pareto-analysis-28873221 [7]]Pareto Analysis by Dr. Himanshu Hora, SRMS College of Engineering &amp;amp; Technology Bareilly&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122439</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122439"/>
		<updated>2022-03-27T18:09:39Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;Developed by William Vossgård&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
==== Abstract ====&lt;br /&gt;
Root Cause Analysis (RCA) is a method of problem solving that can be used in a project, program or portfolio (PPP) to identify root causes of faults and problems in order to identify appropriate solutions. It is broadly used in several industries, among the health care, infrastructure and information technology industry. A Root Cause Analysis supposes that it is more effective to go in-depth of occurring problems, so that the underlaying issue can be treated, instead of only treating ad hoc symptoms. Root Cause Analyses can be performed with several different methodologies, principles and techniques together to identify the root causes of a fault or problem. The goal is to find out where processes or systems failed or caused an issue in the first place.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
To be able to fully understand what a root cause analysis is and what it is used for, it is easier to relate it to something we are entirely acknowledged with. If your arm hurts considerably after an accident, you will go to the doctor to find the root cause of your pain. Also, if your computer stops working, you will try to find the root cause of its malfunction, either by yourself or by a professional technician. For these examples, a simple remedy could be found for the symptoms. To stop your arm from hurting, you could put ice on it to relive pain. To get work done with a broken computer, you could use your phone or tablet instead. Unfortunately, this would only consider the symptoms and not the underlaying issue that caused the problem. The injured arm may need surgery to entirely recover from the sustained injury, and the broken computer may need to have a new battery to function again. The best way to solve a fault or problem would therefore be to perform a Root Cause Analysis. By doing this, the exact root cause can be found so that the correct management of the fault or problem will be accomplished.&lt;br /&gt;
There are a number of techniques and strategies that can be used for root cause analyses. In this article, the most commonly and widely used techniques will be covered.&lt;br /&gt;
&lt;br /&gt;
== Conducting a root cause analysis ==&lt;br /&gt;
&lt;br /&gt;
There is not one specific way of performing a root cause analysis as there are many different techniques and strategies that can be used. In this chapter, the most common and broadly used techniques will be covered. Root cause analyses gives the best effect when a team is gathered, to do the analysis together. In particular, it should be done with those employees, who are directly involved in the problem-causing processes.&lt;br /&gt;
&lt;br /&gt;
===== Goals and benefits =====&lt;br /&gt;
&lt;br /&gt;
Related to the root cause analysis, there are three goals that should be realised. The first one being to discover the root cause of a failure or problem. The second is to develop an understanding on how to fix and learn from the underlaying issues relating the root cause. The third and final is to apply the findings from the root cause analysis, to systematically prevent future issues or problems. The third goal is especially important as this is what gives the analysis a reason to be performed. Root cause analysis can be used for increasing the productiveness in several core processes as well, with the goal to prevent problems in the future. Instead of replacing punctured bike tires on rental bikes, puncture proof tires could be installed instead if the problem persists [https://www.tableau.com/learn/articles/root-cause-analysis [1]].&lt;br /&gt;
&lt;br /&gt;
===== General principles =====&lt;br /&gt;
&lt;br /&gt;
To achieve an effective root cause analysis process, there are some general principles that should be taken into consideration. These principles will increase the quality of the analysis and will help the analysis get trust from clients and stakeholders [https://www.geeksforgeeks.org/basic-principle-of-root-cause-analysis/[2]].&lt;br /&gt;
&lt;br /&gt;
*Consider to actually correct and remedy the root causes, not only the symptoms.&lt;br /&gt;
*While performing the root cause analysis, also remember to treat symptoms for short term fixing.&lt;br /&gt;
*Avoid focus on who was responsible of the failure or problem, instead focus on how and why.&lt;br /&gt;
*Find and document ways to prevent similar root causes in the future.&lt;br /&gt;
*When finding root causes, provide cause-effect evidence to back it up.&lt;br /&gt;
*Often there are multiple root causes, therefore search for several.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
As it can be understood from the principles above, it is important to take a comprehensive and holistic approach in this type of analysis. As the root causes have no importance if no action is taken afterwards, it should be strived to provide information and context that can solve the failure or problem.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Fishbone Diagram ===&lt;br /&gt;
A Fishbone diagram, which also is called an Ishikawa diagram, is used to identify root causes of quality problems. The fishbone diagram provides an organised way of looking at effects and causes. It can also be referred to as a cause-and-effect diagram. It generally represents a model of indicative presentation for the correlations between an event, which is an effect, and its several causes. This helps the team members get the same understanding of the problem, so that they can think systematically. The root causes of a problem can by using this structured approach be found, while encouraging group participation, utilising group knowledge and identifying areas where data should be collected for future studies. Hence the name, the diagram has the same structure as the skeleton of a fish. While it most often is used in a simple representation, with segments leaning on a horizontal axis, it can also be done with a more extensive approach. An example of this is by naming and coding of the risks which characterises the causes and sub-causes. This consists of elements that show the causes and sub-causes succession with different ways for risk treatment [https://www.researchgate.net/publication/46567642_Application_Of_Fishbone_Diagram_To_Determine_The_Risk_Of_An_Event_With_Multiple_Causes[3]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:A-generic-representation-of-the-Ishikawa-diagram-aka-Fishbone-diagram.png|400px|thumb|centre|Figure 1: Illustration of a Fishbone diagram]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Five steps should be followed to successful use the Fishbone diagram technique [https://www.ionos.ca/startupguide/productivity/fishbone-diagram/[4]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#The first step is to state the problem precisely. This problem statement must be carefully chosen, and it is important that it is specific enough.&lt;br /&gt;
#Define the main influencing factors. This is the factors are put in the horizontal category segments in the fishbone diagram. Different defects or problems have different influencing, which means that these should be chosen after what is relevant. Examples of these is seen in the figure above.&lt;br /&gt;
#State the causes into the diagram sorted after the different categories. This should be done with those employees that are directly involved in the problem causing processes. Also, the team should consist of a mix of different levels of expertise. When analysing the problem statement and finding causes, further sub-causes can be elaborated upon.&lt;br /&gt;
#Prioritise the causes. In the same team, make each person state their opinion as what is the most serious cause of the defect or problem. After a discussion about the causes, each person can give points to the causes that they believe are the most serious. The causes with the most points, should then be prioritised.&lt;br /&gt;
#Take measures. Tackle the defect or problem by eradicating the cause or causes. I it’s important that it is certain that the correct cause have been identified. To make sure of this, a significance test can be used for verifying, in order to select suitable methods for problem-solving.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== The 5 Whys ===&lt;br /&gt;
The 5 whys is a simple, yet powerful way of finding root causes. It works as an iterative interrogative technique to explore cause-and-effect relationship underlaying a particular problem. It is often used together with the a Fishbone diagram to find the root causes for the causes on the diagram.  As the name of technique implies, the primary goal is to find the root cause of a problem by asking “Why?” five times. Each answer of the “Whys” forms the basis for the next question, and when the fifth “Why?” have been answered, the root cause should be found. Five times is generally enough, but if the root cause still not is found, it could be repeated up to a total of six, seven or higher levels. For problems or defects that do not have one single root cause, the technique must be repeated asking a different sequence of questions each time [https://www.corship.eu/5-whys-method/[5]]. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:5-whys-example (1).png|500px|thumb|right|Figure 2: Example of a 5 whys analysis[https://www.corship.eu/5-whys-method/]]]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The five steps to conduct the 5 whys analysis, is to [https://www.adb.org/publications/five-whys-technique[6]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather a team who can develop a problem statement in agreement. At this point, it should be discussed whether additionally individuals are needed to resolve the problem. &lt;br /&gt;
#Make the team come with statements on “Why is this or that defect or problem taking place?”. This is the first “why” of the analysis. There are most probable multiple statements for this, and they should all be written down.&lt;br /&gt;
#Repeat the same process asking “why” four more times. This should be done for every statement from the first “why” in the structure like figure 2 shows. All plausible answers should be written down. When the “why” does not yield further useful information, you have found the root cause. This means that is sometimes may take more than five layers to find the root cause.&lt;br /&gt;
#Among the many answers to the last asked “why”, look for systematic causes of the defect or problem. This should be discussed in the group to be able to settle for the most likely systematic cause. The product from the team session should then be showed to others to confirm that they see the same logic in the analysis.&lt;br /&gt;
#The last and final step of the 5 why analysis is to develop appropriate corrective actions to remove the root cause from the system. Others can undertake these actions but planning and implementation will benefit from inputs from the team.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===Pareto Chart Analysis===&lt;br /&gt;
[[File:Pareto output.png|400px|thumb|right|Figure 3: The 20/80 principle]]&lt;br /&gt;
The Pareto chart combines a histogram (bar chart) and a line chart, where cost or frequency of defects or problems show their relative importance. Frequencies are shown in the histogram with descending order of the bars, and the line chart shows the totals or the cumulative percentages increasing from left to right. It is based on the Pareto principle, which states that “80% of the effects or consequences come from 20% of the causes”. This is not like the immutable laws of physics but based on continuous observations. On those observations, it has showed to be applicable to many aspects of life and natural phenomena. In relation to a root cause analysis, the Pareto Chart Analysis helps identify the top 20% of the causes that needs to be addressed to resolve 80% of the problems [https://www.slideshare.net/himanshuhora/pareto-analysis-28873221[7]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;In order to perform a Pareto Chart Analysis, the following needs to be done [https://www.slideshare.net/himanshuhora/pareto-analysis-28873221[7]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather and collect data on the frequency of the causes of a defect or problem.&lt;br /&gt;
#Sort the causes after most to least important, and then calculate the cumulative percentage.&lt;br /&gt;
#Plot bars of the causes ordered from most to least frequent on the x-axis, and then plot the cumulative percentages on the y-axis. &lt;br /&gt;
#Finally, separate the 20% most important root causes from the rest by lifting the x-axis to the 80% cumulative percent on the y-axis.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:Pareto-chart-example.png|600px|thumb|left|Figure 4: An example of a Pareto Chart Analysis[https://www.whatissixsigma.net/pareto-chart-and-analysis/]]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Challenges and limitations ==&lt;br /&gt;
&lt;br /&gt;
For the Root Cause Analysis to give results, it is dependent on a larger problem-solving effort to improve the quality in a business. It therefore the managements responsibility to make the best use of the findings from the root cause analyses. The root cause analysis on itself would not provide the correct result. When it comes to the conduction of a root cause analysis, it is hard to fully know if you have taken every root cause into consideration. The reason for this is because there can be multiple root causes, and there is hard to tell when every root cause has been found. This can lead to too much time spent on irrelevant underlaying factors, which result in confusion and a waste of time. The 5 whys and the fishbone analysis does not rely on specific data, which can lead to less reliable results. The management can therefore have trouble entirely trusting these analyses. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Annotated Bibliography==&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The 5 whys by Olivier Serrat&#039;&#039;&#039;&lt;br /&gt;
The article “The Five Whys Technique” by Olivier Serrat, provides powerful knowledge within the use of the five “why” technique. It provides sufficient information both in relation to the background and meaning of using this technique, but also a step by step guide on how to use it in practice. This is very useful both for current and upcoming managers who will stumble upon a need to use this technique in real life. The article is short, which makes it quick to read. But if there is a need for further knowledge within the subject, reading material of high quality is referred to at the end of the article.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Root Cause Analysis: The Core of Problem Solving and Corrective Action by Duke Okes&#039;&#039;&#039;&lt;br /&gt;
In the book Root Cause Analysis: The Core of Problem Solving and Corrective Action, the author Duke Okes goes in-depth of the importance of using and how to use root cause analyses to catch the actual root causes of problems, and not only the symptoms of them. Different techniques to be implemented into a business are presented in detail so that the management in a company can reduce the amount of reoccurring problems. The terminology in this book is also simpler than most articles and research books, which makes it easy to read for the management.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The Importance of Root Cause Analysis During Incident Investigation by the Occupational Safety and Health Administration (OSHA)&#039;&#039;&#039;&lt;br /&gt;
The factsheet supplied by the OSHA provides a hands-on guidance for conducting root cause analyses in general. Different from most other articles this factsheet provides clear instructions for the whole root cause analysis process, both on a low level where problems are easy to find the causes for, but also for more complex problems. This gives the employees a good understanding of when to actually contact the upper management, which is very useful to achieve optimal efficiency in a company.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
[https://www.tableau.com/learn/articles/root-cause-analysis [1]] Root Cause Analysis Explained: Definition, Examples, and Methods by Tableau&lt;br /&gt;
&lt;br /&gt;
[https://www.geeksforgeeks.org/basic-principle-of-root-cause-analysis/ [2]] Basic Principle of Root cause analysis by GeeksforGeeks&lt;br /&gt;
&lt;br /&gt;
[https://www.researchgate.net/publication/46567642_Application_Of_Fishbone_Diagram_To_Determine_The_Risk_Of_An_Event_With_Multiple_Causes [3]] Application Of Fishbone Diagram To Determine The Risk Of An Event With Multiple Causes by the UTI Grup SRL and the Academy of Economic Studies&lt;br /&gt;
&lt;br /&gt;
[https://www.ionos.ca/startupguide/productivity/fishbone-diagram/[4]] Fishbone diagram: Solving problems properly by IONOS&lt;br /&gt;
&lt;br /&gt;
[https://www.corship.eu/5-whys-method/ [5]] 5 Whys Method by CORSHIP – CORPORATE EDUPRENEURSHIP&lt;br /&gt;
&lt;br /&gt;
[https://www.adb.org/publications/five-whys-technique [6]] The Five Whys Technique by Olivier Serrat&lt;br /&gt;
&lt;br /&gt;
[https://www.slideshare.net/himanshuhora/pareto-analysis-28873221 [7]]Pareto Analysis by Dr. Himanshu Hora, SRMS College of Engineering &amp;amp; Technology Bareilly&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122341</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122341"/>
		<updated>2022-03-27T16:15:15Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: /* Annotated Bibliography */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;Developed by William Vossgård&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
==== Abstract ====&lt;br /&gt;
Root Cause Analysis (RCA) is a method of problem solving that can be used in a project, program or portfolio (PPP) to identify root causes of faults and problems in order to identify appropriate solutions. It is broadly used in several industries, among the health care, infrastructure and information technology industry. A Root Cause Analysis supposes that it is more effective to go in-depth of occurring problems, so that the underlaying issue can be treated, instead of only treating ad hoc symptoms. Root Cause Analyses can be performed with several different methodologies, principles and techniques together to identify the root causes of a fault or problem. The goal is to find out where processes or systems failed or caused an issue in the first place.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
To be able to fully understand what a root cause analysis is and what it is used for, it is easier to relate it to something we are entirely acknowledged with. If your arm hurts considerably after an accident, you will go to the doctor to find the root cause of your pain. Also, if your computer stops working, you will try to find the root cause of its malfunction, either by yourself or by a professional technician. For these examples, a simple remedy could be found for the symptoms. To stop your arm from hurting, you could put ice on it to relive pain. To get work done with a broken computer, you could use your phone or tablet instead. Unfortunately, this would only consider the symptoms and not the underlaying issue that caused the problem. The injured arm may need surgery to entirely recover from the sustained injury, and the broken computer may need to have a new battery to function again. The best way to solve a fault or problem would therefore be to perform a Root Cause Analysis. By doing this, the exact root cause can be found so that the correct management of the fault or problem will be accomplished.&lt;br /&gt;
There are a number of techniques and strategies that can be used for root cause analyses. In this article, the most commonly and widely used techniques will be covered.&lt;br /&gt;
&lt;br /&gt;
== Conducting a root cause analysis ==&lt;br /&gt;
&lt;br /&gt;
There is not one specific way of performing a root cause analysis as there are many different techniques and strategies that can be used. In this chapter, the most common and broadly used techniques will be covered. Root cause analyses gives the best effect when a team is gathered, to do the analysis together. In particular, it should be done with those employees, who are directly involved in the problem-causing processes.&lt;br /&gt;
&lt;br /&gt;
===== Goals and benefits =====&lt;br /&gt;
&lt;br /&gt;
Related to the root cause analysis, there are three goals that should be realised. The first one being to discover the root cause of a failure or problem. The second is to develop an understanding on how to fix and learn from the underlaying issues relating the root cause. The third and final is to apply the findings from the root cause analysis, to systematically prevent future issues or problems. The third goal is especially important as this is what gives the analysis a reason to be performed. Root cause analysis can be used for increasing the productiveness in several core processes as well, with the goal to prevent problems in the future. Instead of replacing punctured bike tires on rental bikes, puncture proof tires could be installed instead if the problem persists [https://www.tableau.com/learn/articles/root-cause-analysis [1]].&lt;br /&gt;
&lt;br /&gt;
===== General principles =====&lt;br /&gt;
&lt;br /&gt;
To achieve an effective root cause analysis process, there are some general principles that should be taken into consideration. These principles will increase the quality of the analysis and will help the analysis get trust from clients and stakeholders [https://www.geeksforgeeks.org/basic-principle-of-root-cause-analysis/[2]].&lt;br /&gt;
&lt;br /&gt;
*Consider to actually correct and remedy the root causes, not only the symptoms.&lt;br /&gt;
*While performing the root cause analysis, also remember to treat symptoms for short term fixing.&lt;br /&gt;
*Avoid focus on who was responsible of the failure or problem, instead focus on how and why.&lt;br /&gt;
*Find and document ways to prevent similar root causes in the future.&lt;br /&gt;
*When finding root causes, provide cause-effect evidence to back it up.&lt;br /&gt;
*Often there are multiple root causes, therefore search for several.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
As it can be understood from the principles above, it is important to take a comprehensive and holistic approach in this type of analysis. As the root causes have no importance if no action is taken afterwards, it should be strived to provide information and context that can solve the failure or problem.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Fishbone Diagram ===&lt;br /&gt;
A Fishbone diagram, which also is called an Ishikawa diagram, is used to identify root causes of quality problems. The fishbone diagram provides an organised way of looking at effects and causes. It can also be referred to as a cause-and-effect diagram. It generally represents a model of indicative presentation for the correlations between an event, which is an effect, and its several causes. This helps the team members get the same understanding of the problem, so that they can think systematically. The root causes of a problem can by using this structured approach be found, while encouraging group participation, utilising group knowledge and identifying areas where data should be collected for future studies. Hence the name, the diagram has the same structure as the skeleton of a fish. While it most often is used in a simple representation, with segments leaning on a horizontal axis, it can also be done with a more extensive approach. An example of this is by naming and coding of the risks which characterises the causes and sub-causes. This consists of elements that show the causes and sub-causes succession with different ways for risk treatment [https://www.researchgate.net/publication/46567642_Application_Of_Fishbone_Diagram_To_Determine_The_Risk_Of_An_Event_With_Multiple_Causes[3]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:A-generic-representation-of-the-Ishikawa-diagram-aka-Fishbone-diagram.png|400px|thumb|centre|Figure 2: Illustration of a Fishbone diagram]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Five steps should be followed to successful use the Fishbone diagram technique [https://www.ionos.ca/startupguide/productivity/fishbone-diagram/[4]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#The first step is to state the problem precisely. This problem statement must be carefully chosen, and it is important that it is specific enough.&lt;br /&gt;
#Define the main influencing factors. This is the factors are put in the horizontal category segments in the fishbone diagram. Different defects or problems have different influencing, which means that these should be chosen after what is relevant. Examples of these is seen in the figure above.&lt;br /&gt;
#State the causes into the diagram sorted after the different categories. This should be done with those employees that are directly involved in the problem causing processes. Also, the team should consist of a mix of different levels of expertise. When analysing the problem statement and finding causes, further sub-causes can be elaborated upon.&lt;br /&gt;
#Prioritise the causes. In the same team, make each person state their opinion as what is the most serious cause of the defect or problem. After a discussion about the causes, each person can give points to the causes that they believe are the most serious. The causes with the most points, should then be prioritised.&lt;br /&gt;
#Take measures. Tackle the defect or problem by eradicating the cause or causes. I it’s important that it is certain that the correct cause have been identified. To make sure of this, a significance test can be used for verifying, in order to select suitable methods for problem-solving.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== The 5 Whys ===&lt;br /&gt;
The 5 whys is a simple, yet powerful way of finding root causes. It works as an iterative interrogative technique to explore cause-and-effect relationship underlaying a particular problem. It is often used together with the a Fishbone diagram to find the root causes for the causes on the diagram.  As the name of technique implies, the primary goal is to find the root cause of a problem by asking “Why?” five times. Each answer of the “Whys” forms the basis for the next question, and when the fifth “Why?” have been answered, the root cause should be found. Five times is generally enough, but if the root cause still not is found, it could be repeated up to a total of six, seven or higher levels. For problems or defects that do not have one single root cause, the technique must be repeated asking a different sequence of questions each time [https://www.corship.eu/5-whys-method/[5]]. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:5-whys-example (1).png|500px|thumb|right|Figure 3: Example of a 5 whys analysis[https://www.corship.eu/5-whys-method/]]]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The five steps to conduct the 5 whys analysis, is to [https://www.adb.org/publications/five-whys-technique[6]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather a team who can develop a problem statement in agreement. At this point, it should be discussed whether additionally individuals are needed to resolve the problem. &lt;br /&gt;
#Make the team come with statements on “Why is this or that defect or problem taking place?”. This is the first “why” of the analysis. There are most probable multiple statements for this, and they should all be written down.&lt;br /&gt;
#Repeat the same process asking “why” four more times. This should be done for every statement from the first “why” in the structure like the figure below shows. All plausible answers should be written down. When the “why” does not yield further useful information, you have found the root cause. This means that is sometimes may take more than five layers to find the root cause.&lt;br /&gt;
#Among the many answers to the last asked “why”, look for systematic causes of the defect or problem. This should be discussed in the group to be able to settle for the most likely systematic cause. The product from the team session should then be showed to others to confirm that they see the same logic in the analysis.&lt;br /&gt;
#The last and final step of the 5 why analysis is to develop appropriate corrective actions to remove the root cause from the system. Others can undertake these actions but planning and implementation will benefit from inputs from the team.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===Pareto Chart Analysis===&lt;br /&gt;
[[File:Pareto output.png|400px|thumb|right|Figure 4: The 20/80 principle]]&lt;br /&gt;
The Pareto chart combines a histogram (bar chart) and a line chart, where cost or frequency of defects or problems show their relative importance. Frequencies are shown in the histogram with descending order of the bars, and the line chart shows the totals or the cumulative percentages increasing from left to right. It is based on the Pareto principle, which states that “80% of the effects or consequences come from 20% of the causes”. This is not like the immutable laws of physics but based on continuous observations. On those observations, it has showed to be applicable to many aspects of life and natural phenomena. In relation to a root cause analysis, the Pareto Chart Analysis helps identify the top 20% of the causes that needs to be addressed to resolve 80% of the problems [https://www.slideshare.net/himanshuhora/pareto-analysis-28873221[7]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;In order to perform a Pareto Chart Analysis, the following needs to be done [https://www.slideshare.net/himanshuhora/pareto-analysis-28873221[7]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather and collect data on the frequency of the causes of a defect or problem.&lt;br /&gt;
#Sort the causes after most to least important, and then calculate the cumulative percentage.&lt;br /&gt;
#Plot bars of the causes ordered from most to least frequent on the x-axis, and then plot the cumulative percentages on the y-axis. &lt;br /&gt;
#Finally, separate the 20% most important root causes from the rest by lifting the x-axis to the 80% cumulative percent on the y-axis.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:Pareto-chart-example.png|600px|thumb|left|Figure 5: An example of a Pareto Chart Analysis[https://www.whatissixsigma.net/pareto-chart-and-analysis/]]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Challenges and limitations ==&lt;br /&gt;
&lt;br /&gt;
For the Root Cause Analysis to give results, it is dependent on a larger problem-solving effort to improve the quality in a business. It therefore the managements responsibility to make the best use of the findings from the root cause analyses. The root cause analysis on itself would not provide the correct result. When it comes to the conduction of a root cause analysis, it is hard to fully know if you have taken every root cause into consideration. The reason for this is because there can be multiple root causes, and there is hard to tell when every root cause has been found. This can lead to too much time spent on irrelevant underlaying factors, which result in confusion and a waste of time. The 5 whys and the fishbone analysis does not rely on specific data, which can lead to less reliable results. The management can therefore have trouble entirely trusting these analyses. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Annotated Bibliography==&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The 5 whys by Olivier Serrat&#039;&#039;&#039;&lt;br /&gt;
The article “The Five Whys Technique” by Olivier Serrat, provides powerful knowledge within the use of the five “why” technique. It provides sufficient information both in relation to the background and meaning of using this technique, but also a step by step guide on how to use it in practice. This is very useful both for current and upcoming managers who will stumble upon a need to use this technique in real life. The article is short, which makes it quick to read. But if there is a need for further knowledge within the subject, reading material of high quality is referred to at the end of the article.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Root Cause Analysis: The Core of Problem Solving and Corrective Action by Duke Okes&#039;&#039;&#039;&lt;br /&gt;
In the book Root Cause Analysis: The Core of Problem Solving and Corrective Action, the author Duke Okes goes in-depth of the importance of using and how to use root cause analyses to catch the actual root causes of problems, and not only the symptoms of them. Different techniques to be implemented into a business are presented in detail so that the management in a company can reduce the amount of reoccurring problems. The terminology in this book is also simpler than most articles and research books, which makes it easy to read for the management.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The Importance of Root Cause Analysis During Incident Investigation by the Occupational Safety and Health Administration (OSHA)&#039;&#039;&#039;&lt;br /&gt;
The factsheet supplied by the OSHA provides a hands-on guidance for conducting root cause analyses in general. Different from most other articles this factsheet provides clear instructions for the whole root cause analysis process, both on a low level where problems are easy to find the causes for, but also for more complex problems. This gives the employees a good understanding of when to actually contact the upper management, which is very useful to achieve optimal efficiency in a company.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
[https://www.tableau.com/learn/articles/root-cause-analysis [1]] Root Cause Analysis Explained: Definition, Examples, and Methods by Tableau&lt;br /&gt;
&lt;br /&gt;
[https://www.geeksforgeeks.org/basic-principle-of-root-cause-analysis/ [2]] Basic Principle of Root cause analysis by GeeksforGeeks&lt;br /&gt;
&lt;br /&gt;
[https://www.researchgate.net/publication/46567642_Application_Of_Fishbone_Diagram_To_Determine_The_Risk_Of_An_Event_With_Multiple_Causes [3]] Application Of Fishbone Diagram To Determine The Risk Of An Event With Multiple Causes by the UTI Grup SRL and the Academy of Economic Studies&lt;br /&gt;
&lt;br /&gt;
[https://www.ionos.ca/startupguide/productivity/fishbone-diagram/[4]] Fishbone diagram: Solving problems properly by IONOS&lt;br /&gt;
&lt;br /&gt;
[https://www.corship.eu/5-whys-method/ [5]] 5 Whys Method by CORSHIP – CORPORATE EDUPRENEURSHIP&lt;br /&gt;
&lt;br /&gt;
[https://www.adb.org/publications/five-whys-technique [6]] The Five Whys Technique by Olivier Serrat&lt;br /&gt;
&lt;br /&gt;
[https://www.slideshare.net/himanshuhora/pareto-analysis-28873221 [7]]Pareto Analysis by Dr. Himanshu Hora, SRMS College of Engineering &amp;amp; Technology Bareilly&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122308</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122308"/>
		<updated>2022-03-27T15:56:29Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: /* Annotated Bibliography */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;Developed by William Vossgård&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
==== Abstract ====&lt;br /&gt;
Root Cause Analysis (RCA) is a method of problem solving that can be used in a project, program or portfolio (PPP) to identify root causes of faults and problems in order to identify appropriate solutions. It is broadly used in several industries, among the health care, infrastructure and information technology industry. A Root Cause Analysis supposes that it is more effective to go in-depth of occurring problems, so that the underlaying issue can be treated, instead of only treating ad hoc symptoms. Root Cause Analyses can be performed with several different methodologies, principles and techniques together to identify the root causes of a fault or problem. The goal is to find out where processes or systems failed or caused an issue in the first place.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
To be able to fully understand what a root cause analysis is and what it is used for, it is easier to relate it to something we are entirely acknowledged with. If your arm hurts considerably after an accident, you will go to the doctor to find the root cause of your pain. Also, if your computer stops working, you will try to find the root cause of its malfunction, either by yourself or by a professional technician. For these examples, a simple remedy could be found for the symptoms. To stop your arm from hurting, you could put ice on it to relive pain. To get work done with a broken computer, you could use your phone or tablet instead. Unfortunately, this would only consider the symptoms and not the underlaying issue that caused the problem. The injured arm may need surgery to entirely recover from the sustained injury, and the broken computer may need to have a new battery to function again. The best way to solve a fault or problem would therefore be to perform a Root Cause Analysis. By doing this, the exact root cause can be found so that the correct management of the fault or problem will be accomplished.&lt;br /&gt;
There are a number of techniques and strategies that can be used for root cause analyses. In this article, the most commonly and widely used techniques will be covered.&lt;br /&gt;
&lt;br /&gt;
== Conducting a root cause analysis ==&lt;br /&gt;
&lt;br /&gt;
There is not one specific way of performing a root cause analysis as there are many different techniques and strategies that can be used. In this chapter, the most common and broadly used techniques will be covered. Root cause analyses gives the best effect when a team is gathered, to do the analysis together. In particular, it should be done with those employees, who are directly involved in the problem-causing processes.&lt;br /&gt;
&lt;br /&gt;
===== Goals and benefits =====&lt;br /&gt;
&lt;br /&gt;
Related to the root cause analysis, there are three goals that should be realised. The first one being to discover the root cause of a failure or problem. The second is to develop an understanding on how to fix and learn from the underlaying issues relating the root cause. The third and final is to apply the findings from the root cause analysis, to systematically prevent future issues or problems. The third goal is especially important as this is what gives the analysis a reason to be performed. Root cause analysis can be used for increasing the productiveness in several core processes as well, with the goal to prevent problems in the future. Instead of replacing punctured bike tires on rental bikes, puncture proof tires could be installed instead if the problem persists [https://www.tableau.com/learn/articles/root-cause-analysis [1]].&lt;br /&gt;
&lt;br /&gt;
===== General principles =====&lt;br /&gt;
&lt;br /&gt;
To achieve an effective root cause analysis process, there are some general principles that should be taken into consideration. These principles will increase the quality of the analysis and will help the analysis get trust from clients and stakeholders [https://www.geeksforgeeks.org/basic-principle-of-root-cause-analysis/[2]].&lt;br /&gt;
&lt;br /&gt;
*Consider to actually correct and remedy the root causes, not only the symptoms.&lt;br /&gt;
*While performing the root cause analysis, also remember to treat symptoms for short term fixing.&lt;br /&gt;
*Avoid focus on who was responsible of the failure or problem, instead focus on how and why.&lt;br /&gt;
*Find and document ways to prevent similar root causes in the future.&lt;br /&gt;
*When finding root causes, provide cause-effect evidence to back it up.&lt;br /&gt;
*Often there are multiple root causes, therefore search for several.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
As it can be understood from the principles above, it is important to take a comprehensive and holistic approach in this type of analysis. As the root causes have no importance if no action is taken afterwards, it should be strived to provide information and context that can solve the failure or problem.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Fishbone Diagram ===&lt;br /&gt;
A Fishbone diagram, which also is called an Ishikawa diagram, is used to identify root causes of quality problems. The fishbone diagram provides an organised way of looking at effects and causes. It can also be referred to as a cause-and-effect diagram. It generally represents a model of indicative presentation for the correlations between an event, which is an effect, and its several causes. This helps the team members get the same understanding of the problem, so that they can think systematically. The root causes of a problem can by using this structured approach be found, while encouraging group participation, utilising group knowledge and identifying areas where data should be collected for future studies. Hence the name, the diagram has the same structure as the skeleton of a fish. While it most often is used in a simple representation, with segments leaning on a horizontal axis, it can also be done with a more extensive approach. An example of this is by naming and coding of the risks which characterises the causes and sub-causes. This consists of elements that show the causes and sub-causes succession with different ways for risk treatment [https://www.researchgate.net/publication/46567642_Application_Of_Fishbone_Diagram_To_Determine_The_Risk_Of_An_Event_With_Multiple_Causes[3]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:A-generic-representation-of-the-Ishikawa-diagram-aka-Fishbone-diagram.png|400px|thumb|centre|Figure 2: Illustration of a Fishbone diagram]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Five steps should be followed to successful use the Fishbone diagram technique [https://www.ionos.ca/startupguide/productivity/fishbone-diagram/[4]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#The first step is to state the problem precisely. This problem statement must be carefully chosen, and it is important that it is specific enough.&lt;br /&gt;
#Define the main influencing factors. This is the factors are put in the horizontal category segments in the fishbone diagram. Different defects or problems have different influencing, which means that these should be chosen after what is relevant. Examples of these is seen in the figure above.&lt;br /&gt;
#State the causes into the diagram sorted after the different categories. This should be done with those employees that are directly involved in the problem causing processes. Also, the team should consist of a mix of different levels of expertise. When analysing the problem statement and finding causes, further sub-causes can be elaborated upon.&lt;br /&gt;
#Prioritise the causes. In the same team, make each person state their opinion as what is the most serious cause of the defect or problem. After a discussion about the causes, each person can give points to the causes that they believe are the most serious. The causes with the most points, should then be prioritised.&lt;br /&gt;
#Take measures. Tackle the defect or problem by eradicating the cause or causes. I it’s important that it is certain that the correct cause have been identified. To make sure of this, a significance test can be used for verifying, in order to select suitable methods for problem-solving.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== The 5 Whys ===&lt;br /&gt;
The 5 whys is a simple, yet powerful way of finding root causes. It works as an iterative interrogative technique to explore cause-and-effect relationship underlaying a particular problem. It is often used together with the a Fishbone diagram to find the root causes for the causes on the diagram.  As the name of technique implies, the primary goal is to find the root cause of a problem by asking “Why?” five times. Each answer of the “Whys” forms the basis for the next question, and when the fifth “Why?” have been answered, the root cause should be found. Five times is generally enough, but if the root cause still not is found, it could be repeated up to a total of six, seven or higher levels. For problems or defects that do not have one single root cause, the technique must be repeated asking a different sequence of questions each time [https://www.corship.eu/5-whys-method/[5]]. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:5-whys-example (1).png|500px|thumb|right|Figure 3: Example of a 5 whys analysis[https://www.corship.eu/5-whys-method/]]]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The five steps to conduct the 5 whys analysis, is to [https://www.adb.org/publications/five-whys-technique[6]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather a team who can develop a problem statement in agreement. At this point, it should be discussed whether additionally individuals are needed to resolve the problem. &lt;br /&gt;
#Make the team come with statements on “Why is this or that defect or problem taking place?”. This is the first “why” of the analysis. There are most probable multiple statements for this, and they should all be written down.&lt;br /&gt;
#Repeat the same process asking “why” four more times. This should be done for every statement from the first “why” in the structure like the figure below shows. All plausible answers should be written down. When the “why” does not yield further useful information, you have found the root cause. This means that is sometimes may take more than five layers to find the root cause.&lt;br /&gt;
#Among the many answers to the last asked “why”, look for systematic causes of the defect or problem. This should be discussed in the group to be able to settle for the most likely systematic cause. The product from the team session should then be showed to others to confirm that they see the same logic in the analysis.&lt;br /&gt;
#The last and final step of the 5 why analysis is to develop appropriate corrective actions to remove the root cause from the system. Others can undertake these actions but planning and implementation will benefit from inputs from the team.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===Pareto Chart Analysis===&lt;br /&gt;
[[File:Pareto output.png|400px|thumb|right|Figure 4: The 20/80 principle]]&lt;br /&gt;
The Pareto chart combines a histogram (bar chart) and a line chart, where cost or frequency of defects or problems show their relative importance. Frequencies are shown in the histogram with descending order of the bars, and the line chart shows the totals or the cumulative percentages increasing from left to right. It is based on the Pareto principle, which states that “80% of the effects or consequences come from 20% of the causes”. This is not like the immutable laws of physics but based on continuous observations. On those observations, it has showed to be applicable to many aspects of life and natural phenomena. In relation to a root cause analysis, the Pareto Chart Analysis helps identify the top 20% of the causes that needs to be addressed to resolve 80% of the problems [https://www.slideshare.net/himanshuhora/pareto-analysis-28873221[7]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;In order to perform a Pareto Chart Analysis, the following needs to be done [https://www.slideshare.net/himanshuhora/pareto-analysis-28873221[7]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather and collect data on the frequency of the causes of a defect or problem.&lt;br /&gt;
#Sort the causes after most to least important, and then calculate the cumulative percentage.&lt;br /&gt;
#Plot bars of the causes ordered from most to least frequent on the x-axis, and then plot the cumulative percentages on the y-axis. &lt;br /&gt;
#Finally, separate the 20% most important root causes from the rest by lifting the x-axis to the 80% cumulative percent on the y-axis.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:Pareto-chart-example.png|600px|thumb|left|Figure 5: An example of a Pareto Chart Analysis[https://www.whatissixsigma.net/pareto-chart-and-analysis/]]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Challenges and limitations ==&lt;br /&gt;
&lt;br /&gt;
For the Root Cause Analysis to give results, it is dependent on a larger problem-solving effort to improve the quality in a business. It therefore the managements responsibility to make the best use of the findings from the root cause analyses. The root cause analysis on itself would not provide the correct result. When it comes to the conduction of a root cause analysis, it is hard to fully know if you have taken every root cause into consideration. The reason for this is because there can be multiple root causes, and there is hard to tell when every root cause has been found. This can lead to too much time spent on irrelevant underlaying factors, which result in confusion and a waste of time. The 5 whys and the fishbone analysis does not rely on specific data, which can lead to less reliable results. The management can therefore have trouble entirely trusting these analyses. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Annotated Bibliography==&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The 5 whys by Olivier Serrat&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
The article “The Five Whys Technique” by Olivier Serrat, provides powerful knowledge within the use of the five “why” technique. It provides sufficient information both in relation to the background and meaning of using this technique, but also a step by step guide on how to use it in practice. This is very useful both for current and upcoming managers who will stumble upon a need to use this technique in real life. The article is short, which makes it quick to read. But if there is a need for further knowledge within the subject, reading material of high quality is referred to at the end of the article.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Root Cause Analysis: The Core of Problem Solving and Corrective Action by Duke Okes&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the book Root Cause Analysis: The Core of Problem Solving and Corrective Action, the author Duke Okes goes in-depth of the importance of using and how to use root cause analyses to catch the actual root causes of problems, and not only the symptoms of them. Different techniques to be implemented into a business are presented in detail so that the management in a company can reduce the amount of reoccurring problems. The terminology in this book is also simpler than most articles and research books, which makes it easy to read for the management.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
[https://www.tableau.com/learn/articles/root-cause-analysis [1]] Root Cause Analysis Explained: Definition, Examples, and Methods by Tableau&lt;br /&gt;
&lt;br /&gt;
[https://www.geeksforgeeks.org/basic-principle-of-root-cause-analysis/ [2]] Basic Principle of Root cause analysis by GeeksforGeeks&lt;br /&gt;
&lt;br /&gt;
[https://www.researchgate.net/publication/46567642_Application_Of_Fishbone_Diagram_To_Determine_The_Risk_Of_An_Event_With_Multiple_Causes [3]] Application Of Fishbone Diagram To Determine The Risk Of An Event With Multiple Causes by the UTI Grup SRL and the Academy of Economic Studies&lt;br /&gt;
&lt;br /&gt;
[https://www.ionos.ca/startupguide/productivity/fishbone-diagram/[4]] Fishbone diagram: Solving problems properly by IONOS&lt;br /&gt;
&lt;br /&gt;
[https://www.corship.eu/5-whys-method/ [5]] 5 Whys Method by CORSHIP – CORPORATE EDUPRENEURSHIP&lt;br /&gt;
&lt;br /&gt;
[https://www.adb.org/publications/five-whys-technique [6]] The Five Whys Technique by Olivier Serrat&lt;br /&gt;
&lt;br /&gt;
[https://www.slideshare.net/himanshuhora/pareto-analysis-28873221 [7]]Pareto Analysis by Dr. Himanshu Hora, SRMS College of Engineering &amp;amp; Technology Bareilly&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122306</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122306"/>
		<updated>2022-03-27T15:55:18Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;Developed by William Vossgård&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
==== Abstract ====&lt;br /&gt;
Root Cause Analysis (RCA) is a method of problem solving that can be used in a project, program or portfolio (PPP) to identify root causes of faults and problems in order to identify appropriate solutions. It is broadly used in several industries, among the health care, infrastructure and information technology industry. A Root Cause Analysis supposes that it is more effective to go in-depth of occurring problems, so that the underlaying issue can be treated, instead of only treating ad hoc symptoms. Root Cause Analyses can be performed with several different methodologies, principles and techniques together to identify the root causes of a fault or problem. The goal is to find out where processes or systems failed or caused an issue in the first place.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
To be able to fully understand what a root cause analysis is and what it is used for, it is easier to relate it to something we are entirely acknowledged with. If your arm hurts considerably after an accident, you will go to the doctor to find the root cause of your pain. Also, if your computer stops working, you will try to find the root cause of its malfunction, either by yourself or by a professional technician. For these examples, a simple remedy could be found for the symptoms. To stop your arm from hurting, you could put ice on it to relive pain. To get work done with a broken computer, you could use your phone or tablet instead. Unfortunately, this would only consider the symptoms and not the underlaying issue that caused the problem. The injured arm may need surgery to entirely recover from the sustained injury, and the broken computer may need to have a new battery to function again. The best way to solve a fault or problem would therefore be to perform a Root Cause Analysis. By doing this, the exact root cause can be found so that the correct management of the fault or problem will be accomplished.&lt;br /&gt;
There are a number of techniques and strategies that can be used for root cause analyses. In this article, the most commonly and widely used techniques will be covered.&lt;br /&gt;
&lt;br /&gt;
== Conducting a root cause analysis ==&lt;br /&gt;
&lt;br /&gt;
There is not one specific way of performing a root cause analysis as there are many different techniques and strategies that can be used. In this chapter, the most common and broadly used techniques will be covered. Root cause analyses gives the best effect when a team is gathered, to do the analysis together. In particular, it should be done with those employees, who are directly involved in the problem-causing processes.&lt;br /&gt;
&lt;br /&gt;
===== Goals and benefits =====&lt;br /&gt;
&lt;br /&gt;
Related to the root cause analysis, there are three goals that should be realised. The first one being to discover the root cause of a failure or problem. The second is to develop an understanding on how to fix and learn from the underlaying issues relating the root cause. The third and final is to apply the findings from the root cause analysis, to systematically prevent future issues or problems. The third goal is especially important as this is what gives the analysis a reason to be performed. Root cause analysis can be used for increasing the productiveness in several core processes as well, with the goal to prevent problems in the future. Instead of replacing punctured bike tires on rental bikes, puncture proof tires could be installed instead if the problem persists [https://www.tableau.com/learn/articles/root-cause-analysis [1]].&lt;br /&gt;
&lt;br /&gt;
===== General principles =====&lt;br /&gt;
&lt;br /&gt;
To achieve an effective root cause analysis process, there are some general principles that should be taken into consideration. These principles will increase the quality of the analysis and will help the analysis get trust from clients and stakeholders [https://www.geeksforgeeks.org/basic-principle-of-root-cause-analysis/[2]].&lt;br /&gt;
&lt;br /&gt;
*Consider to actually correct and remedy the root causes, not only the symptoms.&lt;br /&gt;
*While performing the root cause analysis, also remember to treat symptoms for short term fixing.&lt;br /&gt;
*Avoid focus on who was responsible of the failure or problem, instead focus on how and why.&lt;br /&gt;
*Find and document ways to prevent similar root causes in the future.&lt;br /&gt;
*When finding root causes, provide cause-effect evidence to back it up.&lt;br /&gt;
*Often there are multiple root causes, therefore search for several.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
As it can be understood from the principles above, it is important to take a comprehensive and holistic approach in this type of analysis. As the root causes have no importance if no action is taken afterwards, it should be strived to provide information and context that can solve the failure or problem.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Fishbone Diagram ===&lt;br /&gt;
A Fishbone diagram, which also is called an Ishikawa diagram, is used to identify root causes of quality problems. The fishbone diagram provides an organised way of looking at effects and causes. It can also be referred to as a cause-and-effect diagram. It generally represents a model of indicative presentation for the correlations between an event, which is an effect, and its several causes. This helps the team members get the same understanding of the problem, so that they can think systematically. The root causes of a problem can by using this structured approach be found, while encouraging group participation, utilising group knowledge and identifying areas where data should be collected for future studies. Hence the name, the diagram has the same structure as the skeleton of a fish. While it most often is used in a simple representation, with segments leaning on a horizontal axis, it can also be done with a more extensive approach. An example of this is by naming and coding of the risks which characterises the causes and sub-causes. This consists of elements that show the causes and sub-causes succession with different ways for risk treatment [https://www.researchgate.net/publication/46567642_Application_Of_Fishbone_Diagram_To_Determine_The_Risk_Of_An_Event_With_Multiple_Causes[3]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:A-generic-representation-of-the-Ishikawa-diagram-aka-Fishbone-diagram.png|400px|thumb|centre|Figure 2: Illustration of a Fishbone diagram]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Five steps should be followed to successful use the Fishbone diagram technique [https://www.ionos.ca/startupguide/productivity/fishbone-diagram/[4]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#The first step is to state the problem precisely. This problem statement must be carefully chosen, and it is important that it is specific enough.&lt;br /&gt;
#Define the main influencing factors. This is the factors are put in the horizontal category segments in the fishbone diagram. Different defects or problems have different influencing, which means that these should be chosen after what is relevant. Examples of these is seen in the figure above.&lt;br /&gt;
#State the causes into the diagram sorted after the different categories. This should be done with those employees that are directly involved in the problem causing processes. Also, the team should consist of a mix of different levels of expertise. When analysing the problem statement and finding causes, further sub-causes can be elaborated upon.&lt;br /&gt;
#Prioritise the causes. In the same team, make each person state their opinion as what is the most serious cause of the defect or problem. After a discussion about the causes, each person can give points to the causes that they believe are the most serious. The causes with the most points, should then be prioritised.&lt;br /&gt;
#Take measures. Tackle the defect or problem by eradicating the cause or causes. I it’s important that it is certain that the correct cause have been identified. To make sure of this, a significance test can be used for verifying, in order to select suitable methods for problem-solving.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== The 5 Whys ===&lt;br /&gt;
The 5 whys is a simple, yet powerful way of finding root causes. It works as an iterative interrogative technique to explore cause-and-effect relationship underlaying a particular problem. It is often used together with the a Fishbone diagram to find the root causes for the causes on the diagram.  As the name of technique implies, the primary goal is to find the root cause of a problem by asking “Why?” five times. Each answer of the “Whys” forms the basis for the next question, and when the fifth “Why?” have been answered, the root cause should be found. Five times is generally enough, but if the root cause still not is found, it could be repeated up to a total of six, seven or higher levels. For problems or defects that do not have one single root cause, the technique must be repeated asking a different sequence of questions each time [https://www.corship.eu/5-whys-method/[5]]. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:5-whys-example (1).png|500px|thumb|right|Figure 3: Example of a 5 whys analysis[https://www.corship.eu/5-whys-method/]]]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The five steps to conduct the 5 whys analysis, is to [https://www.adb.org/publications/five-whys-technique[6]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather a team who can develop a problem statement in agreement. At this point, it should be discussed whether additionally individuals are needed to resolve the problem. &lt;br /&gt;
#Make the team come with statements on “Why is this or that defect or problem taking place?”. This is the first “why” of the analysis. There are most probable multiple statements for this, and they should all be written down.&lt;br /&gt;
#Repeat the same process asking “why” four more times. This should be done for every statement from the first “why” in the structure like the figure below shows. All plausible answers should be written down. When the “why” does not yield further useful information, you have found the root cause. This means that is sometimes may take more than five layers to find the root cause.&lt;br /&gt;
#Among the many answers to the last asked “why”, look for systematic causes of the defect or problem. This should be discussed in the group to be able to settle for the most likely systematic cause. The product from the team session should then be showed to others to confirm that they see the same logic in the analysis.&lt;br /&gt;
#The last and final step of the 5 why analysis is to develop appropriate corrective actions to remove the root cause from the system. Others can undertake these actions but planning and implementation will benefit from inputs from the team.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===Pareto Chart Analysis===&lt;br /&gt;
[[File:Pareto output.png|400px|thumb|right|Figure 4: The 20/80 principle]]&lt;br /&gt;
The Pareto chart combines a histogram (bar chart) and a line chart, where cost or frequency of defects or problems show their relative importance. Frequencies are shown in the histogram with descending order of the bars, and the line chart shows the totals or the cumulative percentages increasing from left to right. It is based on the Pareto principle, which states that “80% of the effects or consequences come from 20% of the causes”. This is not like the immutable laws of physics but based on continuous observations. On those observations, it has showed to be applicable to many aspects of life and natural phenomena. In relation to a root cause analysis, the Pareto Chart Analysis helps identify the top 20% of the causes that needs to be addressed to resolve 80% of the problems [https://www.slideshare.net/himanshuhora/pareto-analysis-28873221[7]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;In order to perform a Pareto Chart Analysis, the following needs to be done [https://www.slideshare.net/himanshuhora/pareto-analysis-28873221[7]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather and collect data on the frequency of the causes of a defect or problem.&lt;br /&gt;
#Sort the causes after most to least important, and then calculate the cumulative percentage.&lt;br /&gt;
#Plot bars of the causes ordered from most to least frequent on the x-axis, and then plot the cumulative percentages on the y-axis. &lt;br /&gt;
#Finally, separate the 20% most important root causes from the rest by lifting the x-axis to the 80% cumulative percent on the y-axis.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:Pareto-chart-example.png|600px|thumb|left|Figure 5: An example of a Pareto Chart Analysis[https://www.whatissixsigma.net/pareto-chart-and-analysis/]]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Challenges and limitations ==&lt;br /&gt;
&lt;br /&gt;
For the Root Cause Analysis to give results, it is dependent on a larger problem-solving effort to improve the quality in a business. It therefore the managements responsibility to make the best use of the findings from the root cause analyses. The root cause analysis on itself would not provide the correct result. When it comes to the conduction of a root cause analysis, it is hard to fully know if you have taken every root cause into consideration. The reason for this is because there can be multiple root causes, and there is hard to tell when every root cause has been found. This can lead to too much time spent on irrelevant underlaying factors, which result in confusion and a waste of time. The 5 whys and the fishbone analysis does not rely on specific data, which can lead to less reliable results. The management can therefore have trouble entirely trusting these analyses. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Annotated Bibliography==&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The 5 whys by Olivier Serrat&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
The article “The Five Whys Technique” by Olivier Serrat, provides powerful knowledge within the use of the five “why” technique. It provides sufficient information both in relation to the background and meaning of using this technique, but also a step by step guide on how to use it in practice. This is very useful both for current and upcoming managers who will stumble upon a need to use this technique in real life. The article is short, which makes it quick to read. But if there is a need for further knowledge within the subject, reading material of high quality is referred to at the end of the article.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Root Cause Analysis: The Core of Problem Solving and Corrective Action by Duke Okes&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the book Root Cause Analysis: The Core of Problem Solving and Corrective Action, the author Duke Okes goes in-depth of the importance of using and how to use root cause analyses to catch the actual root causes of problems, and not only the symptoms of them. Different techniques to be implemented into a business are presented in detail so that the management in a company can reduce reoccurring problems. The terminology in this book is simpler than most traditional articles and other research books, which makes it easier to read for the management.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
[https://www.tableau.com/learn/articles/root-cause-analysis [1]] Root Cause Analysis Explained: Definition, Examples, and Methods by Tableau&lt;br /&gt;
&lt;br /&gt;
[https://www.geeksforgeeks.org/basic-principle-of-root-cause-analysis/ [2]] Basic Principle of Root cause analysis by GeeksforGeeks&lt;br /&gt;
&lt;br /&gt;
[https://www.researchgate.net/publication/46567642_Application_Of_Fishbone_Diagram_To_Determine_The_Risk_Of_An_Event_With_Multiple_Causes [3]] Application Of Fishbone Diagram To Determine The Risk Of An Event With Multiple Causes by the UTI Grup SRL and the Academy of Economic Studies&lt;br /&gt;
&lt;br /&gt;
[https://www.ionos.ca/startupguide/productivity/fishbone-diagram/[4]] Fishbone diagram: Solving problems properly by IONOS&lt;br /&gt;
&lt;br /&gt;
[https://www.corship.eu/5-whys-method/ [5]] 5 Whys Method by CORSHIP – CORPORATE EDUPRENEURSHIP&lt;br /&gt;
&lt;br /&gt;
[https://www.adb.org/publications/five-whys-technique [6]] The Five Whys Technique by Olivier Serrat&lt;br /&gt;
&lt;br /&gt;
[https://www.slideshare.net/himanshuhora/pareto-analysis-28873221 [7]]Pareto Analysis by Dr. Himanshu Hora, SRMS College of Engineering &amp;amp; Technology Bareilly&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122302</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122302"/>
		<updated>2022-03-27T15:38:27Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: /* Annotated Bibliography */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;Developed by William Vossgård&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
==== Abstract ====&lt;br /&gt;
Root Cause Analysis (RCA) is a method of problem solving that can be used in a project, program or portfolio (PPP) to identify root causes of faults and problems in order to identify appropriate solutions. It is broadly used in several industries, among the health care, infrastructure and information technology industry. A Root Cause Analysis supposes that it is more effective to go in-depth of occurring problems, so that the underlaying issue can be treated, instead of only treating ad hoc symptoms. Root Cause Analyses can be performed with several different methodologies, principles and techniques together to identify the root causes of a fault or problem. The goal is to find out where processes or systems failed or caused an issue in the first place.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
To be able to fully understand what a root cause analysis is and what it is used for, it is easier to relate it to something we are entirely acknowledged with. If your arm hurts considerably after an accident, you will go to the doctor to find the root cause of your pain. Also, if your computer stops working, you will try to find the root cause of its malfunction, either by yourself or by a professional technician. For these examples, a simple remedy could be found for the symptoms. To stop your arm from hurting, you could put ice on it to relive pain. To get work done with a broken computer, you could use your phone or tablet instead. Unfortunately, this would only consider the symptoms and not the underlaying issue that caused the problem. The injured arm may need surgery to entirely recover from the sustained injury, and the broken computer may need to have a new battery to function again. The best way to solve a fault or problem would therefore be to perform a Root Cause Analysis. By doing this, the exact root cause can be found so that the correct management of the fault or problem will be accomplished.&lt;br /&gt;
There are a number of techniques and strategies that can be used for root cause analyses. In this article, the most commonly and widely used techniques will be covered.&lt;br /&gt;
&lt;br /&gt;
== Conducting a root cause analysis ==&lt;br /&gt;
&lt;br /&gt;
There is not one specific way of performing a root cause analysis as there are many different techniques and strategies that can be used. In this chapter, the most common and broadly used techniques will be covered. Root cause analyses gives the best effect when a team is gathered, to do the analysis together. In particular, it should be done with those employees, who are directly involved in the problem-causing processes.&lt;br /&gt;
&lt;br /&gt;
===== Goals and benefits =====&lt;br /&gt;
&lt;br /&gt;
Related to the root cause analysis, there are three goals that should be realised. The first one being to discover the root cause of a failure or problem. The second is to develop an understanding on how to fix and learn from the underlaying issues relating the root cause. The third and final is to apply the findings from the root cause analysis, to systematically prevent future issues or problems. The third goal is especially important as this is what gives the analysis a reason to be performed. Root cause analysis can be used for increasing the productiveness in several core processes as well, with the goal to prevent problems in the future. Instead of replacing punctured bike tires on rental bikes, puncture proof tires could be installed instead if the problem persists [https://www.tableau.com/learn/articles/root-cause-analysis [1]].&lt;br /&gt;
&lt;br /&gt;
===== General principles =====&lt;br /&gt;
&lt;br /&gt;
To achieve an effective root cause analysis process, there are some general principles that should be taken into consideration. These principles will increase the quality of the analysis and will help the analysis get trust from clients and stakeholders [https://www.geeksforgeeks.org/basic-principle-of-root-cause-analysis/[2]].&lt;br /&gt;
&lt;br /&gt;
*Consider to actually correct and remedy the root causes, not only the symptoms.&lt;br /&gt;
*While performing the root cause analysis, also remember to treat symptoms for short term fixing.&lt;br /&gt;
*Avoid focus on who was responsible of the failure or problem, instead focus on how and why.&lt;br /&gt;
*Find and document ways to prevent similar root causes in the future.&lt;br /&gt;
*When finding root causes, provide cause-effect evidence to back it up.&lt;br /&gt;
*Often there are multiple root causes, therefore search for several.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
As it can be understood from the principles above, it is important to take a comprehensive and holistic approach in this type of analysis. As the root causes have no importance if no action is taken afterwards, it should be strived to provide information and context that can solve the failure or problem.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Fishbone Diagram ===&lt;br /&gt;
A Fishbone diagram, which also is called an Ishikawa diagram, is used to identify root causes of quality problems. The fishbone diagram provides an organised way of looking at effects and causes. It can also be referred to as a cause-and-effect diagram. It generally represents a model of indicative presentation for the correlations between an event, which is an effect, and its several causes. This helps the team members get the same understanding of the problem, so that they can think systematically. The root causes of a problem can by using this structured approach be found, while encouraging group participation, utilising group knowledge and identifying areas where data should be collected for future studies. Hence the name, the diagram has the same structure as the skeleton of a fish. While it most often is used in a simple representation, with segments leaning on a horizontal axis, it can also be done with a more extensive approach. An example of this is by naming and coding of the risks which characterises the causes and sub-causes. This consists of elements that show the causes and sub-causes succession with different ways for risk treatment [https://www.researchgate.net/publication/46567642_Application_Of_Fishbone_Diagram_To_Determine_The_Risk_Of_An_Event_With_Multiple_Causes[3]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:A-generic-representation-of-the-Ishikawa-diagram-aka-Fishbone-diagram.png|400px|thumb|centre|Figure 2: Illustration of a Fishbone diagram]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Five steps should be followed to successful use the Fishbone diagram technique [https://www.ionos.ca/startupguide/productivity/fishbone-diagram/[4]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#The first step is to state the problem precisely. This problem statement must be carefully chosen, and it is important that it is specific enough.&lt;br /&gt;
#Define the main influencing factors. This is the factors are put in the horizontal category segments in the fishbone diagram. Different defects or problems have different influencing, which means that these should be chosen after what is relevant. Examples of these is seen in the figure above.&lt;br /&gt;
#State the causes into the diagram sorted after the different categories. This should be done with those employees that are directly involved in the problem causing processes. Also, the team should consist of a mix of different levels of expertise. When analysing the problem statement and finding causes, further sub-causes can be elaborated upon.&lt;br /&gt;
#Prioritise the causes. In the same team, make each person state their opinion as what is the most serious cause of the defect or problem. After a discussion about the causes, each person can give points to the causes that they believe are the most serious. The causes with the most points, should then be prioritised.&lt;br /&gt;
#Take measures. Tackle the defect or problem by eradicating the cause or causes. I it’s important that it is certain that the correct cause have been identified. To make sure of this, a significance test can be used for verifying, in order to select suitable methods for problem-solving.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== The 5 Whys ===&lt;br /&gt;
The 5 whys is a simple, yet powerful way of finding root causes. It works as an iterative interrogative technique to explore cause-and-effect relationship underlaying a particular problem. It is often used together with the a Fishbone diagram to find the root causes for the causes on the diagram.  As the name of technique implies, the primary goal is to find the root cause of a problem by asking “Why?” five times. Each answer of the “Whys” forms the basis for the next question, and when the fifth “Why?” have been answered, the root cause should be found. Five times is generally enough, but if the root cause still not is found, it could be repeated up to a total of six, seven or higher levels. For problems or defects that do not have one single root cause, the technique must be repeated asking a different sequence of questions each time [https://www.corship.eu/5-whys-method/[5]]. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:5-whys-example (1).png|500px|thumb|right|Figure 3: Example of a 5 whys analysis[https://www.corship.eu/5-whys-method/]]]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The five steps to conduct the 5 whys analysis, is to [https://www.adb.org/publications/five-whys-technique[6]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather a team who can develop a problem statement in agreement. At this point, it should be discussed whether additionally individuals are needed to resolve the problem. &lt;br /&gt;
#Make the team come with statements on “Why is this or that defect or problem taking place?”. This is the first “why” of the analysis. There are most probable multiple statements for this, and they should all be written down.&lt;br /&gt;
#Repeat the same process asking “why” four more times. This should be done for every statement from the first “why” in the structure like the figure below shows. All plausible answers should be written down. When the “why” does not yield further useful information, you have found the root cause. This means that is sometimes may take more than five layers to find the root cause.&lt;br /&gt;
#Among the many answers to the last asked “why”, look for systematic causes of the defect or problem. This should be discussed in the group to be able to settle for the most likely systematic cause. The product from the team session should then be showed to others to confirm that they see the same logic in the analysis.&lt;br /&gt;
#The last and final step of the 5 why analysis is to develop appropriate corrective actions to remove the root cause from the system. Others can undertake these actions but planning and implementation will benefit from inputs from the team.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===Pareto Chart Analysis===&lt;br /&gt;
[[File:Pareto output.png|400px|thumb|right|Figure 4: The 20/80 principle]]&lt;br /&gt;
The Pareto chart combines a histogram (bar chart) and a line chart, where cost or frequency of defects or problems show their relative importance. Frequencies are shown in the histogram with descending order of the bars, and the line chart shows the totals or the cumulative percentages increasing from left to right. It is based on the Pareto principle, which states that “80% of the effects or consequences come from 20% of the causes”. This is not like the immutable laws of physics but based on continuous observations. On those observations, it has showed to be applicable to many aspects of life and natural phenomena. In relation to a root cause analysis, the Pareto Chart Analysis helps identify the top 20% of the causes that needs to be addressed to resolve 80% of the problems [https://www.slideshare.net/himanshuhora/pareto-analysis-28873221[7]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;In order to perform a Pareto Chart Analysis, the following needs to be done [https://www.slideshare.net/himanshuhora/pareto-analysis-28873221[7]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather and collect data on the frequency of the causes of a defect or problem.&lt;br /&gt;
#Sort the causes after most to least important, and then calculate the cumulative percentage.&lt;br /&gt;
#Plot bars of the causes ordered from most to least frequent on the x-axis, and then plot the cumulative percentages on the y-axis. &lt;br /&gt;
#Finally, separate the 20% most important root causes from the rest by lifting the x-axis to the 80% cumulative percent on the y-axis.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:Pareto-chart-example.png|600px|thumb|left|Figure 5: An example of a Pareto Chart Analysis[https://www.whatissixsigma.net/pareto-chart-and-analysis/]]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Challenges and limitations ==&lt;br /&gt;
&lt;br /&gt;
For the Root Cause Analysis to give results, it is dependent on a larger problem-solving effort to improve the quality in a business. It therefore the managements responsibility to make the best use of the findings from the root cause analyses. The root cause analysis on itself would not provide the correct result. When it comes to the conduction of a root cause analysis, it is hard to fully know if you have taken every root cause into consideration. The reason for this is because there can be multiple root causes, and there is hard to tell when every root cause has been found. This can lead to too much time spent on irrelevant underlaying factors, which result in confusion and a waste of time. The 5 whys and the fishbone analysis does not rely on specific data, which can lead to less reliable results. The management can therefore have trouble entirely trusting these analyses. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Annotated Bibliography==&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The 5 whys by Olivier Serrat&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
The article “The Five Whys Technique” by Olivier Serrat, provides powerful knowledge within the use of the five “why” technique. It provides sufficient information both in relation to the background and meaning of using this technique, but also a step by step guide on how to use it in practice. This is very useful both for current and upcoming managers who will stumble upon a need to use this technique in real life. The article is short, which makes it quick to read. But if there is a need for further knowledge within the subject, reading material of high quality is referred to at the end of the article.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
[https://www.tableau.com/learn/articles/root-cause-analysis [1]] Root Cause Analysis Explained: Definition, Examples, and Methods by Tableau&lt;br /&gt;
&lt;br /&gt;
[https://www.geeksforgeeks.org/basic-principle-of-root-cause-analysis/ [2]] Basic Principle of Root cause analysis by GeeksforGeeks&lt;br /&gt;
&lt;br /&gt;
[https://www.researchgate.net/publication/46567642_Application_Of_Fishbone_Diagram_To_Determine_The_Risk_Of_An_Event_With_Multiple_Causes [3]] Application Of Fishbone Diagram To Determine The Risk Of An Event With Multiple Causes by the UTI Grup SRL and the Academy of Economic Studies&lt;br /&gt;
&lt;br /&gt;
[https://www.ionos.ca/startupguide/productivity/fishbone-diagram/[4]] Fishbone diagram: Solving problems properly by IONOS&lt;br /&gt;
&lt;br /&gt;
[https://www.corship.eu/5-whys-method/ [5]] 5 Whys Method by CORSHIP – CORPORATE EDUPRENEURSHIP&lt;br /&gt;
&lt;br /&gt;
[https://www.adb.org/publications/five-whys-technique [6]] The Five Whys Technique by Olivier Serrat&lt;br /&gt;
&lt;br /&gt;
[https://www.slideshare.net/himanshuhora/pareto-analysis-28873221 [7]]Pareto Analysis by Dr. Himanshu Hora, SRMS College of Engineering &amp;amp; Technology Bareilly&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122299</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122299"/>
		<updated>2022-03-27T15:17:24Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: /* References */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;Developed by William Vossgård&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
==== Abstract ====&lt;br /&gt;
Root Cause Analysis (RCA) is a method of problem solving that can be used in a project, program or portfolio (PPP) to identify root causes of faults and problems in order to identify appropriate solutions. It is broadly used in several industries, among the health care, infrastructure and information technology industry. A Root Cause Analysis supposes that it is more effective to go in-depth of occurring problems, so that the underlaying issue can be treated, instead of only treating ad hoc symptoms. Root Cause Analyses can be performed with several different methodologies, principles and techniques together to identify the root causes of a fault or problem. The goal is to find out where processes or systems failed or caused an issue in the first place.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
To be able to fully understand what a root cause analysis is and what it is used for, it is easier to relate it to something we are entirely acknowledged with. If your arm hurts considerably after an accident, you will go to the doctor to find the root cause of your pain. Also, if your computer stops working, you will try to find the root cause of its malfunction, either by yourself or by a professional technician. For these examples, a simple remedy could be found for the symptoms. To stop your arm from hurting, you could put ice on it to relive pain. To get work done with a broken computer, you could use your phone or tablet instead. Unfortunately, this would only consider the symptoms and not the underlaying issue that caused the problem. The injured arm may need surgery to entirely recover from the sustained injury, and the broken computer may need to have a new battery to function again. The best way to solve a fault or problem would therefore be to perform a Root Cause Analysis. By doing this, the exact root cause can be found so that the correct management of the fault or problem will be accomplished.&lt;br /&gt;
There are a number of techniques and strategies that can be used for root cause analyses. In this article, the most commonly and widely used techniques will be covered.&lt;br /&gt;
&lt;br /&gt;
== Conducting a root cause analysis ==&lt;br /&gt;
&lt;br /&gt;
There is not one specific way of performing a root cause analysis as there are many different techniques and strategies that can be used. In this chapter, the most common and broadly used techniques will be covered. Root cause analyses gives the best effect when a team is gathered, to do the analysis together. In particular, it should be done with those employees, who are directly involved in the problem-causing processes.&lt;br /&gt;
&lt;br /&gt;
===== Goals and benefits =====&lt;br /&gt;
&lt;br /&gt;
Related to the root cause analysis, there are three goals that should be realised. The first one being to discover the root cause of a failure or problem. The second is to develop an understanding on how to fix and learn from the underlaying issues relating the root cause. The third and final is to apply the findings from the root cause analysis, to systematically prevent future issues or problems. The third goal is especially important as this is what gives the analysis a reason to be performed. Root cause analysis can be used for increasing the productiveness in several core processes as well, with the goal to prevent problems in the future. Instead of replacing punctured bike tires on rental bikes, puncture proof tires could be installed instead if the problem persists [https://www.tableau.com/learn/articles/root-cause-analysis [1]].&lt;br /&gt;
&lt;br /&gt;
===== General principles =====&lt;br /&gt;
&lt;br /&gt;
To achieve an effective root cause analysis process, there are some general principles that should be taken into consideration. These principles will increase the quality of the analysis and will help the analysis get trust from clients and stakeholders [https://www.geeksforgeeks.org/basic-principle-of-root-cause-analysis/[2]].&lt;br /&gt;
&lt;br /&gt;
*Consider to actually correct and remedy the root causes, not only the symptoms.&lt;br /&gt;
*While performing the root cause analysis, also remember to treat symptoms for short term fixing.&lt;br /&gt;
*Avoid focus on who was responsible of the failure or problem, instead focus on how and why.&lt;br /&gt;
*Find and document ways to prevent similar root causes in the future.&lt;br /&gt;
*When finding root causes, provide cause-effect evidence to back it up.&lt;br /&gt;
*Often there are multiple root causes, therefore search for several.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
As it can be understood from the principles above, it is important to take a comprehensive and holistic approach in this type of analysis. As the root causes have no importance if no action is taken afterwards, it should be strived to provide information and context that can solve the failure or problem.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Fishbone Diagram ===&lt;br /&gt;
A Fishbone diagram, which also is called an Ishikawa diagram, is used to identify root causes of quality problems. The fishbone diagram provides an organised way of looking at effects and causes. It can also be referred to as a cause-and-effect diagram. It generally represents a model of indicative presentation for the correlations between an event, which is an effect, and its several causes. This helps the team members get the same understanding of the problem, so that they can think systematically. The root causes of a problem can by using this structured approach be found, while encouraging group participation, utilising group knowledge and identifying areas where data should be collected for future studies. Hence the name, the diagram has the same structure as the skeleton of a fish. While it most often is used in a simple representation, with segments leaning on a horizontal axis, it can also be done with a more extensive approach. An example of this is by naming and coding of the risks which characterises the causes and sub-causes. This consists of elements that show the causes and sub-causes succession with different ways for risk treatment [https://www.researchgate.net/publication/46567642_Application_Of_Fishbone_Diagram_To_Determine_The_Risk_Of_An_Event_With_Multiple_Causes[3]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:A-generic-representation-of-the-Ishikawa-diagram-aka-Fishbone-diagram.png|400px|thumb|centre|Figure 2: Illustration of a Fishbone diagram]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Five steps should be followed to successful use the Fishbone diagram technique [https://www.ionos.ca/startupguide/productivity/fishbone-diagram/[4]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#The first step is to state the problem precisely. This problem statement must be carefully chosen, and it is important that it is specific enough.&lt;br /&gt;
#Define the main influencing factors. This is the factors are put in the horizontal category segments in the fishbone diagram. Different defects or problems have different influencing, which means that these should be chosen after what is relevant. Examples of these is seen in the figure above.&lt;br /&gt;
#State the causes into the diagram sorted after the different categories. This should be done with those employees that are directly involved in the problem causing processes. Also, the team should consist of a mix of different levels of expertise. When analysing the problem statement and finding causes, further sub-causes can be elaborated upon.&lt;br /&gt;
#Prioritise the causes. In the same team, make each person state their opinion as what is the most serious cause of the defect or problem. After a discussion about the causes, each person can give points to the causes that they believe are the most serious. The causes with the most points, should then be prioritised.&lt;br /&gt;
#Take measures. Tackle the defect or problem by eradicating the cause or causes. I it’s important that it is certain that the correct cause have been identified. To make sure of this, a significance test can be used for verifying, in order to select suitable methods for problem-solving.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== The 5 Whys ===&lt;br /&gt;
The 5 whys is a simple, yet powerful way of finding root causes. It works as an iterative interrogative technique to explore cause-and-effect relationship underlaying a particular problem. It is often used together with the a Fishbone diagram to find the root causes for the causes on the diagram.  As the name of technique implies, the primary goal is to find the root cause of a problem by asking “Why?” five times. Each answer of the “Whys” forms the basis for the next question, and when the fifth “Why?” have been answered, the root cause should be found. Five times is generally enough, but if the root cause still not is found, it could be repeated up to a total of six, seven or higher levels. For problems or defects that do not have one single root cause, the technique must be repeated asking a different sequence of questions each time [https://www.corship.eu/5-whys-method/[5]]. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:5-whys-example (1).png|500px|thumb|right|Figure 3: Example of a 5 whys analysis[https://www.corship.eu/5-whys-method/]]]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The five steps to conduct the 5 whys analysis, is to [https://www.adb.org/publications/five-whys-technique[6]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather a team who can develop a problem statement in agreement. At this point, it should be discussed whether additionally individuals are needed to resolve the problem. &lt;br /&gt;
#Make the team come with statements on “Why is this or that defect or problem taking place?”. This is the first “why” of the analysis. There are most probable multiple statements for this, and they should all be written down.&lt;br /&gt;
#Repeat the same process asking “why” four more times. This should be done for every statement from the first “why” in the structure like the figure below shows. All plausible answers should be written down. When the “why” does not yield further useful information, you have found the root cause. This means that is sometimes may take more than five layers to find the root cause.&lt;br /&gt;
#Among the many answers to the last asked “why”, look for systematic causes of the defect or problem. This should be discussed in the group to be able to settle for the most likely systematic cause. The product from the team session should then be showed to others to confirm that they see the same logic in the analysis.&lt;br /&gt;
#The last and final step of the 5 why analysis is to develop appropriate corrective actions to remove the root cause from the system. Others can undertake these actions but planning and implementation will benefit from inputs from the team.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===Pareto Chart Analysis===&lt;br /&gt;
[[File:Pareto output.png|400px|thumb|right|Figure 4: The 20/80 principle]]&lt;br /&gt;
The Pareto chart combines a histogram (bar chart) and a line chart, where cost or frequency of defects or problems show their relative importance. Frequencies are shown in the histogram with descending order of the bars, and the line chart shows the totals or the cumulative percentages increasing from left to right. It is based on the Pareto principle, which states that “80% of the effects or consequences come from 20% of the causes”. This is not like the immutable laws of physics but based on continuous observations. On those observations, it has showed to be applicable to many aspects of life and natural phenomena. In relation to a root cause analysis, the Pareto Chart Analysis helps identify the top 20% of the causes that needs to be addressed to resolve 80% of the problems [https://www.slideshare.net/himanshuhora/pareto-analysis-28873221[7]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;In order to perform a Pareto Chart Analysis, the following needs to be done [https://www.slideshare.net/himanshuhora/pareto-analysis-28873221[7]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather and collect data on the frequency of the causes of a defect or problem.&lt;br /&gt;
#Sort the causes after most to least important, and then calculate the cumulative percentage.&lt;br /&gt;
#Plot bars of the causes ordered from most to least frequent on the x-axis, and then plot the cumulative percentages on the y-axis. &lt;br /&gt;
#Finally, separate the 20% most important root causes from the rest by lifting the x-axis to the 80% cumulative percent on the y-axis.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:Pareto-chart-example.png|600px|thumb|left|Figure 5: An example of a Pareto Chart Analysis[https://www.whatissixsigma.net/pareto-chart-and-analysis/]]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Challenges and limitations ==&lt;br /&gt;
&lt;br /&gt;
For the Root Cause Analysis to give results, it is dependent on a larger problem-solving effort to improve the quality in a business. It therefore the managements responsibility to make the best use of the findings from the root cause analyses. The root cause analysis on itself would not provide the correct result. When it comes to the conduction of a root cause analysis, it is hard to fully know if you have taken every root cause into consideration. The reason for this is because there can be multiple root causes, and there is hard to tell when every root cause has been found. This can lead to too much time spent on irrelevant underlaying factors, which result in confusion and a waste of time. The 5 whys and the fishbone analysis does not rely on specific data, which can lead to less reliable results. The management can therefore have trouble entirely trusting these analyses. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Annotated Bibliography==&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
[https://www.tableau.com/learn/articles/root-cause-analysis [1]] Root Cause Analysis Explained: Definition, Examples, and Methods by Tableau&lt;br /&gt;
&lt;br /&gt;
[https://www.geeksforgeeks.org/basic-principle-of-root-cause-analysis/ [2]] Basic Principle of Root cause analysis by GeeksforGeeks&lt;br /&gt;
&lt;br /&gt;
[https://www.researchgate.net/publication/46567642_Application_Of_Fishbone_Diagram_To_Determine_The_Risk_Of_An_Event_With_Multiple_Causes [3]] Application Of Fishbone Diagram To Determine The Risk Of An Event With Multiple Causes by the UTI Grup SRL and the Academy of Economic Studies&lt;br /&gt;
&lt;br /&gt;
[https://www.ionos.ca/startupguide/productivity/fishbone-diagram/[4]] Fishbone diagram: Solving problems properly by IONOS&lt;br /&gt;
&lt;br /&gt;
[https://www.corship.eu/5-whys-method/ [5]] 5 Whys Method by CORSHIP – CORPORATE EDUPRENEURSHIP&lt;br /&gt;
&lt;br /&gt;
[https://www.adb.org/publications/five-whys-technique [6]] The Five Whys Technique by Olivier Serrat&lt;br /&gt;
&lt;br /&gt;
[https://www.slideshare.net/himanshuhora/pareto-analysis-28873221 [7]]Pareto Analysis by Dr. Himanshu Hora, SRMS College of Engineering &amp;amp; Technology Bareilly&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122298</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122298"/>
		<updated>2022-03-27T15:07:00Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;Developed by William Vossgård&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
==== Abstract ====&lt;br /&gt;
Root Cause Analysis (RCA) is a method of problem solving that can be used in a project, program or portfolio (PPP) to identify root causes of faults and problems in order to identify appropriate solutions. It is broadly used in several industries, among the health care, infrastructure and information technology industry. A Root Cause Analysis supposes that it is more effective to go in-depth of occurring problems, so that the underlaying issue can be treated, instead of only treating ad hoc symptoms. Root Cause Analyses can be performed with several different methodologies, principles and techniques together to identify the root causes of a fault or problem. The goal is to find out where processes or systems failed or caused an issue in the first place.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
To be able to fully understand what a root cause analysis is and what it is used for, it is easier to relate it to something we are entirely acknowledged with. If your arm hurts considerably after an accident, you will go to the doctor to find the root cause of your pain. Also, if your computer stops working, you will try to find the root cause of its malfunction, either by yourself or by a professional technician. For these examples, a simple remedy could be found for the symptoms. To stop your arm from hurting, you could put ice on it to relive pain. To get work done with a broken computer, you could use your phone or tablet instead. Unfortunately, this would only consider the symptoms and not the underlaying issue that caused the problem. The injured arm may need surgery to entirely recover from the sustained injury, and the broken computer may need to have a new battery to function again. The best way to solve a fault or problem would therefore be to perform a Root Cause Analysis. By doing this, the exact root cause can be found so that the correct management of the fault or problem will be accomplished.&lt;br /&gt;
There are a number of techniques and strategies that can be used for root cause analyses. In this article, the most commonly and widely used techniques will be covered.&lt;br /&gt;
&lt;br /&gt;
== Conducting a root cause analysis ==&lt;br /&gt;
&lt;br /&gt;
There is not one specific way of performing a root cause analysis as there are many different techniques and strategies that can be used. In this chapter, the most common and broadly used techniques will be covered. Root cause analyses gives the best effect when a team is gathered, to do the analysis together. In particular, it should be done with those employees, who are directly involved in the problem-causing processes.&lt;br /&gt;
&lt;br /&gt;
===== Goals and benefits =====&lt;br /&gt;
&lt;br /&gt;
Related to the root cause analysis, there are three goals that should be realised. The first one being to discover the root cause of a failure or problem. The second is to develop an understanding on how to fix and learn from the underlaying issues relating the root cause. The third and final is to apply the findings from the root cause analysis, to systematically prevent future issues or problems. The third goal is especially important as this is what gives the analysis a reason to be performed. Root cause analysis can be used for increasing the productiveness in several core processes as well, with the goal to prevent problems in the future. Instead of replacing punctured bike tires on rental bikes, puncture proof tires could be installed instead if the problem persists [https://www.tableau.com/learn/articles/root-cause-analysis [1]].&lt;br /&gt;
&lt;br /&gt;
===== General principles =====&lt;br /&gt;
&lt;br /&gt;
To achieve an effective root cause analysis process, there are some general principles that should be taken into consideration. These principles will increase the quality of the analysis and will help the analysis get trust from clients and stakeholders [https://www.geeksforgeeks.org/basic-principle-of-root-cause-analysis/[2]].&lt;br /&gt;
&lt;br /&gt;
*Consider to actually correct and remedy the root causes, not only the symptoms.&lt;br /&gt;
*While performing the root cause analysis, also remember to treat symptoms for short term fixing.&lt;br /&gt;
*Avoid focus on who was responsible of the failure or problem, instead focus on how and why.&lt;br /&gt;
*Find and document ways to prevent similar root causes in the future.&lt;br /&gt;
*When finding root causes, provide cause-effect evidence to back it up.&lt;br /&gt;
*Often there are multiple root causes, therefore search for several.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
As it can be understood from the principles above, it is important to take a comprehensive and holistic approach in this type of analysis. As the root causes have no importance if no action is taken afterwards, it should be strived to provide information and context that can solve the failure or problem.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Fishbone Diagram ===&lt;br /&gt;
A Fishbone diagram, which also is called an Ishikawa diagram, is used to identify root causes of quality problems. The fishbone diagram provides an organised way of looking at effects and causes. It can also be referred to as a cause-and-effect diagram. It generally represents a model of indicative presentation for the correlations between an event, which is an effect, and its several causes. This helps the team members get the same understanding of the problem, so that they can think systematically. The root causes of a problem can by using this structured approach be found, while encouraging group participation, utilising group knowledge and identifying areas where data should be collected for future studies. Hence the name, the diagram has the same structure as the skeleton of a fish. While it most often is used in a simple representation, with segments leaning on a horizontal axis, it can also be done with a more extensive approach. An example of this is by naming and coding of the risks which characterises the causes and sub-causes. This consists of elements that show the causes and sub-causes succession with different ways for risk treatment [https://www.researchgate.net/publication/46567642_Application_Of_Fishbone_Diagram_To_Determine_The_Risk_Of_An_Event_With_Multiple_Causes[3]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:A-generic-representation-of-the-Ishikawa-diagram-aka-Fishbone-diagram.png|400px|thumb|centre|Figure 2: Illustration of a Fishbone diagram]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Five steps should be followed to successful use the Fishbone diagram technique [https://www.ionos.ca/startupguide/productivity/fishbone-diagram/[4]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#The first step is to state the problem precisely. This problem statement must be carefully chosen, and it is important that it is specific enough.&lt;br /&gt;
#Define the main influencing factors. This is the factors are put in the horizontal category segments in the fishbone diagram. Different defects or problems have different influencing, which means that these should be chosen after what is relevant. Examples of these is seen in the figure above.&lt;br /&gt;
#State the causes into the diagram sorted after the different categories. This should be done with those employees that are directly involved in the problem causing processes. Also, the team should consist of a mix of different levels of expertise. When analysing the problem statement and finding causes, further sub-causes can be elaborated upon.&lt;br /&gt;
#Prioritise the causes. In the same team, make each person state their opinion as what is the most serious cause of the defect or problem. After a discussion about the causes, each person can give points to the causes that they believe are the most serious. The causes with the most points, should then be prioritised.&lt;br /&gt;
#Take measures. Tackle the defect or problem by eradicating the cause or causes. I it’s important that it is certain that the correct cause have been identified. To make sure of this, a significance test can be used for verifying, in order to select suitable methods for problem-solving.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== The 5 Whys ===&lt;br /&gt;
The 5 whys is a simple, yet powerful way of finding root causes. It works as an iterative interrogative technique to explore cause-and-effect relationship underlaying a particular problem. It is often used together with the a Fishbone diagram to find the root causes for the causes on the diagram.  As the name of technique implies, the primary goal is to find the root cause of a problem by asking “Why?” five times. Each answer of the “Whys” forms the basis for the next question, and when the fifth “Why?” have been answered, the root cause should be found. Five times is generally enough, but if the root cause still not is found, it could be repeated up to a total of six, seven or higher levels. For problems or defects that do not have one single root cause, the technique must be repeated asking a different sequence of questions each time [https://www.corship.eu/5-whys-method/[5]]. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:5-whys-example (1).png|500px|thumb|right|Figure 3: Example of a 5 whys analysis[https://www.corship.eu/5-whys-method/]]]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The five steps to conduct the 5 whys analysis, is to [https://www.adb.org/publications/five-whys-technique[6]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather a team who can develop a problem statement in agreement. At this point, it should be discussed whether additionally individuals are needed to resolve the problem. &lt;br /&gt;
#Make the team come with statements on “Why is this or that defect or problem taking place?”. This is the first “why” of the analysis. There are most probable multiple statements for this, and they should all be written down.&lt;br /&gt;
#Repeat the same process asking “why” four more times. This should be done for every statement from the first “why” in the structure like the figure below shows. All plausible answers should be written down. When the “why” does not yield further useful information, you have found the root cause. This means that is sometimes may take more than five layers to find the root cause.&lt;br /&gt;
#Among the many answers to the last asked “why”, look for systematic causes of the defect or problem. This should be discussed in the group to be able to settle for the most likely systematic cause. The product from the team session should then be showed to others to confirm that they see the same logic in the analysis.&lt;br /&gt;
#The last and final step of the 5 why analysis is to develop appropriate corrective actions to remove the root cause from the system. Others can undertake these actions but planning and implementation will benefit from inputs from the team.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===Pareto Chart Analysis===&lt;br /&gt;
[[File:Pareto output.png|400px|thumb|right|Figure 4: The 20/80 principle]]&lt;br /&gt;
The Pareto chart combines a histogram (bar chart) and a line chart, where cost or frequency of defects or problems show their relative importance. Frequencies are shown in the histogram with descending order of the bars, and the line chart shows the totals or the cumulative percentages increasing from left to right. It is based on the Pareto principle, which states that “80% of the effects or consequences come from 20% of the causes”. This is not like the immutable laws of physics but based on continuous observations. On those observations, it has showed to be applicable to many aspects of life and natural phenomena. In relation to a root cause analysis, the Pareto Chart Analysis helps identify the top 20% of the causes that needs to be addressed to resolve 80% of the problems [https://www.slideshare.net/himanshuhora/pareto-analysis-28873221[7]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;In order to perform a Pareto Chart Analysis, the following needs to be done [https://www.slideshare.net/himanshuhora/pareto-analysis-28873221[7]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather and collect data on the frequency of the causes of a defect or problem.&lt;br /&gt;
#Sort the causes after most to least important, and then calculate the cumulative percentage.&lt;br /&gt;
#Plot bars of the causes ordered from most to least frequent on the x-axis, and then plot the cumulative percentages on the y-axis. &lt;br /&gt;
#Finally, separate the 20% most important root causes from the rest by lifting the x-axis to the 80% cumulative percent on the y-axis.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:Pareto-chart-example.png|600px|thumb|left|Figure 5: An example of a Pareto Chart Analysis[https://www.whatissixsigma.net/pareto-chart-and-analysis/]]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Challenges and limitations ==&lt;br /&gt;
&lt;br /&gt;
For the Root Cause Analysis to give results, it is dependent on a larger problem-solving effort to improve the quality in a business. It therefore the managements responsibility to make the best use of the findings from the root cause analyses. The root cause analysis on itself would not provide the correct result. When it comes to the conduction of a root cause analysis, it is hard to fully know if you have taken every root cause into consideration. The reason for this is because there can be multiple root causes, and there is hard to tell when every root cause has been found. This can lead to too much time spent on irrelevant underlaying factors, which result in confusion and a waste of time. The 5 whys and the fishbone analysis does not rely on specific data, which can lead to less reliable results. The management can therefore have trouble entirely trusting these analyses. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Annotated Bibliography==&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
[https://www.tableau.com/learn/articles/root-cause-analysis [1]] Root Cause Analysis Explained: Definition, Examples, and Methods by Tableau&lt;br /&gt;
&lt;br /&gt;
[https://www.geeksforgeeks.org/basic-principle-of-root-cause-analysis/ [2]] Basic Principle of Root cause analysis by GeeksforGeeks&lt;br /&gt;
&lt;br /&gt;
[https://www.researchgate.net/publication/46567642_Application_Of_Fishbone_Diagram_To_Determine_The_Risk_Of_An_Event_With_Multiple_Causes [3]] Application Of Fishbone Diagram To Determine The Risk Of An Event With Multiple Causes by the UTI Grup SRL and the Academy of Economic Studies&lt;br /&gt;
&lt;br /&gt;
[https://www.ionos.ca/startupguide/productivity/fishbone-diagram/[4]] Fishbone diagram: Solving problems properly by IONOS&lt;br /&gt;
&lt;br /&gt;
[https://www.corship.eu/5-whys-method/ [5]] 5 Whys Method by CORSHIP – CORPORATE EDUPRENEURSHIP&lt;br /&gt;
&lt;br /&gt;
[https://www.adb.org/publications/five-whys-technique [6]] The Five Whys Technique by The Asian Development Bank&lt;br /&gt;
&lt;br /&gt;
[https://www.slideshare.net/himanshuhora/pareto-analysis-28873221 [7]]Pareto Analysis by Dr. Himanshu Hora, SRMS College of Engineering &amp;amp; Technology Bareilly&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122297</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122297"/>
		<updated>2022-03-27T15:05:11Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;Developed by William Vossgård&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
==== Abstract ====&lt;br /&gt;
Root Cause Analysis (RCA) is a method of problem solving that can be used in a project, program or portfolio (PPP) to identify root causes of faults and problems in order to identify appropriate solutions. It is broadly used in several industries, among the health care, infrastructure and information technology industry. A Root Cause Analysis supposes that it is more effective to go in-depth of occurring problems, so that the underlaying issue can be treated, instead of only treating ad hoc symptoms. Root Cause Analyses can be performed with several different methodologies, principles and techniques together to identify the root causes of a fault or problem. The goal is to find out where processes or systems failed or caused an issue in the first place.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
To be able to fully understand what a root cause analysis is and what it is used for, it is easier to relate it to something we are entirely acknowledged with. If your arm hurts considerably after an accident, you will go to the doctor to find the root cause of your pain. Also, if your computer stops working, you will try to find the root cause of its malfunction, either by yourself or by a professional technician. For these examples, a simple remedy could be found for the symptoms. To stop your arm from hurting, you could put ice on it to relive pain. To get work done with a broken computer, you could use your phone or tablet instead. Unfortunately, this would only consider the symptoms and not the underlaying issue that caused the problem. The injured arm may need surgery to entirely recover from the sustained injury, and the broken computer may need to have a new battery to function again. The best way to solve a fault or problem would therefore be to perform a Root Cause Analysis. By doing this, the exact root cause can be found so that the correct management of the fault or problem will be accomplished.&lt;br /&gt;
There are a number of techniques and strategies that can be used for root cause analyses. In this article, the most commonly and widely used techniques will be covered.&lt;br /&gt;
&lt;br /&gt;
== Conducting a root cause analysis ==&lt;br /&gt;
&lt;br /&gt;
There is not one specific way of performing a root cause analysis as there are many different techniques and strategies that can be used. In this chapter, the most common and broadly used techniques will be covered. Root cause analyses gives the best effect when a team is gathered, to do the analysis together. In particular, it should be done with those employees, who are directly involved in the problem-causing processes.&lt;br /&gt;
&lt;br /&gt;
===== Goals and benefits =====&lt;br /&gt;
&lt;br /&gt;
Related to the root cause analysis, there are three goals that should be realised. The first one being to discover the root cause of a failure or problem. The second is to develop an understanding on how to fix and learn from the underlaying issues relating the root cause. The third and final is to apply the findings from the root cause analysis, to systematically prevent future issues or problems. The third goal is especially important as this is what gives the analysis a reason to be performed. Root cause analysis can be used for increasing the productiveness in several core processes as well, with the goal to prevent problems in the future. Instead of replacing punctured bike tires on rental bikes, puncture proof tires could be installed instead if the problem persists [https://www.tableau.com/learn/articles/root-cause-analysis [1]].&lt;br /&gt;
&lt;br /&gt;
===== General principles =====&lt;br /&gt;
&lt;br /&gt;
To achieve an effective root cause analysis process, there are some general principles that should be taken into consideration. These principles will increase the quality of the analysis and will help the analysis get trust from clients and stakeholders [https://www.geeksforgeeks.org/basic-principle-of-root-cause-analysis/[2]].&lt;br /&gt;
&lt;br /&gt;
*Consider to actually correct and remedy the root causes, not only the symptoms.&lt;br /&gt;
*While performing the root cause analysis, also remember to treat symptoms for short term fixing.&lt;br /&gt;
*Avoid focus on who was responsible of the failure or problem, instead focus on how and why.&lt;br /&gt;
*Find and document ways to prevent similar root causes in the future.&lt;br /&gt;
*When finding root causes, provide cause-effect evidence to back it up.&lt;br /&gt;
*Often there are multiple root causes, therefore search for several.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
As it can be understood from the principles above, it is important to take a comprehensive and holistic approach in this type of analysis. As the root causes have no importance if no action is taken afterwards, it should be strived to provide information and context that can solve the failure or problem.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Fishbone Diagram ===&lt;br /&gt;
A Fishbone diagram, which also is called an Ishikawa diagram, is used to identify root causes of quality problems. The fishbone diagram provides an organised way of looking at effects and causes. It can also be referred to as a cause-and-effect diagram. It generally represents a model of indicative presentation for the correlations between an event, which is an effect, and its several causes. This helps the team members get the same understanding of the problem, so that they can think systematically. The root causes of a problem can by using this structured approach be found, while encouraging group participation, utilising group knowledge and identifying areas where data should be collected for future studies. Hence the name, the diagram has the same structure as the skeleton of a fish. While it most often is used in a simple representation, with segments leaning on a horizontal axis, it can also be done with a more extensive approach. An example of this is by naming and coding of the risks which characterises the causes and sub-causes. This consists of elements that show the causes and sub-causes succession with different ways for risk treatment [https://www.researchgate.net/publication/46567642_Application_Of_Fishbone_Diagram_To_Determine_The_Risk_Of_An_Event_With_Multiple_Causes[3]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:A-generic-representation-of-the-Ishikawa-diagram-aka-Fishbone-diagram.png|400px|thumb|centre|Figure 2: Illustration of a Fishbone diagram]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Five steps should be followed to successful use the Fishbone diagram technique [https://www.ionos.ca/startupguide/productivity/fishbone-diagram/[4]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#The first step is to state the problem precisely. This problem statement must be carefully chosen, and it is important that it is specific enough.&lt;br /&gt;
#Define the main influencing factors. This is the factors are put in the horizontal category segments in the fishbone diagram. Different defects or problems have different influencing, which means that these should be chosen after what is relevant. Examples of these is seen in the figure above.&lt;br /&gt;
#State the causes into the diagram sorted after the different categories. This should be done with those employees that are directly involved in the problem causing processes. Also, the team should consist of a mix of different levels of expertise. When analysing the problem statement and finding causes, further sub-causes can be elaborated upon.&lt;br /&gt;
#Prioritise the causes. In the same team, make each person state their opinion as what is the most serious cause of the defect or problem. After a discussion about the causes, each person can give points to the causes that they believe are the most serious. The causes with the most points, should then be prioritised.&lt;br /&gt;
#Take measures. Tackle the defect or problem by eradicating the cause or causes. I it’s important that it is certain that the correct cause have been identified. To make sure of this, a significance test can be used for verifying, in order to select suitable methods for problem-solving.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== The 5 Whys ===&lt;br /&gt;
The 5 whys is a simple, yet powerful way of finding root causes. It works as an iterative interrogative technique to explore cause-and-effect relationship underlaying a particular problem. It is often used together with the a Fishbone diagram to find the root causes for the causes on the diagram.  As the name of technique implies, the primary goal is to find the root cause of a problem by asking “Why?” five times. Each answer of the “Whys” forms the basis for the next question, and when the fifth “Why?” have been answered, the root cause should be found. Five times is generally enough, but if the root cause still not is found, it could be repeated up to a total of six, seven or higher levels. For problems or defects that do not have one single root cause, the technique must be repeated asking a different sequence of questions each time [https://www.corship.eu/5-whys-method/[5]]. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:5-whys-example (1).png|500px|thumb|right|Figure 3: Example of a 5 whys analysis[https://www.corship.eu/5-whys-method/]]]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The five steps to conduct the 5 whys analysis, is to [https://www.adb.org/publications/five-whys-technique[6]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather a team who can develop a problem statement in agreement. At this point, it should be discussed whether additionally individuals are needed to resolve the problem. &lt;br /&gt;
#Make the team come with statements on “Why is this or that defect or problem taking place?”. This is the first “why” of the analysis. There are most probable multiple statements for this, and they should all be written down.&lt;br /&gt;
#Repeat the same process asking “why” four more times. This should be done for every statement from the first “why” in the structure like the figure below shows. All plausible answers should be written down. When the “why” does not yield further useful information, you have found the root cause. This means that is sometimes may take more than five layers to find the root cause.&lt;br /&gt;
#Among the many answers to the last asked “why”, look for systematic causes of the defect or problem. This should be discussed in the group to be able to settle for the most likely systematic cause. The product from the team session should then be showed to others to confirm that they see the same logic in the analysis.&lt;br /&gt;
#The last and final step of the 5 why analysis is to develop appropriate corrective actions to remove the root cause from the system. Others can undertake these actions but planning and implementation will benefit from inputs from the team.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===Pareto Chart Analysis===&lt;br /&gt;
[[File:Pareto output.png|400px|thumb|right|Figure 4: The 20/80 principle]]&lt;br /&gt;
The Pareto chart combines a histogram (bar chart) and a line chart, where cost or frequency of defects or problems show their relative importance. Frequencies are shown in the histogram with descending order of the bars, and the line chart shows the totals or the cumulative percentages increasing from left to right. It is based on the Pareto principle, which states that “80% of the effects or consequences come from 20% of the causes”. This is not like the immutable laws of physics but based on continuous observations. On those observations, it has showed to be applicable to many aspects of life and natural phenomena. In relation to a root cause analysis, the Pareto Chart Analysis helps identify the top 20% of the causes that needs to be addressed to resolve 80% of the problems [https://www.slideshare.net/himanshuhora/pareto-analysis-28873221[7]].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;In order to perform a Pareto Chart Analysis, the following needs to be done [https://www.slideshare.net/himanshuhora/pareto-analysis-28873221[7]]:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather and collect data on the frequency of the causes of a defect or problem.&lt;br /&gt;
#Sort the causes after most to least important, and then calculate the cumulative percentage.&lt;br /&gt;
#Plot bars of the causes ordered from most to least frequent on the x-axis, and then plot the cumulative percentages on the y-axis. &lt;br /&gt;
#Finally, separate the 20% most important root causes from the rest by lifting the x-axis to the 80% cumulative percent on the y-axis.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:Pareto-chart-example.png|600px|thumb|left|Figure 5: An example of a Pareto Chart Analysis[https://www.whatissixsigma.net/pareto-chart-and-analysis/]]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Challenges and limitations ==&lt;br /&gt;
&lt;br /&gt;
For the Root Cause Analysis to give results, it is dependent on a larger problem-solving effort to improve the quality in a business. It therefore the managements responsibility to make the best use of the findings from the root cause analyses. The root cause analysis on itself would not provide the correct result. When it comes to the conduction of a root cause analysis, it is hard to fully know if you have taken every root cause into consideration. The reason for this is because there can be multiple root causes, and there is hard to tell when every root cause has been found. This can lead to too much time spent on irrelevant underlaying factors, which result in confusion and a waste of time. The 5 whys and the fishbone analysis does not rely on specific data, which can lead to less reliable results. The management can therefore have trouble entirely trusting these analyses. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Annotated Bibliography==&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
[https://www.tableau.com/learn/articles/root-cause-analysis [1]]&lt;br /&gt;
&lt;br /&gt;
[https://www.geeksforgeeks.org/basic-principle-of-root-cause-analysis/ [2]] Basic Principle of Root cause analysis by GeeksforGeeks&lt;br /&gt;
&lt;br /&gt;
[https://www.researchgate.net/publication/46567642_Application_Of_Fishbone_Diagram_To_Determine_The_Risk_Of_An_Event_With_Multiple_Causes [3]] Application Of Fishbone Diagram To Determine The Risk Of An Event With Multiple Causes by the UTI Grup SRL and the Academy of Economic Studies&lt;br /&gt;
&lt;br /&gt;
[https://www.ionos.ca/startupguide/productivity/fishbone-diagram/[4]] Fishbone diagram: Solving problems properly by IONOS&lt;br /&gt;
&lt;br /&gt;
[https://www.corship.eu/5-whys-method/ [5]] 5 Whys Method by CORSHIP – CORPORATE EDUPRENEURSHIP&lt;br /&gt;
&lt;br /&gt;
[https://www.adb.org/publications/five-whys-technique [6]] The Five Whys Technique by The Asian Development Bank&lt;br /&gt;
&lt;br /&gt;
[https://www.slideshare.net/himanshuhora/pareto-analysis-28873221 [7]]Pareto Analysis by Dr. Himanshu Hora, SRMS College of Engineering &amp;amp; Technology Bareilly&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122267</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122267"/>
		<updated>2022-03-27T13:36:51Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;Developed by William Vossgård&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
==== Abstract ====&lt;br /&gt;
Root Cause Analysis (RCA) is a method of problem solving that can be used in a project, program or portfolio (PPP) to identify root causes of faults and problems in order to identify appropriate solutions. It is broadly used in several industries, among the health care, infrastructure and information technology industry. A Root Cause Analysis supposes that it is more effective to go in-depth of occurring problems, so that the underlaying issue can be treated, instead of only treating ad hoc symptoms. Root Cause Analyses can be performed with several different methodologies, principles and techniques together to identify the root causes of a fault or problem. The goal is to find out where processes or systems failed or caused an issue in the first place.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A Root Cause Analysis can be divided into four steps:&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; – What went wrong? Do not look at symptoms of the fault or problem, but discover what specifically went wrong and caused the fault or problem.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Establish a timeline&#039;&#039;&#039; – Establish a timeline that specifies how the situation went from normal to problematical.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Distinguish root causes from other casual factors&#039;&#039;&#039; – Sort out factors that actually made the failure or problem occur. This can e.g. be done using event correlation.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Establish an overview between the root cause and the problem&#039;&#039;&#039; – Document how the root cause caused the fault or problem, this can be done e.g. with a casual graph.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
To be able to fully understand what a root cause analysis is and what it is used for, it is easier to relate it to something we are entirely acknowledged with. If your arm hurts considerably after an accident, you will go to the doctor to find the root cause of your pain. Also, if your computer stops working, you will try to find the root cause of its malfunction, either by yourself or by a professional technician. For these examples, a simple remedy could be found for the symptoms. To stop your arm from hurting, you could put ice on it to relive pain. To get work done with a broken computer, you could use your phone or tablet instead. Unfortunately, this would only consider the symptoms and not the underlaying issue that caused the problem. The injured arm may need surgery to entirely recover from the sustained injury, and the broken computer may need to have a new battery to function again. The best way to solve a fault or problem would therefore be to perform a Root Cause Analysis. By doing this, the exact root cause can be found so that the correct management of the fault or problem will be accomplished.&lt;br /&gt;
There are a number of techniques and strategies that can be used for root cause analyses. In this article, the most commonly and widely used techniques will be covered.&lt;br /&gt;
&lt;br /&gt;
== Conducting a root cause analysis ==&lt;br /&gt;
&lt;br /&gt;
There is not one specific way of performing a root cause analysis as there are many different techniques and strategies that can be used. In this chapter, the most common and broadly used techniques will be covered. Root cause analyses gives the best effect when a team is gathered, to do the analysis together. In particular, it should be done with those employees, who are directly involved in the problem-causing processes.&lt;br /&gt;
&lt;br /&gt;
===== Goals and benefits =====&lt;br /&gt;
&lt;br /&gt;
Related to the root cause analysis, there are three goals that should be realised. The first one being to discover the root cause of a failure or problem. The second is to develop an understanding on how to fix and learn from the underlaying issues relating the root cause. The third and final is to apply the findings from the root cause analysis, to systematically prevent future issues or problems. The third goal is especially important as this is what gives the analysis a reason to be performed. Root cause analysis can be used for increasing the productiveness in several core processes as well, with the goal to prevent problems in the future. Instead of replacing punctured bike tires on rental bikes, puncture proof tires could be installed instead if the problem persists.&lt;br /&gt;
&lt;br /&gt;
===== General principles =====&lt;br /&gt;
&lt;br /&gt;
To achieve an effective root cause analysis process, there are some general principles that should be taken into consideration. These principles will increase the quality of the analysis and will help the analysis get trust from clients and stakeholders.&lt;br /&gt;
&lt;br /&gt;
*Consider to actually correct and remedy the root causes, not only the symptoms.&lt;br /&gt;
*While performing the root cause analysis, also remember to treat symptoms for short term fixing.&lt;br /&gt;
*Avoid focus on who was responsible of the failure or problem, instead focus on how and why.&lt;br /&gt;
*Find and document ways to prevent similar root causes in the future.&lt;br /&gt;
*When finding root causes, provide cause-effect evidence to back it up.&lt;br /&gt;
*Often there are multiple root causes, therefore search for several.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
As it can be understood from the principles above, it is important to take a comprehensive and holistic approach in this type of analysis. As the root causes have no importance if no action is taken afterwards, it should be strived to provide information and context that can solve the failure or problem.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Fishbone Diagram ==&lt;br /&gt;
A Fishbone diagram, which also is called an Ishikawa diagram, is used to identify root causes of quality problems [1]. The fishbone diagram provides an organised way of looking at effects and causes. It can also be referred to as a cause-and-effect diagram (Watson, 2004). It generally represents a model of indicative presentation for the correlations between an event, which is an effect, and its several causes. This helps the team members get the same understanding of the problem, so that they can think systematically. The root causes of a problem can by using this structured approach be found, while encouraging group participation, utilising group knowledge and identifying areas where data should be collected for future studies. Hence the name, the diagram has the same structure as the skeleton of a fish. While it most often is used in a simple representation, with segments leaning on a horizontal axis, it can also be done with a more extensive approach. An example of this is by naming and coding of the risks which characterises the causes and sub-causes. This consists of elements that show the causes and sub-causes succession with different ways for risk treatment [1].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:A-generic-representation-of-the-Ishikawa-diagram-aka-Fishbone-diagram.png|400px|thumb|centre|Figure 2: Illustration of a Fishbone diagram]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;To successfully use the fishbone diagram as a tool for analysing root causes, five steps should be followed:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#The first step is to state the problem precisely. This problem statement must be carefully chosen, and it is important that it is specific enough.&lt;br /&gt;
#Define the main influencing factors. This is the factors are put in the horizontal category segments in the fishbone diagram. Different defects or problems have different influencing, which means that these should be chosen after what is relevant. Examples of these is seen in the figure above.&lt;br /&gt;
#State the causes into the diagram sorted after the different categories. This should be done with those employees that are directly involved in the problem causing processes. Also, the team should consist of a mix of different levels of expertise. When analysing the problem statement and finding causes, further sub-causes can be elaborated upon.&lt;br /&gt;
#Prioritise the causes. In the same team, make each person state their opinion as what is the most serious cause of the defect or problem. After a discussion about the causes, each person can give points to the causes that they believe are the most serious. The causes with the most points, should then be prioritised.&lt;br /&gt;
#Take measures. Tackle the defect or problem by eradicating the cause or causes. I it’s important that it is certain that the correct cause have been identified. To make sure of this, a significance test can be used for verifying, in order to select suitable methods for problem-solving.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== The 5 Whys ==&lt;br /&gt;
The 5 whys is a simple, yet powerful way of finding root causes. It works as an iterative interrogative technique to explore cause-and-effect relationship underlaying a particular problem. It is often used together with the a Fishbone diagram to find the root causes for the causes on the diagram.  As the name of technique implies, the primary goal is to find the root cause of a problem by asking “Why?” five times. Each answer of the “Whys” forms the basis for the next question, and when the fifth “Why?” have been answered, the root cause should be found. Five times is generally enough, but if the root cause still not is found, it could be repeated up to a total of six, seven or higher levels. For problems or defects that do not have one single root cause, the technique must be repeated asking a different sequence of questions each time. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:5-whys-example (1).png|500px|thumb|right|Figure 3: Example of a 5 whys analysis]]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The five steps to conduct the 5 whys analysis, is to:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather a team who can develop a problem statement in agreement. At this point, it should be discussed whether additionally individuals are needed to resolve the problem. &lt;br /&gt;
#Make the team come with statements on “Why is this or that defect or problem taking place?”. This is the first “why” of the analysis. There are most probable multiple statements for this, and they should all be written down.&lt;br /&gt;
#Repeat the same process asking “why” four more times. This should be done for every statement from the first “why” in the structure like the figure below shows. All plausible answers should be written down. When the “why” does not yield further useful information, you have found the root cause. This means that is sometimes may take more than five layers to find the root cause.&lt;br /&gt;
#Among the many answers to the last asked “why”, look for systematic causes of the defect or problem. This should be discussed in the group to be able to settle for the most likely systematic cause. The product from the team session should then be showed to others to confirm that they see the same logic in the analysis.&lt;br /&gt;
#The last and final step of the 5 why analysis is to develop appropriate corrective actions to remove the root cause from the system. Others can undertake these actions but planning and implementation will benefit from inputs from the team.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Pareto Chart Analysis==&lt;br /&gt;
[[File:Pareto output.png|400px|thumb|right|Figure 4: The 20/80 principle]]&lt;br /&gt;
The Pareto chart combines a histogram (bar chart) and a line chart, where cost or frequency of defects or problems show their relative importance. Frequencies are shown in the histogram with descending order of the bars, and the line chart shows the totals or the cumulative percentages increasing from left to right. It is based on the Pareto principle, which states that “80% of the effects or consequences come from 20% of the causes”. This is not like the immutable laws of physics but based on continuous observations. On those observations, it has showed to be applicable to many aspects of life and natural phenomena. In relation to a root cause analysis, the Pareto Chart Analysis helps identify the top 20% of the causes that needs to be addressed to resolve 80% of the problems.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;In order to perform a Pareto Chart Analysis, the following needs to be done:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather and collect data on the frequency of the causes of a defect or problem.&lt;br /&gt;
#Sort the causes after most to least important, and then calculate the cumulative percentage.&lt;br /&gt;
#Plot bars of the causes ordered from most to least frequent on the x-axis, and then plot the cumulative percentages on the y-axis. &lt;br /&gt;
#Finally, separate the 20% most important root causes from the rest by lifting the x-axis to the 80% cumulative percent on the y-axis.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:Pareto-chart-example.png|600px|thumb|left|Figure 5: An example of a Pareto Chart Analysis]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Challenges and limitations == &lt;br /&gt;
&lt;br /&gt;
For the Root Cause Analysis to give results, it is dependent on a larger problem-solving effort to improve the quality in a business. It therefore the managements responsibility to make the best use of the findings from the root cause analyses. The root cause analysis on itself would not provide the correct result. When it comes to the conduction of a root cause analysis, it is hard to fully know if you have taken every root cause into consideration. The reason for this is because there can be multiple root causes, and there is hard to tell when every root cause has been found. This can lead to too much time spent on irrelevant underlaying factors, which result in confusion and a waste of time. The 5 whys and the fishbone analysis does not rely on specific data, which can lead to less reliable results. The management can therefore have trouble entirely trusting these analyses. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Annotated Bibliography==&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122250</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122250"/>
		<updated>2022-03-27T12:51:27Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Root Cause Analysis (RCA) is a method of problem solving that can be used in a project, program or portfolio (PPP) to identify root causes of faults and problems in order to identify appropriate solutions. It is broadly used in several industries, among the health care, infrastructure and information technology industry. A Root Cause Analysis supposes that it is more effective to go in-depth of occurring problems, so that the underlaying issue can be treated, instead of only treating ad hoc symptoms. Root Cause Analyses can be performed with several different methodologies, principles and techniques together to identify the root causes of a fault or problem. The goal is to find out where processes or systems failed or caused an issue in the first place.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A Root Cause Analysis can be divided into four steps:&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; – What went wrong? Do not look at symptoms of the fault or problem, but discover what specifically went wrong and caused the fault or problem.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Establish a timeline&#039;&#039;&#039; – Establish a timeline that specifies how the situation went from normal to problematical.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Distinguish root causes from other casual factors&#039;&#039;&#039; – Sort out factors that actually made the failure or problem occur. This can e.g. be done using event correlation.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Establish an overview between the root cause and the problem&#039;&#039;&#039; – Document how the root cause caused the fault or problem, this can be done e.g. with a casual graph.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
To be able to fully understand what a root cause analysis is and what it is used for, it is easier to relate it to something we are entirely acknowledged with. If your arm hurts considerably after an accident, you will go to the doctor to find the root cause of your pain. Also, if your computer stops working, you will try to find the root cause of its malfunction, either by yourself or by a professional technician. For these examples, a simple remedy could be found for the symptoms. To stop your arm from hurting, you could put ice on it to relive pain. To get work done with a broken computer, you could use your phone or tablet instead. Unfortunately, this would only consider the symptoms and not the underlaying issue that caused the problem. The injured arm may need surgery to entirely recover from the sustained injury, and the broken computer may need to have a new battery to function again. The best way to solve a fault or problem would therefore be to perform a Root Cause Analysis. By doing this, the exact root cause can be found so that the correct management of the fault or problem will be accomplished.&lt;br /&gt;
There are a number of techniques and strategies that can be used for root cause analyses. In this article, the most commonly and widely used techniques will be covered.&lt;br /&gt;
&lt;br /&gt;
== Conducting a root cause analysis ==&lt;br /&gt;
&lt;br /&gt;
There is not one specific way of performing a root cause analysis as there are many different techniques and strategies that can be used. In this chapter, the most common and broadly used techniques will be covered. Root cause analyses gives the best effect when a team is gathered, to do the analysis together. In particular, it should be done with those employees, who are directly involved in the problem-causing processes.&lt;br /&gt;
&lt;br /&gt;
===== Goals and benefits =====&lt;br /&gt;
&lt;br /&gt;
Related to the root cause analysis, there are three goals that should be realised. The first one being to discover the root cause of a failure or problem. The second is to develop an understanding on how to fix and learn from the underlaying issues relating the root cause. The third and final is to apply the findings from the root cause analysis, to systematically prevent future issues or problems. The third goal is especially important as this is what gives the analysis a reason to be performed. Root cause analysis can be used for increasing the productiveness in several core processes as well, with the goal to prevent problems in the future. Instead of replacing punctured bike tires on rental bikes, puncture proof tires could be installed instead if the problem persists.&lt;br /&gt;
&lt;br /&gt;
===== General principles =====&lt;br /&gt;
&lt;br /&gt;
To achieve an effective root cause analysis process, there are some general principles that should be taken into consideration. These principles will increase the quality of the analysis and will help the analysis get trust from clients and stakeholders.&lt;br /&gt;
&lt;br /&gt;
*Consider to actually correct and remedy the root causes, not only the symptoms.&lt;br /&gt;
*While performing the root cause analysis, also remember to treat symptoms for short term fixing.&lt;br /&gt;
*Avoid focus on who was responsible of the failure or problem, instead focus on how and why.&lt;br /&gt;
*Find and document ways to prevent similar root causes in the future.&lt;br /&gt;
*When finding root causes, provide cause-effect evidence to back it up.&lt;br /&gt;
*Often there are multiple root causes, therefore search for several.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
As it can be understood from the principles above, it is important to take a comprehensive and holistic approach in this type of analysis. As the root causes have no importance if no action is taken afterwards, it should be strived to provide information and context that can solve the failure or problem.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Fishbone Diagram ==&lt;br /&gt;
A Fishbone diagram, which also is called an Ishikawa diagram, is used to identify root causes of quality problems [1]. The fishbone diagram provides an organised way of looking at effects and causes. It can also be referred to as a cause-and-effect diagram (Watson, 2004). It generally represents a model of indicative presentation for the correlations between an event, which is an effect, and its several causes. This helps the team members get the same understanding of the problem, so that they can think systematically. The root causes of a problem can by using this structured approach be found, while encouraging group participation, utilising group knowledge and identifying areas where data should be collected for future studies. Hence the name, the diagram has the same structure as the skeleton of a fish. While it most often is used in a simple representation, with segments leaning on a horizontal axis, it can also be done with a more extensive approach. An example of this is by naming and coding of the risks which characterises the causes and sub-causes. This consists of elements that show the causes and sub-causes succession with different ways for risk treatment [1].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:A-generic-representation-of-the-Ishikawa-diagram-aka-Fishbone-diagram.png|400px|thumb|centre|Figure 2: Illustration of a Fishbone diagram]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;To successfully use the fishbone diagram as a tool for analysing root causes, five steps should be followed:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#The first step is to state the problem precisely. This problem statement must be carefully chosen, and it is important that it is specific enough.&lt;br /&gt;
#Define the main influencing factors. This is the factors are put in the horizontal category segments in the fishbone diagram. Different defects or problems have different influencing, which means that these should be chosen after what is relevant. Examples of these is seen in the figure above.&lt;br /&gt;
#State the causes into the diagram sorted after the different categories. This should be done with those employees that are directly involved in the problem causing processes. Also, the team should consist of a mix of different levels of expertise. When analysing the problem statement and finding causes, further sub-causes can be elaborated upon.&lt;br /&gt;
#Prioritise the causes. In the same team, make each person state their opinion as what is the most serious cause of the defect or problem. After a discussion about the causes, each person can give points to the causes that they believe are the most serious. The causes with the most points, should then be prioritised.&lt;br /&gt;
#Take measures. Tackle the defect or problem by eradicating the cause or causes. I it’s important that it is certain that the correct cause have been identified. To make sure of this, a significance test can be used for verifying, in order to select suitable methods for problem-solving.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== The 5 Whys ==&lt;br /&gt;
The 5 whys is a simple, yet powerful way of finding root causes. It works as an iterative interrogative technique to explore cause-and-effect relationship underlaying a particular problem. It is often used together with the a Fishbone diagram to find the root causes for the causes on the diagram.  As the name of technique implies, the primary goal is to find the root cause of a problem by asking “Why?” five times. Each answer of the “Whys” forms the basis for the next question, and when the fifth “Why?” have been answered, the root cause should be found. Five times is generally enough, but if the root cause still not is found, it could be repeated up to a total of six, seven or higher levels. For problems or defects that do not have one single root cause, the technique must be repeated asking a different sequence of questions each time. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:5-whys-example (1).png|500px|thumb|right|Figure 3: Example of a 5 whys analysis]]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The five steps to conduct the 5 whys analysis, is to:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather a team who can develop a problem statement in agreement. At this point, it should be discussed whether additionally individuals are needed to resolve the problem. &lt;br /&gt;
#Make the team come with statements on “Why is this or that defect or problem taking place?”. This is the first “why” of the analysis. There are most probable multiple statements for this, and they should all be written down.&lt;br /&gt;
#Repeat the same process asking “why” four more times. This should be done for every statement from the first “why” in the structure like the figure below shows. All plausible answers should be written down. When the “why” does not yield further useful information, you have found the root cause. This means that is sometimes may take more than five layers to find the root cause.&lt;br /&gt;
#Among the many answers to the last asked “why”, look for systematic causes of the defect or problem. This should be discussed in the group to be able to settle for the most likely systematic cause. The product from the team session should then be showed to others to confirm that they see the same logic in the analysis.&lt;br /&gt;
#The last and final step of the 5 why analysis is to develop appropriate corrective actions to remove the root cause from the system. Others can undertake these actions but planning and implementation will benefit from inputs from the team.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Pareto Chart Analysis==&lt;br /&gt;
[[File:Pareto output.png|400px|thumb|right|Figure 4: The 20/80 principle]]&lt;br /&gt;
The Pareto chart combines a histogram (bar chart) and a line chart, where cost or frequency of defects or problems show their relative importance. Frequencies are shown in the histogram with descending order of the bars, and the line chart shows the totals or the cumulative percentages increasing from left to right. It is based on the Pareto principle, which states that “80% of the effects or consequences come from 20% of the causes”. This is not like the immutable laws of physics but based on continuous observations. On those observations, it has showed to be applicable to many aspects of life and natural phenomena. In relation to a root cause analysis, the Pareto Chart Analysis helps identify the top 20% of the causes that needs to be addressed to resolve 80% of the problems.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;In order to perform a Pareto Chart Analysis, the following needs to be done:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather and collect data on the frequency of the causes of a defect or problem.&lt;br /&gt;
#Sort the causes after most to least important, and then calculate the cumulative percentage.&lt;br /&gt;
#Plot bars of the causes ordered from most to least frequent on the x-axis, and then plot the cumulative percentages on the y-axis. &lt;br /&gt;
#Finally, separate the 20% most important root causes from the rest by lifting the x-axis to the 80% cumulative percent on the y-axis.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:Pareto-chart-example.png|600px|thumb|left|Figure 5: An example of a Pareto Chart Analysis]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Challenges and limitations == &lt;br /&gt;
&lt;br /&gt;
For the Root Cause Analysis to give results, it is dependent on a larger problem-solving effort to improve the quality in a business. It therefore the managements responsibility to make the best use of the findings from the root cause analyses. The root cause analysis on itself would not provide the correct result. When it comes to the conduction of a root cause analysis, it is hard to fully know if you have taken every root cause into consideration. The reason for this is because there can be multiple root causes, and there is hard to tell when every root cause has been found. This can lead to too much time spent on irrelevant underlaying factors, which result in confusion and a waste of time. The 5 whys and the fishbone analysis does not rely on specific data, which can lead to less reliable results. The management can therefore have trouble entirely trusting these analyses. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Annotated Bibliography==&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122249</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122249"/>
		<updated>2022-03-27T12:43:36Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Root Cause Analysis (RCA) is a method of problem solving that can be used in a project, program or portfolio (PPP) to identify root causes of faults and problems in order to identify appropriate solutions. It is broadly used in several industries, among the health care, infrastructure and information technology industry. A Root Cause Analysis supposes that it is more effective to go in-depth of occurring problems, so that the underlaying issue can be treated, instead of only treating ad hoc symptoms. Root Cause Analyses can be performed with several different methodologies, principles and techniques together to identify the root causes of a fault or problem. The goal is to find out where processes or systems failed or caused an issue in the first place.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A Root Cause Analysis can be divided into four steps:&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; – What went wrong? Do not look at symptoms of the fault or problem, but discover what specifically went wrong and caused the fault or problem.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Establish a timeline&#039;&#039;&#039; – Establish a timeline that specifies how the situation went from normal to problematical.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Distinguish root causes from other casual factors&#039;&#039;&#039; – Sort out factors that actually made the failure or problem occur. This can e.g. be done using event correlation.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Establish an overview between the root cause and the problem&#039;&#039;&#039; – Document how the root cause caused the fault or problem, this can be done e.g. with a casual graph.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
To be able to fully understand what a root cause analysis is and what it is used for, it is easier to relate it to something we are entirely acknowledged with. If your arm hurts considerably after an accident, you will go to the doctor to find the root cause of your pain. Also, if your computer stops working, you will try to find the root cause of its malfunction, either by yourself or by a professional technician. For these examples, a simple remedy could be found for the symptoms. To stop your arm from hurting, you could put ice on it to relive pain. To get work done with a broken computer, you could use your phone or tablet instead. Unfortunately, this would only consider the symptoms and not the underlaying issue that caused the problem. The injured arm may need surgery to entirely recover from the sustained injury, and the broken computer may need to have a new battery to function again. The best way to solve a fault or problem would therefore be to perform a Root Cause Analysis. By doing this, the exact root cause can be found so that the correct management of the fault or problem will be accomplished.&lt;br /&gt;
There are a number of techniques and strategies that can be used for root cause analyses. In this article, the most commonly and widely used techniques will be covered.&lt;br /&gt;
&lt;br /&gt;
===== Goals and benefits =====&lt;br /&gt;
&lt;br /&gt;
Related to the root cause analysis, there are three goals that should be realised. The first one being to discover the root cause of a failure or problem. The second is to develop an understanding on how to fix and learn from the underlaying issues relating the root cause. The third and final is to apply the findings from the root cause analysis, to systematically prevent future issues or problems. The third goal is especially important as this is what gives the analysis a reason to be performed. Root cause analysis can be used for increasing the productiveness in several core processes as well, with the goal to prevent problems in the future. Instead of replacing punctured bike tires on rental bikes, puncture proof tires could be installed instead if the problem persists.&lt;br /&gt;
&lt;br /&gt;
===== General principles =====&lt;br /&gt;
&lt;br /&gt;
To achieve an effective root cause analysis process, there are some general principles that should be taken into consideration. These principles will increase the quality of the analysis and will help the analysis get trust from clients and stakeholders.&lt;br /&gt;
&lt;br /&gt;
*Consider to actually correct and remedy the root causes, not only the symptoms.&lt;br /&gt;
*While performing the root cause analysis, also remember to treat symptoms for short term fixing.&lt;br /&gt;
*Avoid focus on who was responsible of the failure or problem, instead focus on how and why.&lt;br /&gt;
*Find and document ways to prevent similar root causes in the future.&lt;br /&gt;
*When finding root causes, provide cause-effect evidence to back it up.&lt;br /&gt;
*Often there are multiple root causes, therefore search for several.&lt;br /&gt;
&lt;br /&gt;
As it can be understood from the principles above, it is important to take a comprehensive and holistic approach in this type of analysis. As the root causes have no importance if no action is taken afterwards, it should be strived to provide information and context that can solve the failure or problem.&lt;br /&gt;
 &lt;br /&gt;
== Conducting a root cause analysis ==&lt;br /&gt;
&lt;br /&gt;
There is not one specific way of performing a root cause analysis as there are many different techniques and strategies that can be used. In this chapter, the most common and broadly used techniques will be covered. Root cause analyses gives the best effect when a team is gathered, to do the analysis together. In particular, it should be done with those employees, who are directly involved in the problem-causing processes.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Fishbone Diagram ==&lt;br /&gt;
A Fishbone diagram, which also is called an Ishikawa diagram, is used to identify root causes of quality problems [1]. The fishbone diagram provides an organised way of looking at effects and causes. It can also be referred to as a cause-and-effect diagram (Watson, 2004). It generally represents a model of indicative presentation for the correlations between an event, which is an effect, and its several causes. This helps the team members get the same understanding of the problem, so that they can think systematically. The root causes of a problem can by using this structured approach be found, while encouraging group participation, utilising group knowledge and identifying areas where data should be collected for future studies. Hence the name, the diagram has the same structure as the skeleton of a fish. While it most often is used in a simple representation, with segments leaning on a horizontal axis, it can also be done with a more extensive approach. An example of this is by naming and coding of the risks which characterises the causes and sub-causes. This consists of elements that show the causes and sub-causes succession with different ways for risk treatment [1].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:A-generic-representation-of-the-Ishikawa-diagram-aka-Fishbone-diagram.png|400px|thumb|centre|Figure 2: Illustration of a Fishbone diagram]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;To successfully use the fishbone diagram as a tool for analysing root causes, five steps should be followed:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#The first step is to state the problem precisely. This problem statement must be carefully chosen, and it is important that it is specific enough.&lt;br /&gt;
#Define the main influencing factors. This is the factors are put in the horizontal category segments in the fishbone diagram. Different defects or problems have different influencing, which means that these should be chosen after what is relevant. Examples of these is seen in the figure above.&lt;br /&gt;
#State the causes into the diagram sorted after the different categories. This should be done with those employees that are directly involved in the problem causing processes. Also, the team should consist of a mix of different levels of expertise. When analysing the problem statement and finding causes, further sub-causes can be elaborated upon.&lt;br /&gt;
#Prioritise the causes. In the same team, make each person state their opinion as what is the most serious cause of the defect or problem. After a discussion about the causes, each person can give points to the causes that they believe are the most serious. The causes with the most points, should then be prioritised.&lt;br /&gt;
#Take measures. Tackle the defect or problem by eradicating the cause or causes. I it’s important that it is certain that the correct cause have been identified. To make sure of this, a significance test can be used for verifying, in order to select suitable methods for problem-solving.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== The 5 Whys ==&lt;br /&gt;
The 5 whys is a simple, yet powerful way of finding root causes. It works as an iterative interrogative technique to explore cause-and-effect relationship underlaying a particular problem. It is often used together with the a Fishbone diagram to find the root causes for the causes on the diagram.  As the name of technique implies, the primary goal is to find the root cause of a problem by asking “Why?” five times. Each answer of the “Whys” forms the basis for the next question, and when the fifth “Why?” have been answered, the root cause should be found. Five times is generally enough, but if the root cause still not is found, it could be repeated up to a total of six, seven or higher levels. For problems or defects that do not have one single root cause, the technique must be repeated asking a different sequence of questions each time. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:5-whys-example (1).png|500px|thumb|right|Figure 3: Example of a 5 whys analysis]]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;The five steps to conduct the 5 whys analysis, is to:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather a team who can develop a problem statement in agreement. At this point, it should be discussed whether additionally individuals are needed to resolve the problem. &lt;br /&gt;
#Make the team come with statements on “Why is this or that defect or problem taking place?”. This is the first “why” of the analysis. There are most probable multiple statements for this, and they should all be written down.&lt;br /&gt;
#Repeat the same process asking “why” four more times. This should be done for every statement from the first “why” in the structure like the figure below shows. All plausible answers should be written down. When the “why” does not yield further useful information, you have found the root cause. This means that is sometimes may take more than five layers to find the root cause.&lt;br /&gt;
#Among the many answers to the last asked “why”, look for systematic causes of the defect or problem. This should be discussed in the group to be able to settle for the most likely systematic cause. The product from the team session should then be showed to others to confirm that they see the same logic in the analysis.&lt;br /&gt;
#The last and final step of the 5 why analysis is to develop appropriate corrective actions to remove the root cause from the system. Others can undertake these actions but planning and implementation will benefit from inputs from the team.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Pareto Chart Analysis==&lt;br /&gt;
[[File:Pareto output.png|400px|thumb|right|Figure 4: The 20/80 principle]]&lt;br /&gt;
The Pareto chart combines a histogram (bar chart) and a line chart, where cost or frequency of defects or problems show their relative importance. Frequencies are shown in the histogram with descending order of the bars, and the line chart shows the totals or the cumulative percentages increasing from left to right. It is based on the Pareto principle, which states that “80% of the effects or consequences come from 20% of the causes”. This is not like the immutable laws of physics but based on continuous observations. On those observations, it has showed to be applicable to many aspects of life and natural phenomena. In relation to a root cause analysis, the Pareto Chart Analysis helps identify the top 20% of the causes that needs to be addressed to resolve 80% of the problems.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;In order to perform a Pareto Chart Analysis, the following needs to be done:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather and collect data on the frequency of the causes of a defect or problem.&lt;br /&gt;
#Sort the causes after most to least important, and then calculate the cumulative percentage.&lt;br /&gt;
#Plot bars of the causes ordered from most to least frequent on the x-axis, and then plot the cumulative percentages on the y-axis. &lt;br /&gt;
#Finally, separate the 20% most important root causes from the rest by lifting the x-axis to the 80% cumulative percent on the y-axis.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:Pareto-chart-example.png|600px|thumb|left|Figure 5: An example of a Pareto Chart Analysis]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Challenges and limitations == &lt;br /&gt;
&lt;br /&gt;
For the Root Cause Analysis to give results, it is dependent on a larger problem-solving effort to improve the quality in a business. It therefore the managements responsibility to make the best use of the findings from the root cause analyses. The root cause analysis on itself would not provide the correct result. When it comes to the conduction of a root cause analysis, it is hard to fully know if you have taken every root cause into consideration. The reason for this is because there can be multiple root causes, and there is hard to tell when every root cause has been found. This can lead to too much time spent on irrelevant underlaying factors, which result in confusion and a waste of time. The 5 whys and the fishbone analysis does not rely on specific data, which can lead to less reliable results. The management can therefore have trouble entirely trusting these analyses. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Annotated Bibliography==&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122247</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122247"/>
		<updated>2022-03-27T12:31:47Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Root Cause Analysis (RCA) is a method of problem solving that can be used in a project, program or portfolio (PPP) to identify root causes of faults and problems in order to identify appropriate solutions. It is broadly used in several industries, among the health care, infrastructure and information technology industry. A Root Cause Analysis supposes that it is more effective to go in-depth of occurring problems, so that the underlaying issue can be treated, instead of only treating ad hoc symptoms. Root Cause Analyses can be performed with several different methodologies, principles and techniques together to identify the root causes of a fault or problem. The goal is to find out where processes or systems failed or caused an issue in the first place.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A Root Cause Analysis can be divided into four steps:&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; – What went wrong? Do not look at symptoms of the fault or problem, but discover what specifically went wrong and caused the fault or problem.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Establish a timeline&#039;&#039;&#039; – Establish a timeline that specifies how the situation went from normal to problematical.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Distinguish root causes from other casual factors&#039;&#039;&#039; – Sort out factors that actually made the failure or problem occur. This can e.g. be done using event correlation.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Establish an overview between the root cause and the problem&#039;&#039;&#039; – Document how the root cause caused the fault or problem, this can be done e.g. with a casual graph.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
To be able to fully understand what a root cause analysis is and what it is used for, it is easier to relate it to something we are entirely acknowledged with. If your arm hurts considerably after an accident, you will go to the doctor to find the root cause of your pain. Also, if your computer stops working, you will try to find the root cause of its malfunction, either by yourself or by a professional technician. For these examples, a simple remedy could be found for the symptoms. To stop your arm from hurting, you could put ice on it to relive pain. To get work done with a broken computer, you could use your phone or tablet instead. Unfortunately, this would only consider the symptoms and not the underlaying issue that caused the problem. The injured arm may need surgery to entirely recover from the sustained injury, and the broken computer may need to have a new battery to function again. The best way to solve a fault or problem would therefore be to perform a Root Cause Analysis. By doing this, the exact root cause can be found so that the correct management of the fault or problem will be accomplished.&lt;br /&gt;
There are a number of techniques and strategies that can be used for root cause analyses. In this article, the most commonly and widely used techniques will be covered.&lt;br /&gt;
&lt;br /&gt;
===== Goals and benefits =====&lt;br /&gt;
&lt;br /&gt;
Related to the root cause analysis, there are three goals that should be realised. The first one being to discover the root cause of a failure or problem. The second is to develop an understanding on how to fix and learn from the underlaying issues relating the root cause. The third and final is to apply the findings from the root cause analysis, to systematically prevent future issues or problems. The third goal is especially important as this is what gives the analysis a reason to be performed. Root cause analysis can be used for increasing the productiveness in several core processes as well, with the goal to prevent problems in the future. Instead of replacing punctured bike tires on rental bikes, puncture proof tires could be installed instead if the problem persists.&lt;br /&gt;
&lt;br /&gt;
===== General principles =====&lt;br /&gt;
&lt;br /&gt;
To achieve an effective root cause analysis process, there are some general principles that should be taken into consideration. These principles will increase the quality of the analysis and will help the analysis get trust from clients and stakeholders.&lt;br /&gt;
&lt;br /&gt;
*Consider to actually correct and remedy the root causes, not only the symptoms.&lt;br /&gt;
*While performing the root cause analysis, also remember to treat symptoms for short term fixing.&lt;br /&gt;
*Avoid focus on who was responsible of the failure or problem, instead focus on how and why.&lt;br /&gt;
*Find and document ways to prevent similar root causes in the future.&lt;br /&gt;
*When finding root causes, provide cause-effect evidence to back it up.&lt;br /&gt;
*Often there are multiple root causes, therefore search for several.&lt;br /&gt;
&lt;br /&gt;
As it can be understood from the principles above, it is important to take a comprehensive and holistic approach in this type of analysis. As the root causes have no importance if no action is taken afterwards, it should be strived to provide information and context that can solve the failure or problem.&lt;br /&gt;
 &lt;br /&gt;
== Conducting a root cause analysis ==&lt;br /&gt;
&lt;br /&gt;
There is not one specific way of performing a root cause analysis as there are many different techniques and strategies that can be used. In this chapter, the most common and broadly used techniques will be covered. Root cause analyses gives the best effect when a team is gathered, to do the analysis together. In particular, it should be done with those employees, who are directly involved in the problem-causing processes.&lt;br /&gt;
&lt;br /&gt;
=== Fishbone Diagram ===&lt;br /&gt;
A Fishbone diagram, which also is called an Ishikawa diagram, is used to identify root causes of quality problems [1]. The fishbone diagram provides an organised way of looking at effects and causes. It can also be referred to as a cause-and-effect diagram (Watson, 2004). It generally represents a model of indicative presentation for the correlations between an event, which is an effect, and its several causes. This helps the team members get the same understanding of the problem, so that they can think systematically. The root causes of a problem can by using this structured approach be found, while encouraging group participation, utilising group knowledge and identifying areas where data should be collected for future studies. Hence the name, the diagram has the same structure as the skeleton of a fish. While it most often is used in a simple representation, with segments leaning on a horizontal axis, it can also be done with a more extensive approach. An example of this is by naming and coding of the risks which characterises the causes and sub-causes. This consists of elements that show the causes and sub-causes succession with different ways for risk treatment [1].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:A-generic-representation-of-the-Ishikawa-diagram-aka-Fishbone-diagram.png|400px|thumb|centre|Figure 2: Illustration of a Fishbone diagram]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;To successfully use the fishbone diagram as a tool for analysing root causes, five steps should be followed:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#The first step is to state the problem precisely. This problem statement must be carefully chosen, and it is important that it is specific enough.&lt;br /&gt;
#Define the main influencing factors. This is the factors are put in the horizontal category segments in the fishbone diagram. Different defects or problems have different influencing, which means that these should be chosen after what is relevant. Examples of these is seen in the figure above.&lt;br /&gt;
#State the causes into the diagram sorted after the different categories. This should be done with those employees that are directly involved in the problem causing processes. Also, the team should consist of a mix of different levels of expertise. When analysing the problem statement and finding causes, further sub-causes can be elaborated upon.&lt;br /&gt;
#Prioritise the causes. In the same team, make each person state their opinion as what is the most serious cause of the defect or problem. After a discussion about the causes, each person can give points to the causes that they believe are the most serious. The causes with the most points, should then be prioritised.&lt;br /&gt;
#Take measures. Tackle the defect or problem by eradicating the cause or causes. I it’s important that it is certain that the correct cause have been identified. To make sure of this, a significance test can be used for verifying, in order to select suitable methods for problem-solving.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== The 5 Whys ===&lt;br /&gt;
The 5 whys is a simple, yet powerful way of finding root causes. It works as an iterative interrogative technique to explore cause-and-effect relationship underlaying a particular problem. It is often used together with the a Fishbone diagram to find the root causes for the causes on the diagram.  As the name of technique implies, the primary goal is to find the root cause of a problem by asking “Why?” five times. Each answer of the “Whys” forms the basis for the next question, and when the fifth “Why?” have been answered, the root cause should be found. Five times is generally enough, but if the root cause still not is found, it could be repeated up to a total of six, seven or higher levels. For problems or defects that do not have one single root cause, the technique must be repeated asking a different sequence of questions each time. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:5-whys-example (1).png|400px|thumb|right|Illustration of a Fishbone diagram]]&lt;br /&gt;
&lt;br /&gt;
 &lt;br /&gt;
&#039;&#039;&#039;The five steps to conduct the 5 whys analysis, is to:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather a team who can develop a problem statement in agreement. At this point, it should be discussed whether additionally individuals are needed to resolve the problem. &lt;br /&gt;
#Make the team come with statements on “Why is this or that defect or problem taking place?”. This is the first “why” of the analysis. There are most probable multiple statements for this, and they should all be written down.&lt;br /&gt;
#Repeat the same process asking “why” four more times. This should be done for every statement from the first “why” in the structure like the figure below shows. All plausible answers should be written down. When the “why” does not yield further useful information, you have found the root cause. This means that is sometimes may take more than five layers to find the root cause.&lt;br /&gt;
#Among the many answers to the last asked “why”, look for systematic causes of the defect or problem. This should be discussed in the group to be able to settle for the most likely systematic cause. The product from the team session should then be showed to others to confirm that they see the same logic in the analysis.&lt;br /&gt;
#The last and final step of the 5 why analysis is to develop appropriate corrective actions to remove the root cause from the system. Others can undertake these actions but planning and implementation will benefit from inputs from the team.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:Pareto output.png|200px|thumb|right|The 20/80 principle]]&lt;br /&gt;
===Pareto Chart Analysis===&lt;br /&gt;
The Pareto chart combines a histogram (bar chart) and a line chart, where cost or frequency of defects or problems show their relative importance. Frequencies are shown in the histogram with descending order of the bars, and the line chart shows the totals or the cumulative percentages increasing from left to right. It is based on the Pareto principle, which states that “80% of the effects or consequences come from 20% of the causes”. This is not like the immutable laws of physics but based on continuous observations. On those observations, it has showed to be applicable to many aspects of life and natural phenomena. In relation to a root cause analysis, the Pareto Chart Analysis helps identify the top 20% of the causes that needs to be addressed to resolve 80% of the problems.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:Pareto-chart-example.png|400px|thumb|right|An example of a Pareto Chart Analysis]]&lt;br /&gt;
&#039;&#039;&#039;In order to perform a Pareto Chart Analysis, the following needs to be done:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather and collect data on the frequency of the causes of a defect or problem.&lt;br /&gt;
#Sort the causes after most to least important, and then calculate the cumulative percentage.&lt;br /&gt;
#Plot bars of the causes ordered from most to least frequent on the x-axis, and then plot the cumulative percentages on the y-axis. &lt;br /&gt;
#Finally, separate the 20% most important root causes from the rest by lifting the x-axis to the 80% cumulative percent on the y-axis.&lt;br /&gt;
&lt;br /&gt;
 &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Challenges and limitations == &lt;br /&gt;
&lt;br /&gt;
For the Root Cause Analysis to give results, it is dependent on a larger problem-solving effort to improve the quality in a business. It therefore the managements responsibility to make the best use of the findings from the root cause analyses. The root cause analysis on itself would not provide the correct result. When it comes to the conduction of a root cause analysis, it is hard to fully know if you have taken every root cause into consideration. The reason for this is because there can be multiple root causes, and there is hard to tell when every root cause has been found. This can lead to too much time spent on irrelevant underlaying factors, which result in confusion and a waste of time. The 5 whys and the fishbone analysis does not rely on specific data, which can lead to less reliable results. The management can therefore have trouble entirely trusting these analyses. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Annotated Bibliography==&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122244</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122244"/>
		<updated>2022-03-27T12:18:57Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Root Cause Analysis (RCA) is a method of problem solving that can be used in a project, program or portfolio (PPP) to identify root causes of faults and problems in order to identify appropriate solutions. It is broadly used in several industries, among the health care, infrastructure and information technology industry. A Root Cause Analysis supposes that it is more effective to go in-depth of occurring problems, so that the underlaying issue can be treated, instead of only treating ad hoc symptoms. Root Cause Analyses can be performed with several different methodologies, principles and techniques together to identify the root causes of a fault or problem. The goal is to find out where processes or systems failed or caused an issue in the first place.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A Root Cause Analysis can be divided into four steps:&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; – What went wrong? Do not look at symptoms of the fault or problem, but discover what specifically went wrong and caused the fault or problem.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Establish a timeline&#039;&#039;&#039; – Establish a timeline that specifies how the situation went from normal to problematical.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Distinguish root causes from other casual factors&#039;&#039;&#039; – Sort out factors that actually made the failure or problem occur. This can e.g. be done using event correlation.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Establish an overview between the root cause and the problem&#039;&#039;&#039; – Document how the root cause caused the fault or problem, this can be done e.g. with a casual graph.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
To be able to fully understand what a root cause analysis is and what it is used for, it is easier to relate it to something we are entirely acknowledged with. If your arm hurts considerably after an accident, you will go to the doctor to find the root cause of your pain. Also, if your computer stops working, you will try to find the root cause of its malfunction, either by yourself or by a professional technician. For these examples, a simple remedy could be found for the symptoms. To stop your arm from hurting, you could put ice on it to relive pain. To get work done with a broken computer, you could use your phone or tablet instead. Unfortunately, this would only consider the symptoms and not the underlaying issue that caused the problem. The injured arm may need surgery to entirely recover from the sustained injury, and the broken computer may need to have a new battery to function again. The best way to solve a fault or problem would therefore be to perform a Root Cause Analysis. By doing this, the exact root cause can be found so that the correct management of the fault or problem will be accomplished.&lt;br /&gt;
There are a number of techniques and strategies that can be used for root cause analyses. In this article, the most commonly and widely used techniques will be covered.&lt;br /&gt;
&lt;br /&gt;
===== Goals and benefits =====&lt;br /&gt;
&lt;br /&gt;
Related to the root cause analysis, there are three goals that should be realised. The first one being to discover the root cause of a failure or problem. The second is to develop an understanding on how to fix and learn from the underlaying issues relating the root cause. The third and final is to apply the findings from the root cause analysis, to systematically prevent future issues or problems. The third goal is especially important as this is what gives the analysis a reason to be performed. Root cause analysis can be used for increasing the productiveness in several core processes as well, with the goal to prevent problems in the future. Instead of replacing punctured bike tires on rental bikes, puncture proof tires could be installed instead if the problem persists.&lt;br /&gt;
&lt;br /&gt;
===== General principles =====&lt;br /&gt;
&lt;br /&gt;
To achieve an effective root cause analysis process, there are some general principles that should be taken into consideration. These principles will increase the quality of the analysis and will help the analysis get trust from clients and stakeholders.&lt;br /&gt;
&lt;br /&gt;
*Consider to actually correct and remedy the root causes, not only the symptoms.&lt;br /&gt;
*While performing the root cause analysis, also remember to treat symptoms for short term fixing.&lt;br /&gt;
*Avoid focus on who was responsible of the failure or problem, instead focus on how and why.&lt;br /&gt;
*Find and document ways to prevent similar root causes in the future.&lt;br /&gt;
*When finding root causes, provide cause-effect evidence to back it up.&lt;br /&gt;
*Often there are multiple root causes, therefore search for several.&lt;br /&gt;
&lt;br /&gt;
As it can be understood from the principles above, it is important to take a comprehensive and holistic approach in this type of analysis. As the root causes have no importance if no action is taken afterwards, it should be strived to provide information and context that can solve the failure or problem.&lt;br /&gt;
 &lt;br /&gt;
== Conducting a root cause analysis ==&lt;br /&gt;
&lt;br /&gt;
There is not one specific way of performing a root cause analysis as there are many different techniques and strategies that can be used. In this chapter, the most common and broadly used techniques will be covered. Root cause analyses gives the best effect when a team is gathered, to do the analysis together. In particular, it should be done with those employees, who are directly involved in the problem-causing processes.&lt;br /&gt;
&lt;br /&gt;
=== Fishbone Diagram ===&lt;br /&gt;
[[File:A-generic-representation-of-the-Ishikawa-diagram-aka-Fishbone-diagram.png|300px|thumb|right|Illustration of a Fishbone diagram]]&lt;br /&gt;
A Fishbone diagram, which also is called an Ishikawa diagram, is used to identify root causes of quality problems [1]. The fishbone diagram provides an organised way of looking at effects and causes. It can also be referred to as a cause-and-effect diagram (Watson, 2004). It generally represents a model of indicative presentation for the correlations between an event, which is an effect, and its several causes. This helps the team members get the same understanding of the problem, so that they can think systematically. The root causes of a problem can by using this structured approach be found, while encouraging group participation, utilising group knowledge and identifying areas where data should be collected for future studies. Hence the name, the diagram has the same structure as the skeleton of a fish. While it most often is used in a simple representation, with segments leaning on a horizontal axis, it can also be done with a more extensive approach. An example of this is by naming and coding of the risks which characterises the causes and sub-causes. This consists of elements that show the causes and sub-causes succession with different ways for risk treatment [1].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;To successfully use the fishbone diagram as a tool for analysing root causes, five steps should be followed:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#The first step is to state the problem precisely. This problem statement must be carefully chosen, and it is important that it is specific enough.&lt;br /&gt;
#Define the main influencing factors. This is the factors are put in the horizontal category segments in the fishbone diagram. Different defects or problems have different influencing, which means that these should be chosen after what is relevant. Examples of these is seen in the figure above.&lt;br /&gt;
#State the causes into the diagram sorted after the different categories. This should be done with those employees that are directly involved in the problem causing processes. Also, the team should consist of a mix of different levels of expertise. When analysing the problem statement and finding causes, further sub-causes can be elaborated upon.&lt;br /&gt;
#Prioritise the causes. In the same team, make each person state their opinion as what is the most serious cause of the defect or problem. After a discussion about the causes, each person can give points to the causes that they believe are the most serious. The causes with the most points, should then be prioritised.&lt;br /&gt;
#Take measures. Tackle the defect or problem by eradicating the cause or causes. I it’s important that it is certain that the correct cause have been identified. To make sure of this, a significance test can be used for verifying, in order to select suitable methods for problem-solving.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== The 5 Whys ===&lt;br /&gt;
The 5 whys is a simple, yet powerful way of finding root causes. It works as an iterative interrogative technique to explore cause-and-effect relationship underlaying a particular problem. It is often used together with the a Fishbone diagram to find the root causes for the causes on the diagram.  As the name of technique implies, the primary goal is to find the root cause of a problem by asking “Why?” five times. Each answer of the “Whys” forms the basis for the next question, and when the fifth “Why?” have been answered, the root cause should be found. Five times is generally enough, but if the root cause still not is found, it could be repeated up to a total of six, seven or higher levels. For problems or defects that do not have one single root cause, the technique must be repeated asking a different sequence of questions each time. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:5-whys-example (1).png|400px|thumb|right|Illustration of a Fishbone diagram]]&lt;br /&gt;
&lt;br /&gt;
 &lt;br /&gt;
&#039;&#039;&#039;The five steps to conduct the 5 whys analysis, is to:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather a team who can develop a problem statement in agreement. At this point, it should be discussed whether additionally individuals are needed to resolve the problem. &lt;br /&gt;
#Make the team come with statements on “Why is this or that defect or problem taking place?”. This is the first “why” of the analysis. There are most probable multiple statements for this, and they should all be written down.&lt;br /&gt;
#Repeat the same process asking “why” four more times. This should be done for every statement from the first “why” in the structure like the figure below shows. All plausible answers should be written down. When the “why” does not yield further useful information, you have found the root cause. This means that is sometimes may take more than five layers to find the root cause.&lt;br /&gt;
#Among the many answers to the last asked “why”, look for systematic causes of the defect or problem. This should be discussed in the group to be able to settle for the most likely systematic cause. The product from the team session should then be showed to others to confirm that they see the same logic in the analysis.&lt;br /&gt;
#The last and final step of the 5 why analysis is to develop appropriate corrective actions to remove the root cause from the system. Others can undertake these actions but planning and implementation will benefit from inputs from the team.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===Pareto Chart Analysis===&lt;br /&gt;
&lt;br /&gt;
The Pareto chart combines a histogram (bar chart) and a line chart, where cost or frequency of defects or problems show their relative importance. Frequencies are shown in the histogram with descending order of the bars, and the line chart shows the totals or the cumulative percentages increasing from left to right. It is based on the Pareto principle, which states that “80% of the effects or consequences come from 20% of the causes”. This is not like the immutable laws of physics but based on continuous observations. On those observations, it has showed to be applicable to many aspects of life and natural phenomena. In relation to a root cause analysis, the Pareto Chart Analysis helps identify the top 20% of the causes that needs to be addressed to resolve 80% of the problems.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;In order to perform a Pareto Chart Analysis, the following needs to be done:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#Gather and collect data on the frequency of the causes of a defect or problem.&lt;br /&gt;
#Sort the causes after most to least important, and then calculate the cumulative percentage.&lt;br /&gt;
#Plot bars of the causes ordered from most to least frequent on the x-axis, and then plot the cumulative percentages on the y-axis. &lt;br /&gt;
#Finally, separate the 20% most important root causes from the rest by lifting the x-axis to the 80% cumulative percent on the y-axis.&lt;br /&gt;
&lt;br /&gt;
 &lt;br /&gt;
== Challenges and limitations == &lt;br /&gt;
&lt;br /&gt;
For the Root Cause Analysis to give results, it is dependent on a larger problem-solving effort to improve the quality in a business. It therefore the managements responsibility to make the best use of the findings from the root cause analyses. The root cause analysis on itself would not provide the correct result. When it comes to the conduction of a root cause analysis, it is hard to fully know if you have taken every root cause into consideration. The reason for this is because there can be multiple root causes, and there is hard to tell when every root cause has been found. This can lead to too much time spent on irrelevant underlaying factors, which result in confusion and a waste of time. The 5 whys and the fishbone analysis does not rely on specific data, which can lead to less reliable results. The management can therefore have trouble entirely trusting these analyses. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Annotated Bibliography==&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=File:5-whys-example_(1).png&amp;diff=122233</id>
		<title>File:5-whys-example (1).png</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=File:5-whys-example_(1).png&amp;diff=122233"/>
		<updated>2022-03-27T12:08:25Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=File:A-generic-representation-of-the-Ishikawa-diagram-aka-Fishbone-diagram.png&amp;diff=122224</id>
		<title>File:A-generic-representation-of-the-Ishikawa-diagram-aka-Fishbone-diagram.png</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=File:A-generic-representation-of-the-Ishikawa-diagram-aka-Fishbone-diagram.png&amp;diff=122224"/>
		<updated>2022-03-27T11:54:34Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=File:Pareto-chart-example.png&amp;diff=122223</id>
		<title>File:Pareto-chart-example.png</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=File:Pareto-chart-example.png&amp;diff=122223"/>
		<updated>2022-03-27T11:54:24Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=File:Pareto_output.png&amp;diff=122222</id>
		<title>File:Pareto output.png</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=File:Pareto_output.png&amp;diff=122222"/>
		<updated>2022-03-27T11:54:16Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122221</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122221"/>
		<updated>2022-03-27T11:53:51Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Root Cause Analysis (RCA) is a method of problem solving that can be used in a project, program or portfolio (PPP) to identify root causes of faults and problems in order to identify appropriate solutions. It is broadly used in several industries, among the health care, infrastructure and information technology industry. A Root Cause Analysis supposes that it is more effective to go in-depth of occurring problems, so that the underlaying issue can be treated, instead of only treating ad hoc symptoms. Root Cause Analyses can be performed with several different methodologies, principles and techniques together to identify the root causes of a fault or problem. The goal is to find out where processes or systems failed or caused an issue in the first place.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A Root Cause Analysis can be divided into four steps:&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; – What went wrong? Do not look at symptoms of the fault or problem, but discover what specifically went wrong and caused the fault or problem.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Establish a timeline&#039;&#039;&#039; – Establish a timeline that specifies how the situation went from normal to problematical.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Distinguish root causes from other casual factors&#039;&#039;&#039; – Sort out factors that actually made the failure or problem occur. This can e.g. be done using event correlation.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Establish an overview between the root cause and the problem&#039;&#039;&#039; – Document how the root cause caused the fault or problem, this can be done e.g. with a casual graph.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
To be able to fully understand what a root cause analysis is and what it is used for, it is easier to relate it to something we are entirely acknowledged with. If your arm hurts considerably after an accident, you will go to the doctor to find the root cause of your pain. Also, if your computer stops working, you will try to find the root cause of its malfunction, either by yourself or by a professional technician. For these examples, a simple remedy could be found for the symptoms. To stop your arm from hurting, you could put ice on it to relive pain. To get work done with a broken computer, you could use your phone or tablet instead. Unfortunately, this would only consider the symptoms and not the underlaying issue that caused the problem. The injured arm may need surgery to entirely recover from the sustained injury, and the broken computer may need to have a new battery to function again. The best way to solve a fault or problem would therefore be to perform a Root Cause Analysis. By doing this, the exact root cause can be found so that the correct management of the fault or problem will be accomplished.&lt;br /&gt;
There are a number of techniques and strategies that can be used for root cause analyses. In this article, the most commonly and widely used techniques will be covered.&lt;br /&gt;
&lt;br /&gt;
===== Goals and benefits =====&lt;br /&gt;
&lt;br /&gt;
Related to the root cause analysis, there are three goals that should be realised. The first one being to discover the root cause of a failure or problem. The second is to develop an understanding on how to fix and learn from the underlaying issues relating the root cause. The third and final is to apply the findings from the root cause analysis, to systematically prevent future issues or problems. The third goal is especially important as this is what gives the analysis a reason to be performed. Root cause analysis can be used for increasing the productiveness in several core processes as well, with the goal to prevent problems in the future. Instead of replacing punctured bike tires on rental bikes, puncture proof tires could be installed instead if the problem persists.&lt;br /&gt;
&lt;br /&gt;
===== General principles =====&lt;br /&gt;
&lt;br /&gt;
To achieve an effective root cause analysis process, there are some general principles that should be taken into consideration. These principles will increase the quality of the analysis and will help the analysis get trust from clients and stakeholders.&lt;br /&gt;
&lt;br /&gt;
*Consider to actually correct and remedy the root causes, not only the symptoms.&lt;br /&gt;
*While performing the root cause analysis, also remember to treat symptoms for short term fixing.&lt;br /&gt;
*Avoid focus on who was responsible of the failure or problem, instead focus on how and why.&lt;br /&gt;
*Find and document ways to prevent similar root causes in the future.&lt;br /&gt;
*When finding root causes, provide cause-effect evidence to back it up.&lt;br /&gt;
*Often there are multiple root causes, therefore search for several.&lt;br /&gt;
&lt;br /&gt;
As it can be understood from the principles above, it is important to take a comprehensive and holistic approach in this type of analysis. As the root causes have no importance if no action is taken afterwards, it should be strived to provide information and context that can solve the failure or problem.&lt;br /&gt;
 &lt;br /&gt;
== Conducting a root cause analysis ==&lt;br /&gt;
&lt;br /&gt;
There is not one specific way of performing a root cause analysis as there are many different techniques and strategies that can be used. In this chapter, the most common and broadly used techniques will be covered. Root cause analyses gives the best effect when a team is gathered, to do the analysis together. In particular, it should be done with those employees, who are directly involved in the problem-causing processes.&lt;br /&gt;
&lt;br /&gt;
=== Fishbone Diagram ===&lt;br /&gt;
A Fishbone diagram, which also is called an Ishikawa diagram, is used to identify root causes of quality problems [1]. The fishbone diagram provides an organised way of looking at effects and causes. It can also be referred to as a cause-and-effect diagram (Watson, 2004). It generally represents a model of indicative presentation for the correlations between an event, which is an effect, and its several causes. This helps the team members get the same understanding of the problem, so that they can think systematically. The root causes of a problem can by using this structured approach be found, while encouraging group participation, utilising group knowledge and identifying areas where data should be collected for future studies. Hence the name, the diagram has the same structure as the skeleton of a fish. While it most often is used in a simple representation, with segments leaning on a horizontal axis, it can also be done with a more extensive approach. An example of this is by naming and coding of the risks which characterises the causes and sub-causes. This consists of elements that show the causes and sub-causes succession with different ways for risk treatment [1].&lt;br /&gt;
 &lt;br /&gt;
Figure 1[[File:Example.jpg]]&lt;br /&gt;
&lt;br /&gt;
https://www.researchgate.net/figure/A-generic-representation-of-the-Ishikawa-diagram-aka-Fishbone-diagram_fig1_317196193&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;To successfully use the fishbone diagram as a tool for analysing root causes, five steps should be followed:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
#The first step is to state the problem precisely. This problem statement must be carefully chosen, and it is important that it is specific enough.&lt;br /&gt;
#Define the main influencing factors. This is the factors are put in the horizontal category segments in the fishbone diagram. Different defects or problems have different influencing, which means that these should be chosen after what is relevant. Examples of these is seen in the figure above.&lt;br /&gt;
#State the causes into the diagram sorted after the different categories. This should be done with those employees that are directly involved in the problem causing processes. Also, the team should consist of a mix of different levels of expertise. When analysing the problem statement and finding causes, further sub-causes can be elaborated upon.&lt;br /&gt;
#Prioritise the causes. In the same team, make each person state their opinion as what is the most serious cause of the defect or problem. After a discussion about the causes, each person can give points to the causes that they believe are the most serious. The causes with the most points, should then be prioritised.&lt;br /&gt;
#Take measures. Tackle the defect or problem by eradicating the cause or causes. I it’s important that it is certain that the correct cause have been identified. To make sure of this, a significance test can be used for verifying, in order to select suitable methods for problem-solving.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
https://www.ionos.ca/startupguide/productivity/fishbone-diagram/&lt;br /&gt;
Figure 2 - Wall Street MOJO&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== The 5 Whys ===&lt;br /&gt;
The 5 whys is a simple, yet powerful way of finding root causes. It works as an iterative interrogative technique to explore cause-and-effect relationship underlaying a particular problem. It is often used together with the a Fishbone diagram to find the root causes for the causes on the diagram.  As the name of technique implies, the primary goal is to find the root cause of a problem by asking “Why?” five times. Each answer of the “Whys” forms the basis for the next question, and when the fifth “Why?” have been answered, the root cause should be found. Five times is generally enough, but if the root cause still not is found, it could be repeated up to a total of six, seven or higher levels. For problems or defects that do not have one single root cause, the technique must be repeated asking a different sequence of questions each time. &lt;br /&gt;
&lt;br /&gt;
 &lt;br /&gt;
&#039;&#039;&#039;The five steps to conduct the 5 whys analysis, is to:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
1.	Gather a team who can develop a problem statement in agreement. At this point, it should be discussed whether additionally individuals are needed to resolve the problem. &lt;br /&gt;
2.	Make the team come with statements on “Why is this or that defect or problem taking place?”. This is the first “why” of the analysis. There are most probable multiple statements for this, and they should all be written down.&lt;br /&gt;
3.	Repeat the same process asking “why” four more times. This should be done for every statement from the first “why” in the structure like the figure below shows. All plausible answers should be written down. When the “why” does not yield further useful information, you have found the root cause. This means that is sometimes may take more than five layers to find the root cause.&lt;br /&gt;
4.	Among the many answers to the last asked “why”, look for systematic causes of the defect or problem. This should be discussed in the group to be able to settle for the most likely systematic cause. The product from the team session should then be showed to others to confirm that they see the same logic in the analysis.&lt;br /&gt;
5.	The last and final step of the 5 why analysis is to develop appropriate corrective actions to remove the root cause from the system. Others can undertake these actions but planning and implementation will benefit from inputs from the team.&lt;br /&gt;
&lt;br /&gt;
https://www.adb.org/publications/five-whys-technique&lt;br /&gt;
&lt;br /&gt;
chrome-extension://efaidnbmnnnibpcajpcglclefindmkaj/viewer.html?pdfurl=http%3A%2F%2Fmrp.ase.ro%2Fno21%2Ff1.pdf&amp;amp;clen=308820&amp;amp;chunk=true&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
 &lt;br /&gt;
===Pareto Chart Analysis===&lt;br /&gt;
&lt;br /&gt;
The Pareto chart combines a histogram (bar chart) and a line chart, where cost or frequency of defects or problems show their relative importance. Frequencies are shown in the histogram with descending order of the bars, and the line chart shows the totals or the cumulative percentages increasing from left to right. It is based on the Pareto principle, which states that “80% of the effects or consequences come from 20% of the causes”. This is not like the immutable laws of physics but based on continuous observations. On those observations, it has showed to be applicable to many aspects of life and natural phenomena. In relation to a root cause analysis, the Pareto Chart Analysis helps identify the top 20% of the causes that needs to be addressed to resolve 80% of the problems.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;In order to perform a Pareto Chart Analysis, the following needs to be done:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
1.	Gather and collect data on the frequency of the causes of a defect or problem.&lt;br /&gt;
2.	Sort the causes after most to least important, and then calculate the cumulative percentage.&lt;br /&gt;
3.	Plot bars of the causes ordered from most to least frequent on the x-axis, and then plot the cumulative percentages on the y-axis. &lt;br /&gt;
4.	Finally, separate the 20% most important root causes from the rest by lifting the x-axis to the 80% cumulative percent on the y-axis.&lt;br /&gt;
&lt;br /&gt;
 &lt;br /&gt;
 &lt;br /&gt;
== Challenges and limitations == &lt;br /&gt;
&lt;br /&gt;
For the Root Cause Analysis to give results, it is dependent on a larger problem-solving effort to improve the quality in a business. It therefore the managements responsibility to make the best use of the findings from the root cause analyses. The root cause analysis on itself would not provide the correct result. When it comes to the conduction of a root cause analysis, it is hard to fully know if you have taken every root cause into consideration. The reason for this is because there can be multiple root causes, and there is hard to tell when every root cause has been found. This can lead to too much time spent on irrelevant underlaying factors, which result in confusion and a waste of time. The 5 whys and the fishbone analysis does not rely on specific data, which can lead to less reliable results. The management can therefore have trouble entirely trusting these analyses. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Annotated Bibliography==&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122216</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=122216"/>
		<updated>2022-03-27T11:46:24Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Root Cause Analysis (RCA) is a method of problem solving that can be used in a project, program or portfolio (PPP) to identify root causes of faults and problems in order to identify appropriate solutions. It is broadly used in several industries, among the health care, infrastructure and information technology industry. A Root Cause Analysis supposes that it is more effective to go in-depth of occurring problems, so that the underlaying issue can be treated, instead of only treating ad hoc symptoms. Root Cause Analyses can be performed with several different methodologies, principles and techniques together to identify the root causes of a fault or problem. The goal is to find out where processes or systems failed or caused an issue in the first place.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A Root Cause Analysis can be divided into four steps:&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; – What went wrong? Do not look at symptoms of the fault or problem, but discover what specifically went wrong and caused the fault or problem.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Establish a timeline&#039;&#039;&#039; – Establish a timeline that specifies how the situation went from normal to problematical.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Distinguish root causes from other casual factors&#039;&#039;&#039; – Sort out factors that actually made the failure or problem occur. This can e.g. be done using event correlation.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Establish an overview between the root cause and the problem&#039;&#039;&#039; – Document how the root cause caused the fault or problem, this can be done e.g. with a casual graph.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
To be able to fully understand what a root cause analysis is and what it is used for, it is easier to relate it to something we are entirely acknowledged with. If your arm hurts considerably after an accident, you will go to the doctor to find the root cause of your pain. Also, if your computer stops working, you will try to find the root cause of its malfunction, either by yourself or by a professional technician. For these examples, a simple remedy could be found for the symptoms. To stop your arm from hurting, you could put ice on it to relive pain. To get work done with a broken computer, you could use your phone or tablet instead. Unfortunately, this would only consider the symptoms and not the underlaying issue that caused the problem. The injured arm may need surgery to entirely recover from the sustained injury, and the broken computer may need to have a new battery to function again. The best way to solve a fault or problem would therefore be to perform a Root Cause Analysis. By doing this, the exact root cause can be found so that the correct management of the fault or problem will be accomplished.&lt;br /&gt;
There are a number of techniques and strategies that can be used for root cause analyses. In this article, the most commonly and widely used techniques will be covered.&lt;br /&gt;
&lt;br /&gt;
===Goals and benefits===&lt;br /&gt;
&lt;br /&gt;
Related to the root cause analysis, there are three goals that should be realized. The first one being to discover the root cause of a failure or problem. The second is to develop an understanding on how to fix and learn from the underlaying issues relating the root cause. The third and final is to apply the findings from the root cause analysis, to systematically prevent future issues or problems. The third goal is especially important as this is what gives the analysis a reason to be performed. Root cause analysis can be used for increasing the productiveness in several core processes as well, with the goal to prevent problems in the future. Instead of replacing punctured bike tires on rental bikes, puncture proof tires could be installed instead if the problem persists.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== General principles ====&lt;br /&gt;
&lt;br /&gt;
To achieve an effective root cause analysis process, there are some general principles that should be taken into consideration. These principles will increase the quality of the analysis and will help the analysis get trust from clients and stakeholders.&lt;br /&gt;
&lt;br /&gt;
*Consider to actually correct and remedy the root causes, not only the symptoms.&lt;br /&gt;
*While performing the root cause analysis, also remember to treat symptoms for short term fixing.&lt;br /&gt;
*Avoid focus on who was responsible of the failure or problem, instead focus on how and why.&lt;br /&gt;
*Find and document ways to prevent similar root causes in the future.&lt;br /&gt;
*When finding root causes, provide cause-effect evidence to back it up.&lt;br /&gt;
*Often there are multiple root causes, therefore search for several.&lt;br /&gt;
&lt;br /&gt;
As it can be understood from the principles above, it is important to take a comprehensive and holistic approach in this type of analysis. As the root causes have no importance if no action is taken afterwards, it should be strived to provide information and context that can solve the failure or problem.&lt;br /&gt;
 &lt;br /&gt;
== Conducting a root cause analysis ==&lt;br /&gt;
&lt;br /&gt;
There is not one specific way of performing a root cause analysis as there are many different techniques and strategies that can be used. In this chapter, the most common and broadly used techniques will be covered. Root cause analyses gives the best effect when a team is gathered, to do the analysis together. In particular, it should be done with those employees, who are directly involved in the problem-causing processes.&lt;br /&gt;
&lt;br /&gt;
=== Fishbone Diagram ===&lt;br /&gt;
A Fishbone diagram, which also is called an Ishikawa diagram, is used to identify root causes of quality problems [1]. The fishbone diagram provides an organized way of looking at effects and causes. It can also be referred to as a cause-and-effect diagram (Watson, 2004). It generally represents a model of indicative presentation for the correlations between an event, which is an effect, and its several causes. This helps the team members get the same understanding of the problem, so that they can think systematically. The root causes of a problem can by using this structured approach be found, while encouraging group participation, utilizing group knowledge and identifying areas where data should be collected for future studies. Hence the name, the diagram has the same structure as the skeleton of a fish. While it most often is used in a simple representation, with segments leaning on a horizontal axis, it can also be done with a more extensive approach. An example of this is by naming and coding of the risks which characterizes the causes and sub-causes. This consists of elements that show the causes and sub-causes succession with different ways for risk treatment [1].&lt;br /&gt;
 &lt;br /&gt;
Figure 1https://www.researchgate.net/figure/A-generic-representation-of-the-Ishikawa-diagram-aka-Fishbone-diagram_fig1_317196193&lt;br /&gt;
To successfully use the fishbone diagram as a tool for analyzing root causes, five steps should be followed:&lt;br /&gt;
&lt;br /&gt;
1.	The first step is to state the problem precisely. This problem statement must be carefully chosen, and it is important that it is specific enough.&lt;br /&gt;
2.	Define the main influencing factors. This is the factors are put in the horizontal category segments in the fishbone diagram. Different defects or problems have different influencing, which means that these should be chosen after what is relevant. Examples of these is seen in the figure above.&lt;br /&gt;
3.	State the causes into the diagram sorted after the different categories. This should be done with those employees that are directly involved in the problem causing processes. Also, the team should consist of a mix of different levels of expertise. When analyzing the problem statement and finding causes, further sub-causes can be elaborated upon.&lt;br /&gt;
4.	Prioritize the causes. In the same team, make each person state their opinion as what is the most serious cause of the defect or problem. After a discussion about the causes, each person can give points to the causes that they believe are the most serious. The causes with the most points, should then be prioritized.&lt;br /&gt;
5.	Take measures. Tackle the defect or problem by eradicating the cause or causes. I it’s important that it is certain that the correct cause have been identified. To make sure of this, a significance test can be used for verifying, in order to select suitable methods for problem-solving.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
https://www.ionos.ca/startupguide/productivity/fishbone-diagram/&lt;br /&gt;
&lt;br /&gt;
 &lt;br /&gt;
Figure 2 - Wall Street MOJO&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== The 5 Whys ===&lt;br /&gt;
The 5 whys is a simple, yet powerful way of finding root causes. It works as an iterative interrogative technique to explore cause-and-effect relationship underlaying a particular problem. It is often used together with the a Fishbone diagram to find the root causes for the causes on the diagram.  As the name of technique implies, the primary goal is to find the root cause of a problem by asking “Why?” five times. Each answer of the “Whys” forms the basis for the next question, and when the fifth “Why?” have been answered, the root cause should be found. Five times is generally enough, but if the root cause still not is found, it could be repeated up to a total of six, seven or higher levels. For problems or defects that do not have one single root cause, the technique must be repeated asking a different sequence of questions each time. &lt;br /&gt;
&lt;br /&gt;
 &lt;br /&gt;
The five steps to conduct the 5 whys analysis, is to:&lt;br /&gt;
1.	Gather a team who can develop a problem statement in agreement. At this point, it should be discussed whether additionally individuals are needed to resolve the problem. &lt;br /&gt;
2.	Make the team come with statements on “Why is this or that defect or problem taking place?”. This is the first “why” of the analysis. There are most probable multiple statements for this, and they should all be written down.&lt;br /&gt;
3.	Repeat the same process asking “why” four more times. This should be done for every statement from the first “why” in the structure like the figure below shows. All plausible answers should be written down. When the “why” does not yield further useful information, you have found the root cause. This means that is sometimes may take more than five layers to find the root cause.&lt;br /&gt;
4.	Among the many answers to the last asked “why”, look for systematic causes of the defect or problem. This should be discussed in the group to be able to settle for the most likely systematic cause. The product from the team session should then be showed to others to confirm that they see the same logic in the analysis.&lt;br /&gt;
5.	The last and final step of the 5 why analysis is to develop appropriate corrective actions to remove the root cause from the system. Others can undertake these actions but planning and implementation will benefit from inputs from the team.&lt;br /&gt;
&lt;br /&gt;
https://www.adb.org/publications/five-whys-technique&lt;br /&gt;
&lt;br /&gt;
chrome-extension://efaidnbmnnnibpcajpcglclefindmkaj/viewer.html?pdfurl=http%3A%2F%2Fmrp.ase.ro%2Fno21%2Ff1.pdf&amp;amp;clen=308820&amp;amp;chunk=true&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
 &lt;br /&gt;
===Pareto Chart Analysis===&lt;br /&gt;
&lt;br /&gt;
The Pareto chart combines a histogram (bar chart) and a line chart, where cost or frequency of defects or problems show their relative importance. Frequencies are shown in the histogram with descending order of the bars, and the line chart shows the totals or the cumulative percentages increasing from left to right. It is based on the Pareto principle, which states that “80% of the effects or consequences come from 20% of the causes”. This is not like the immutable laws of physics but based on continuous observations. On those observations, it has showed to be applicable to many aspects of life and natural phenomena. In relation to a root cause analysis, the Pareto Chart Analysis helps identify the top 20% of the causes that needs to be addressed to resolve 80% of the problems.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In order to perform a Pareto Chart Analysis, the following needs to be done:&lt;br /&gt;
&lt;br /&gt;
1.	Gather and collect data on the frequency of the causes of a defect or problem.&lt;br /&gt;
2.	Sort the causes after most to least important, and then calculate the cumulative percentage.&lt;br /&gt;
3.	Plot bars of the causes ordered from most to least frequent on the x-axis, and then plot the cumulative percentages on the y-axis. &lt;br /&gt;
4.	Finally, separate the 20% most important root causes from the rest by lifting the x-axis to the 80% cumulative percent on the y-axis.&lt;br /&gt;
&lt;br /&gt;
 &lt;br /&gt;
 &lt;br /&gt;
== Challenges and limitations == &lt;br /&gt;
&lt;br /&gt;
For the Root Cause Analysis to give results, it is dependent on a larger problem-solving effort to improve the quality in a business. It therefore the managements responsibility to make the best use of the findings from the root cause analyses. The root cause analysis on itself would not provide the correct result. When it comes to the conduction of a root cause analysis, it is hard to fully know if you have taken every root cause into consideration. The reason for this is because there can be multiple root causes, and there is hard to tell when every root cause has been found. This can lead to too much time spent on irrelevant underlaying factors, which result in confusion and a waste of time. The 5 whys and the fishbone analysis does not rely on specific data, which can lead to less reliable results. The management can therefore have trouble entirely trusting these analyses. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Performing Root Cause Analyses for Successes&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
==Challenges==&lt;br /&gt;
&lt;br /&gt;
==Annotated Bibliography==&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=110850</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=110850"/>
		<updated>2022-02-25T10:44:27Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: /* Conducting an effective root cause analysis */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Root Cause Analysis (RCA) is a method of problem solving that can be used in a project, program or portfolio (PPP) to identify root causes of faults and problems in order to identify appropriate solutions. It is broadly used in several industries, among the health care, infrastructure and information technology industry. A Root Cause Analysis supposes that it is more effective to go in-depth of occurring problems, so that the underlaying issue can be treated, instead of only treating ad hoc symptoms. Root Cause Analyses can be performed with several different methodologies, principles and techniques together to identify the root causes of a fault or problem. The goal is to find out where processes or systems failed or caused an issue in the first place.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A Root Cause Analysis can be divided into four steps:&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; – What went wrong? Do not look at symptoms of the fault or problem, but discover what specifically went wrong and caused the fault or problem.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Establish a timeline&#039;&#039;&#039; – Establish a timeline that specifies how the situation went from normal to problematical.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Distinguish root causes from other casual factors&#039;&#039;&#039; – Sort out factors that actually made the failure or problem occur. This can e.g. be done using event correlation.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Establish an overview between the root cause and the problem&#039;&#039;&#039; – Document how the root cause caused the fault or problem, this can be done e.g. with a casual graph.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
To be able to fully understand what a root cause analysis is and what it is used for, it is easier to relate it to something we are entirely acknowledged with. If your arm hurts considerably after an accident, you will go to the doctor to find the root cause of your pain. Also, if your computer stops working, you will try to find the root cause of its malfunction, either by yourself or by a professional technician. For these examples, a simple remedy could be found for the symptoms. To stop your arm from hurting, you could put ice on it to relive pain. To get work done with a broken computer, you could use your phone or tablet instead. Unfortunately, this would only consider the symptoms and not the underlaying issue that caused the problem. The injured arm may need surgery to entirely recover from the sustained injury, and the broken computer may need to have a new battery to function again. The best way to solve a fault or problem would therefore be to perform a Root Cause Analysis. By doing this, the exact root cause can be found so that the correct management of the fault or problem will be accomplished.&lt;br /&gt;
&lt;br /&gt;
In this article, the Root Cause Analysis will be defined (**********************)&lt;br /&gt;
&lt;br /&gt;
==== Goals and Benefits of using a Root Cause Analysis ====&lt;br /&gt;
&lt;br /&gt;
Related to the root cause analysis, there are &#039;&#039;&#039;three goals&#039;&#039;&#039; that should be realised. &#039;&#039;&#039;The first&#039;&#039;&#039; one being to discover the root cause of a failure or problem. &#039;&#039;&#039;The second&#039;&#039;&#039; one is to develop an understanding on how to fix and learn from the underlaying issues relating the root cause. &#039;&#039;&#039;The third&#039;&#039;&#039; and final one is to apply the findings from the root cause analysis, to systematically prevent future issues or problems. Root cause analysis can be used for increasing the productiveness in several core processes as well, with the goal to prevent problems in the future. Instead of replacing punctured bike tires on rental bikes, puncture proof tires could be installed instead if the problem persists.&lt;br /&gt;
&lt;br /&gt;
==== General Principles ====&lt;br /&gt;
&lt;br /&gt;
To achieve an effective root cause analysis process, there are some general principles that should be taken into consideration. These principles will increase the quality of the analysis and will help the analysis get trust from clients and stakeholders.&lt;br /&gt;
&lt;br /&gt;
*Consider to actually correct and remedy the root causes, not only the symptoms.&lt;br /&gt;
*While performing the root cause analysis, also remember to treat symptoms for short term fixing.&lt;br /&gt;
*Avoid focus on who was responsible of the failure or problem, instead focus on how and why.&lt;br /&gt;
*Find and document ways to prevent similar root causes in the future.&lt;br /&gt;
*When finding root causes, provide cause-effect evidence to back it up.&lt;br /&gt;
*Often there are multiple root causes, therefore search for several.&lt;br /&gt;
&lt;br /&gt;
As it can be understood from the principles above, it is important to take a comprehensive and holistic approach in this type of analysis. As the root causes have no importance if no action is taken afterwards, it should be strived to provide information and context that can solve the failure or problem.&lt;br /&gt;
&lt;br /&gt;
==Conducting an effective root cause analysis==&lt;br /&gt;
There is not a specific correct way of performing a root cause analysis, as there are many different techniques and strategies that can be used. In this chapter, the most common and broadly used techniques will be covered. &lt;br /&gt;
&lt;br /&gt;
=== Fishbone Diagram ===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Performing Root Cause Analyses for Successes&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
==Challenges==&lt;br /&gt;
&lt;br /&gt;
==Annotated Bibliography==&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=110849</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=110849"/>
		<updated>2022-02-25T10:38:16Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: /* General Principles */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Root Cause Analysis (RCA) is a method of problem solving that can be used in a project, program or portfolio (PPP) to identify root causes of faults and problems in order to identify appropriate solutions. It is broadly used in several industries, among the health care, infrastructure and information technology industry. A Root Cause Analysis supposes that it is more effective to go in-depth of occurring problems, so that the underlaying issue can be treated, instead of only treating ad hoc symptoms. Root Cause Analyses can be performed with several different methodologies, principles and techniques together to identify the root causes of a fault or problem. The goal is to find out where processes or systems failed or caused an issue in the first place.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A Root Cause Analysis can be divided into four steps:&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; – What went wrong? Do not look at symptoms of the fault or problem, but discover what specifically went wrong and caused the fault or problem.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Establish a timeline&#039;&#039;&#039; – Establish a timeline that specifies how the situation went from normal to problematical.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Distinguish root causes from other casual factors&#039;&#039;&#039; – Sort out factors that actually made the failure or problem occur. This can e.g. be done using event correlation.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Establish an overview between the root cause and the problem&#039;&#039;&#039; – Document how the root cause caused the fault or problem, this can be done e.g. with a casual graph.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
To be able to fully understand what a root cause analysis is and what it is used for, it is easier to relate it to something we are entirely acknowledged with. If your arm hurts considerably after an accident, you will go to the doctor to find the root cause of your pain. Also, if your computer stops working, you will try to find the root cause of its malfunction, either by yourself or by a professional technician. For these examples, a simple remedy could be found for the symptoms. To stop your arm from hurting, you could put ice on it to relive pain. To get work done with a broken computer, you could use your phone or tablet instead. Unfortunately, this would only consider the symptoms and not the underlaying issue that caused the problem. The injured arm may need surgery to entirely recover from the sustained injury, and the broken computer may need to have a new battery to function again. The best way to solve a fault or problem would therefore be to perform a Root Cause Analysis. By doing this, the exact root cause can be found so that the correct management of the fault or problem will be accomplished.&lt;br /&gt;
&lt;br /&gt;
In this article, the Root Cause Analysis will be defined (**********************)&lt;br /&gt;
&lt;br /&gt;
==== Goals and Benefits of using a Root Cause Analysis ====&lt;br /&gt;
&lt;br /&gt;
Related to the root cause analysis, there are &#039;&#039;&#039;three goals&#039;&#039;&#039; that should be realised. &#039;&#039;&#039;The first&#039;&#039;&#039; one being to discover the root cause of a failure or problem. &#039;&#039;&#039;The second&#039;&#039;&#039; one is to develop an understanding on how to fix and learn from the underlaying issues relating the root cause. &#039;&#039;&#039;The third&#039;&#039;&#039; and final one is to apply the findings from the root cause analysis, to systematically prevent future issues or problems. Root cause analysis can be used for increasing the productiveness in several core processes as well, with the goal to prevent problems in the future. Instead of replacing punctured bike tires on rental bikes, puncture proof tires could be installed instead if the problem persists.&lt;br /&gt;
&lt;br /&gt;
==== General Principles ====&lt;br /&gt;
&lt;br /&gt;
To achieve an effective root cause analysis process, there are some general principles that should be taken into consideration. These principles will increase the quality of the analysis and will help the analysis get trust from clients and stakeholders.&lt;br /&gt;
&lt;br /&gt;
*Consider to actually correct and remedy the root causes, not only the symptoms.&lt;br /&gt;
*While performing the root cause analysis, also remember to treat symptoms for short term fixing.&lt;br /&gt;
*Avoid focus on who was responsible of the failure or problem, instead focus on how and why.&lt;br /&gt;
*Find and document ways to prevent similar root causes in the future.&lt;br /&gt;
*When finding root causes, provide cause-effect evidence to back it up.&lt;br /&gt;
*Often there are multiple root causes, therefore search for several.&lt;br /&gt;
&lt;br /&gt;
As it can be understood from the principles above, it is important to take a comprehensive and holistic approach in this type of analysis. As the root causes have no importance if no action is taken afterwards, it should be strived to provide information and context that can solve the failure or problem.&lt;br /&gt;
&lt;br /&gt;
==Conducting an effective root cause analysis==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Performing Root Cause Analyses for Successes&#039;&#039;&#039;&lt;br /&gt;
==Challenges==&lt;br /&gt;
&lt;br /&gt;
==Annotated Bibliography==&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=110848</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=110848"/>
		<updated>2022-02-25T10:32:50Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: /* General Principles */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Root Cause Analysis (RCA) is a method of problem solving that can be used in a project, program or portfolio (PPP) to identify root causes of faults and problems in order to identify appropriate solutions. It is broadly used in several industries, among the health care, infrastructure and information technology industry. A Root Cause Analysis supposes that it is more effective to go in-depth of occurring problems, so that the underlaying issue can be treated, instead of only treating ad hoc symptoms. Root Cause Analyses can be performed with several different methodologies, principles and techniques together to identify the root causes of a fault or problem. The goal is to find out where processes or systems failed or caused an issue in the first place.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A Root Cause Analysis can be divided into four steps:&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; – What went wrong? Do not look at symptoms of the fault or problem, but discover what specifically went wrong and caused the fault or problem.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Establish a timeline&#039;&#039;&#039; – Establish a timeline that specifies how the situation went from normal to problematical.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Distinguish root causes from other casual factors&#039;&#039;&#039; – Sort out factors that actually made the failure or problem occur. This can e.g. be done using event correlation.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Establish an overview between the root cause and the problem&#039;&#039;&#039; – Document how the root cause caused the fault or problem, this can be done e.g. with a casual graph.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
To be able to fully understand what a root cause analysis is and what it is used for, it is easier to relate it to something we are entirely acknowledged with. If your arm hurts considerably after an accident, you will go to the doctor to find the root cause of your pain. Also, if your computer stops working, you will try to find the root cause of its malfunction, either by yourself or by a professional technician. For these examples, a simple remedy could be found for the symptoms. To stop your arm from hurting, you could put ice on it to relive pain. To get work done with a broken computer, you could use your phone or tablet instead. Unfortunately, this would only consider the symptoms and not the underlaying issue that caused the problem. The injured arm may need surgery to entirely recover from the sustained injury, and the broken computer may need to have a new battery to function again. The best way to solve a fault or problem would therefore be to perform a Root Cause Analysis. By doing this, the exact root cause can be found so that the correct management of the fault or problem will be accomplished.&lt;br /&gt;
&lt;br /&gt;
In this article, the Root Cause Analysis will be defined (**********************)&lt;br /&gt;
&lt;br /&gt;
==== Goals and Benefits of using a Root Cause Analysis ====&lt;br /&gt;
&lt;br /&gt;
Related to the root cause analysis, there are &#039;&#039;&#039;three goals&#039;&#039;&#039; that should be realised. &#039;&#039;&#039;The first&#039;&#039;&#039; one being to discover the root cause of a failure or problem. &#039;&#039;&#039;The second&#039;&#039;&#039; one is to develop an understanding on how to fix and learn from the underlaying issues relating the root cause. &#039;&#039;&#039;The third&#039;&#039;&#039; and final one is to apply the findings from the root cause analysis, to systematically prevent future issues or problems. Root cause analysis can be used for increasing the productiveness in several core processes as well, with the goal to prevent problems in the future. Instead of replacing punctured bike tires on rental bikes, puncture proof tires could be installed instead if the problem persists.&lt;br /&gt;
&lt;br /&gt;
==== General Principles ====&lt;br /&gt;
&lt;br /&gt;
To achieve an effective root cause analysis process, there are some general principles that should be taken into consideration. These principles will increase the quality of the analysis and will help the analysis get trust from clients and stakeholders.&lt;br /&gt;
&lt;br /&gt;
*Consider to actually correct and remedy the root causes, not only the symptoms.&lt;br /&gt;
*While performing the root cause analysis, also treat symptoms for short term fixing.&lt;br /&gt;
*Avoid focus on who was responsible of the failure or problem, instead focus on how and why.&lt;br /&gt;
*Find and document ways to prevent similar root causes in the future.&lt;br /&gt;
*When finding root causes, provide cause-effect evidence to back it up.&lt;br /&gt;
*Often there are multiple root causes, therefore search for several.&lt;br /&gt;
&lt;br /&gt;
As it can be understood from the principles above, it is important to take a comprehensive and holistic approach in this type of analysis. As the root causes have no importance if no action is taken afterwards, it should be strived to provide information and context that can solve the failure or problem.&lt;br /&gt;
&lt;br /&gt;
==Conducting an effective root cause analysis==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Performing Root Cause Analyses for Successes&#039;&#039;&#039;&lt;br /&gt;
==Challenges==&lt;br /&gt;
&lt;br /&gt;
==Annotated Bibliography==&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=110847</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=110847"/>
		<updated>2022-02-25T10:31:48Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Root Cause Analysis (RCA) is a method of problem solving that can be used in a project, program or portfolio (PPP) to identify root causes of faults and problems in order to identify appropriate solutions. It is broadly used in several industries, among the health care, infrastructure and information technology industry. A Root Cause Analysis supposes that it is more effective to go in-depth of occurring problems, so that the underlaying issue can be treated, instead of only treating ad hoc symptoms. Root Cause Analyses can be performed with several different methodologies, principles and techniques together to identify the root causes of a fault or problem. The goal is to find out where processes or systems failed or caused an issue in the first place.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A Root Cause Analysis can be divided into four steps:&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; – What went wrong? Do not look at symptoms of the fault or problem, but discover what specifically went wrong and caused the fault or problem.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Establish a timeline&#039;&#039;&#039; – Establish a timeline that specifies how the situation went from normal to problematical.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Distinguish root causes from other casual factors&#039;&#039;&#039; – Sort out factors that actually made the failure or problem occur. This can e.g. be done using event correlation.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Establish an overview between the root cause and the problem&#039;&#039;&#039; – Document how the root cause caused the fault or problem, this can be done e.g. with a casual graph.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
To be able to fully understand what a root cause analysis is and what it is used for, it is easier to relate it to something we are entirely acknowledged with. If your arm hurts considerably after an accident, you will go to the doctor to find the root cause of your pain. Also, if your computer stops working, you will try to find the root cause of its malfunction, either by yourself or by a professional technician. For these examples, a simple remedy could be found for the symptoms. To stop your arm from hurting, you could put ice on it to relive pain. To get work done with a broken computer, you could use your phone or tablet instead. Unfortunately, this would only consider the symptoms and not the underlaying issue that caused the problem. The injured arm may need surgery to entirely recover from the sustained injury, and the broken computer may need to have a new battery to function again. The best way to solve a fault or problem would therefore be to perform a Root Cause Analysis. By doing this, the exact root cause can be found so that the correct management of the fault or problem will be accomplished.&lt;br /&gt;
&lt;br /&gt;
In this article, the Root Cause Analysis will be defined (**********************)&lt;br /&gt;
&lt;br /&gt;
==== Goals and Benefits of using a Root Cause Analysis ====&lt;br /&gt;
&lt;br /&gt;
Related to the root cause analysis, there are &#039;&#039;&#039;three goals&#039;&#039;&#039; that should be realised. &#039;&#039;&#039;The first&#039;&#039;&#039; one being to discover the root cause of a failure or problem. &#039;&#039;&#039;The second&#039;&#039;&#039; one is to develop an understanding on how to fix and learn from the underlaying issues relating the root cause. &#039;&#039;&#039;The third&#039;&#039;&#039; and final one is to apply the findings from the root cause analysis, to systematically prevent future issues or problems. Root cause analysis can be used for increasing the productiveness in several core processes as well, with the goal to prevent problems in the future. Instead of replacing punctured bike tires on rental bikes, puncture proof tires could be installed instead if the problem persists.&lt;br /&gt;
&lt;br /&gt;
==== General Principles ====&lt;br /&gt;
&lt;br /&gt;
To achieve an effective root cause analysis process, there are some general principles that should be taken into consideration. These principles will increase the quality of the analysis and will help the analysis get trust from clients and stakeholders.&lt;br /&gt;
&lt;br /&gt;
*Consider to actually correct and remedy the root causes, not only the symptoms.&lt;br /&gt;
*While performing the root cause analysis, also treat symptoms for short term fixing.&lt;br /&gt;
*Avoid focus on who was responsible of the failure or problem, instead focus on how and who.&lt;br /&gt;
*Find and document ways to prevent similar root causes in the future.&lt;br /&gt;
*When finding root causes, provide cause-effect evidence to back it up.&lt;br /&gt;
*Often there are multiple root causes, therefore search for several.&lt;br /&gt;
&lt;br /&gt;
As it can be understood from the principles above, it is important to take a comprehensive and holistic approach in this type of analysis. As the root causes have no importance if no action is taken afterwards, it should be strived to provide information and context that can solve the failure or problem.&lt;br /&gt;
&lt;br /&gt;
==Conducting an effective root cause analysis==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Performing Root Cause Analyses for Successes&#039;&#039;&#039;&lt;br /&gt;
==Challenges==&lt;br /&gt;
&lt;br /&gt;
==Annotated Bibliography==&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=110830</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=110830"/>
		<updated>2022-02-24T16:59:12Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Root Cause Analysis (RCA) is a method of problem solving that can be used in a project, program or portfolio (PPP) to identify root causes of faults and problems in order to identify appropriate solutions. It is broadly used in several industries, among the health care, infrastructure and information technology industry. A Root Cause Analysis supposes that it is more effective to go in-depth of occurring problems, so that the underlaying issue can be treated, instead of only treating ad hoc symptoms. Root Cause Analyses can be performed with several different methodologies, principles and techniques together to identify the root causes of a fault or problem. The goal is to find out where processes or systems failed or caused an issue in the first place.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A Root Cause Analysis can be divided into four steps:&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; – What went wrong? Do not look at symptoms of the fault or problem, but discover what specifically went wrong and caused the fault or problem.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Establish a timeline&#039;&#039;&#039; – Establish a timeline that specifies how the situation went from normal to problematical.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Distinguish root causes from other casual factors&#039;&#039;&#039; – Sort out factors that actually made the failure or problem occur. This can e.g. be done using event correlation.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Establish an overview between the root cause and the problem&#039;&#039;&#039; – Document how the root cause caused the fault or problem, this can be done e.g. with a casual graph.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
To fully understand what a root cause analysis is and what it is used for, it is easier to relate it to something we are entirely acknowledged with. If your arm hurts considerably after an accident, you will go to the doctor to find the root cause of your pain. Also, if your computer stops working, you will try to find the root cause of its malfunction, either by yourself or by a professional technician. For these examples, a simple remedy could be found for the symptoms. To stop your arm from hurting, you could put ice on it to relive pain. To get work done with a broken computer, you could use your phone or tablet instead. Unfortunately, this would only consider the symptoms and not the underlaying issue that caused the problem. The injured arm may need surgery to entirely recover from the sustained injury, and the broken computer may need to have a new battery to function again. The best way to solve a fault or problem would therefore be to perform a Root Cause Analysis. By doing this, the exact root cause can be found so that the correct management of the fault or problem will be accomplished.&lt;br /&gt;
&lt;br /&gt;
In this article, the Root Cause Analysis will be defined (**********************)&lt;br /&gt;
&lt;br /&gt;
==== Goals and Benefits of using a Root Cause Analysis ====&lt;br /&gt;
&lt;br /&gt;
Related to the root cause analysis, there are &#039;&#039;&#039;three goals&#039;&#039;&#039; that should be realised. &#039;&#039;&#039;The first&#039;&#039;&#039; one being to discover the root cause of a failure or problem. &#039;&#039;&#039;The second&#039;&#039;&#039; one is to develop an understanding on how to fix and learn from the underlaying issues relating the root cause. &#039;&#039;&#039;The third&#039;&#039;&#039; and final one is to apply the findings from the root cause analysis, to systematically prevent future issues or problems. Root cause analysis can be used for increasing the productiveness in several core processes as well, with the goal to prevent problems in the future. Instead of replacing punctured bike tires on rental bikes, puncture proof tires could be installed instead if the problem persists.&lt;br /&gt;
&lt;br /&gt;
==== General Principles ====&lt;br /&gt;
&lt;br /&gt;
To achieve an effective root cause analysis process, there are some general principles that should be taken into consideration. These principles will increase the quality of the analysis and will help the analysis get trust from clients and stakeholders.&lt;br /&gt;
&lt;br /&gt;
*Consider to actually correct and remedy the root causes, not only the symptoms.&lt;br /&gt;
*While performing the root cause analysis, also treat symptoms for short term fixing.&lt;br /&gt;
*Avoid focus on who was responsible of the failure or problem, instead focus on how and who.&lt;br /&gt;
*Find and document ways to prevent similar root causes in the future.&lt;br /&gt;
*When finding root causes, provide cause-effect evidence to back it up.&lt;br /&gt;
*Often there are multiple root causes, therefore search for several.&lt;br /&gt;
&lt;br /&gt;
As it can be understood from the principles above, it is important to take a comprehensive and holistic approach in this type of analysis. As the root causes have no importance if no action is taken afterwards, it should be strived to provide information and context that can solve the failure or problem.&lt;br /&gt;
&lt;br /&gt;
==Conducting an effective root cause analysis==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Performing Root Cause Analyses for Successes&#039;&#039;&#039;&lt;br /&gt;
==Challenges==&lt;br /&gt;
&lt;br /&gt;
==Annotated Bibliography==&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=110829</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=110829"/>
		<updated>2022-02-24T14:18:46Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Root Cause Analysis (RCA) is a method of problem solving that can be used in a project, program or portfolio (PPP) to identify root causes of faults and problems in order to identify appropriate solutions. It is broadly used in several industries, among the health care, infrastructure and information technology industry. A Root Cause Analysis supposes that it is more effective to go in-depth of occurring problems, so that the underlaying issue can be treated, instead of only treating ad hoc symptoms. Root Cause Analyses can be performed with several different methodologies, principles and techniques together to identify the root causes of a fault or problem. The goal is to find out where processes or systems failed or caused an issue in the first place.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A Root Cause Analysis can be divided into three steps:&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; – What went wrong? Do not look at symptoms of the fault or problem, but discover what specifically went wrong and caused the fault or problem.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Establish a timeline&#039;&#039;&#039; – Establish a timeline that specifies how the situation went from normal to problematical.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Distinguish root causes from other casual factors&#039;&#039;&#039; – Sort out factors that actually made the failure or problem occur. This can e.g. be done using event correlation.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Establish an overview between the root cause and the problem&#039;&#039;&#039; – Document how the root cause caused the fault or problem, this can be done e.g. with a casual graph.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
To fully understand what a root cause analysis is and what it is used for, it is easier to relate it to something we are entirely acknowledged with. If your arm hurts considerably after an accident, you will go to the doctor to find the root cause of your pain. Also, if your computer stops working, you will try to find the root cause of its malfunction, either by yourself or by a professional technician. For these examples, a simple remedy could be found for the symptoms. To stop your arm from hurting, you could put ice on it to relive pain. To get work done with a broken computer, you could use your phone or tablet instead. Unfortunately, this would only consider the symptoms and not the underlaying issue that caused the problem. The injured arm may need surgery to entirely recover from the sustained injury, and the broken computer may need to have a new battery to function again. The best way to solve a fault or problem would therefore be to perform a Root Cause Analysis. By doing this, the exact root cause can be found so that the correct management of the fault or problem will be accomplished.&lt;br /&gt;
&lt;br /&gt;
In this article, the Root Cause Analysis will be defined (**********************)&lt;br /&gt;
&lt;br /&gt;
==== Goals and benefits of using RCA ====&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==General Principles==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Conducting an effective root cause analysis==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Challenges==&lt;br /&gt;
&lt;br /&gt;
==Annotated Bibliography==&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=110823</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=110823"/>
		<updated>2022-02-24T12:48:34Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Root Cause Analysis (RCA) is a method of problem solving that can be used in a project, program or portfolio (PPP) to identify root causes of faults and problems in order to identify appropriate solutions. It is broadly used in several industries, among the health care, infrastructure and information technology industry. A Root Cause Analysis supposes that it is more effective to go in-depth of occurring problems, so that the underlaying issue can be treated, instead of only treating ad hoc symptoms. Root Cause Analyses can be performed with several different methodologies, principles and techniques together to identify the root causes of a fault or problem. The goal is to find out where processes or systems failed or caused an issue in the first place.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A Root Cause Analysis can be divided into three steps:&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; – What went wrong? Do not look at symptoms of the fault or problem, but discover what specifically went wrong and caused the fault or problem.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Establish a timeline&#039;&#039;&#039; – Establish a timeline that specifies how the situation went from normal to problematical.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Distinguish root causes from other casual factors&#039;&#039;&#039; – Sort out factors that actually made the failure or problem occur. This can e.g. be done using event correlation.&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Establish an overview between the root cause and the problem&#039;&#039;&#039; – Document how the root cause caused the fault or problem, this can be done e.g. with a casual graph.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
==General principles==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Challenges==&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=110820</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=110820"/>
		<updated>2022-02-24T12:41:42Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Root Cause Analysis (RCA) is a method of problem solving that can be used in a project, program or portfolio (PPP) to identify root causes of faults and problems in order to identify appropriate solutions. It is broadly used in several industries, among the health care, infrastructure and information technology industry. A Root Cause Analysis supposes that it is more effective to go in-depth of occurring problems, so that the underlaying issue can be treated, instead of only treating ad hoc symptoms. Root Cause Analyses can be performed with several different methodologies, principles and techniques together to identify the root causes of a fault or problem. The goal is to find out where processes or systems failed or caused an issue in the first place.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A Root Cause Analysis can be divided into three steps:&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; – What went wrong? Do not look at symptoms of the fault or problem, but discover what specifically went wrong and caused the fault or problem&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Establish a timeline&#039;&#039;&#039; – Establish a timeline that specifies how the situation went from normal to problematical&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Distinguish root causes from other casual factors&#039;&#039;&#039; – Sort out factors that actually made the failure or problem occur. This can e.g. be done using event correlation&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Establish an overview between the root cause and the problem&#039;&#039;&#039; – Document how the root cause caused the fault or problem, this can be done e.g. with a casual graph&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
==General principles==&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=110818</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=110818"/>
		<updated>2022-02-24T12:36:36Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Root Cause Analysis (RCA) is a method of problem solving that can be used in a project, program or portfolio (PPP) to identify root causes of faults and problems in order to identify appropriate solutions. It is broadly used in several industries, among the health care, infrastructure and information technology industry. A Root Cause Analysis supposes that it is more effective to go in-depth of occurring problems, so that the underlaying issue can be treated, instead of only treating ad hoc symptoms. Root Cause Analyses can be performed with several different methodologies, principles and techniques together to identify the root causes of a fault or problem. The goal is to find out where processes or systems failed or caused an issue in the first place.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A Root Cause Analysis can be divided into three steps:&lt;br /&gt;
&lt;br /&gt;
*Identify – What went wrong? Do not look at symptoms of the fault or problem, but discover what specifically went wrong and caused the fault or problem&lt;br /&gt;
&lt;br /&gt;
*Establish a timeline – Establish a timeline that specifies how the situation went from normal to problematical&lt;br /&gt;
&lt;br /&gt;
*Distinguish root causes from other casual factors – Sort out factors that actually made the failure or problem occur. This can e.g. be done using event correlation&lt;br /&gt;
&lt;br /&gt;
*Establish an overview between the root cause and the problem – Document how the root cause caused the fault or problem, this can be done e.g. with a casual graph&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=110817</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=110817"/>
		<updated>2022-02-24T12:35:44Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Root Cause Analysis (RCA) is a method of problem solving that can be used in a project, program or portfolio (PPP) to identify root causes of faults and problems in order to identify appropriate solutions. It is broadly used in several industries, among the health care, infrastructure and information technology industry. A Root Cause Analysis supposes that it is more effective to go in-depth of occurring problems, so that the underlaying issue can be treated, instead of only treating ad hoc symptoms. Root Cause Analyses can be performed with several different methodologies, principles and techniques together to identify the root causes of a fault or problem. The goal is to find out where processes or systems failed or caused an issue in the first place.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A Root Cause Analysis can be divided into three steps:&lt;br /&gt;
&lt;br /&gt;
•	Identify – What went wrong? Do not look at symptoms of the fault or problem, but discover what specifically went wrong and caused the fault or problem&lt;br /&gt;
•	Establish a timeline – Establish a timeline that specifies how the situation went from normal to problematical&lt;br /&gt;
•	Distinguish root causes from other casual factors – Sort out factors that actually made the failure or problem occur. This can e.g. be done using event correlation&lt;br /&gt;
•	Establish an overview between the root cause and the problem – Document how the root cause caused the fault or problem, this can be done e.g. with a casual graph&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=110815</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=110815"/>
		<updated>2022-02-24T12:33:22Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Root Cause Analysis (RCA) is a method of problem solving that can be used in a project, program or portfolio (PPP) to identify root causes of faults and problems in order to identify appropriate solutions. It is broadly used in several industries, among the health care, infrastructure and information technology industry. A Root Cause Analysis supposes that it is more effective to go in-depth of occurring problems, so that the underlaying issue can be treated, instead of only treating ad hoc symptoms. Root Cause Analyses can be performed with several different methodologies, principles and techniques together to identify the root causes of a fault or problem. The goal is to find out where processes or systems failed or caused an issue in the first place.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=110814</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=110814"/>
		<updated>2022-02-24T12:29:38Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Root Cause Analysis (RCA) is a method of problem solving that can be used in a project, program or portfolio (PPP) to identify root causes of faults and problems in order to identify appropriate solutions. It is broadly used in several industries, among the health care, infrastructure and information technology industry. A Root Cause Analysis supposes that it is more effective to go in-depth of occurring problems, so that the underlaying issue can be treated, instead of only treating ad hoc symptoms. Root Cause Analyses can be performed with several different methodologies, principles and techniques together to identify the root causes of a fault or problem. The goal is to find out where processes or systems failed or caused an issue in the first place.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable sortable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!Team Roles&lt;br /&gt;
!Personal traits&amp;lt;ref name=&amp;quot;Mind_Tools&amp;quot;&amp;gt; 2016 Belbin&#039;s team roles by Mind tools content team. https://www.mindtools.com/pages/article/newLDR_83.htm&amp;lt;/ref&amp;gt;&lt;br /&gt;
!Strengths&amp;lt;ref name=&amp;quot;Belbin team roles&amp;quot;&amp;gt; 2021 Belbin Associates. https://www.belbin.com/about/belbin-team-roles/&amp;lt;/ref&amp;gt;&lt;br /&gt;
!Allowable weaknesses&amp;lt;ref name=&amp;quot;Belbin team roles&amp;quot; /&amp;gt;&lt;br /&gt;
|-&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=110806</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=110806"/>
		<updated>2022-02-24T11:34:51Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable sortable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!Team Roles&lt;br /&gt;
!Personal traits&amp;lt;ref name=&amp;quot;Mind_Tools&amp;quot;&amp;gt; 2016 Belbin&#039;s team roles by Mind tools content team. https://www.mindtools.com/pages/article/newLDR_83.htm&amp;lt;/ref&amp;gt;&lt;br /&gt;
!Strengths&amp;lt;ref name=&amp;quot;Belbin team roles&amp;quot;&amp;gt; 2021 Belbin Associates. https://www.belbin.com/about/belbin-team-roles/&amp;lt;/ref&amp;gt;&lt;br /&gt;
!Allowable weaknesses&amp;lt;ref name=&amp;quot;Belbin team roles&amp;quot; /&amp;gt;&lt;br /&gt;
|-&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=110805</id>
		<title>Root Cause Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Root_Cause_Analysis&amp;diff=110805"/>
		<updated>2022-02-24T11:33:01Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: Created page with &amp;quot;{| class=&amp;quot;wikitable sortable&amp;quot; |- !Team Roles !Personal traits&amp;lt;ref name=&amp;quot;Mind_Tools&amp;quot;&amp;gt; 2016 Belbin&amp;#039;s team roles by Mind tools content team. https://www.mindtools.com/pages/artic...&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{| class=&amp;quot;wikitable sortable&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!Team Roles&lt;br /&gt;
!Personal traits&amp;lt;ref name=&amp;quot;Mind_Tools&amp;quot;&amp;gt; 2016 Belbin&#039;s team roles by Mind tools content team. https://www.mindtools.com/pages/article/newLDR_83.htm&amp;lt;/ref&amp;gt;&lt;br /&gt;
!Strengths&amp;lt;ref name=&amp;quot;Belbin team roles&amp;quot;&amp;gt; 2021 Belbin Associates. https://www.belbin.com/about/belbin-team-roles/&amp;lt;/ref&amp;gt;&lt;br /&gt;
!Allowable weaknesses&amp;lt;ref name=&amp;quot;Belbin team roles&amp;quot; /&amp;gt;&lt;br /&gt;
|-&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=RCA_Analysis&amp;diff=110804</id>
		<title>RCA Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=RCA_Analysis&amp;diff=110804"/>
		<updated>2022-02-24T11:20:59Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: Blanked the page&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=RCA_Analysis&amp;diff=110803</id>
		<title>RCA Analysis</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=RCA_Analysis&amp;diff=110803"/>
		<updated>2022-02-24T11:18:56Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: Created page with &amp;quot;Created by William Vossgård&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Created by William Vossgård&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Articles_Spring_Term_2021&amp;diff=110732</id>
		<title>Articles Spring Term 2021</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Articles_Spring_Term_2021&amp;diff=110732"/>
		<updated>2022-02-21T14:58:22Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: /* Overview of 2021 Wiki Collections */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Overview of 2021 Wiki Collections=&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable sortable&amp;quot;&lt;br /&gt;
|+Spring Term 2021 Wiki Collections&lt;br /&gt;
|Group name&lt;br /&gt;
|First name&lt;br /&gt;
|Surname&lt;br /&gt;
|Student number&lt;br /&gt;
|[[Article name]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|TAs Example&lt;br /&gt;
|Thomas&lt;br /&gt;
|Giannoulopoulos&lt;br /&gt;
|s192419&lt;br /&gt;
|[[APPM Example 2021]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 12&lt;br /&gt;
|Christian&lt;br /&gt;
|Frøsig&lt;br /&gt;
|s175044&lt;br /&gt;
|[[Belbin&#039;s 9 team roles]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 1&lt;br /&gt;
|Oliver&lt;br /&gt;
|K. Vittrup&lt;br /&gt;
|s163754&lt;br /&gt;
|[[Top-down vs bottom-up estimations]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|44&lt;br /&gt;
|Jeyad&lt;br /&gt;
|M. Baig&lt;br /&gt;
|s153585&lt;br /&gt;
|[[Planning Methods - 3 Levels of Project Planning]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 17&lt;br /&gt;
|Quoc-Khanh Rose-Marie Therese&lt;br /&gt;
|Madsen&lt;br /&gt;
|s123462&lt;br /&gt;
|[[Applying Tuckman’s model for team development]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|31&lt;br /&gt;
|Haoxiang&lt;br /&gt;
|Sang&lt;br /&gt;
|s192258&lt;br /&gt;
|[[Cost control with statistic tools]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 31&lt;br /&gt;
|He&lt;br /&gt;
|Fan&lt;br /&gt;
|s192195&lt;br /&gt;
|[[Work Break-down Structure]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 19&lt;br /&gt;
|Ángel&lt;br /&gt;
|Castro del Olmo&lt;br /&gt;
|s193246&lt;br /&gt;
|[[Stakeholder Engagement and Sustainability in Maritime Spatial Planning]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|44&lt;br /&gt;
|Abdullah Shams&lt;br /&gt;
|Turkmani&lt;br /&gt;
|s153337&lt;br /&gt;
|[[ICT Agreement]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 17&lt;br /&gt;
|Jacopo&lt;br /&gt;
|Renzi&lt;br /&gt;
|s210445&lt;br /&gt;
|[[Double Diamond in Project Management]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 35&lt;br /&gt;
|Helga Sigríður&lt;br /&gt;
|Magnúsdóttir&lt;br /&gt;
|s202027&lt;br /&gt;
|[[Network Planning]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|12&lt;br /&gt;
|Cæcilie&lt;br /&gt;
|Kortbæk&lt;br /&gt;
|163873&lt;br /&gt;
|[[Double diamond]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 18&lt;br /&gt;
|Frithjof Johannes&lt;br /&gt;
|Thiem&lt;br /&gt;
|s202972&lt;br /&gt;
|[[DevOps]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|12&lt;br /&gt;
|Emilie&lt;br /&gt;
|Winther Schmidt&lt;br /&gt;
|163884&lt;br /&gt;
|[[Iron Triangle]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|12&lt;br /&gt;
|Anna&lt;br /&gt;
|Fredgaard&lt;br /&gt;
|s163887&lt;br /&gt;
|[[Active Listening Technique]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|35&lt;br /&gt;
|Ruben&lt;br /&gt;
|Raes&lt;br /&gt;
|s202029&lt;br /&gt;
|[[Iron Triangle of Project Management]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|21&lt;br /&gt;
|Claudia&lt;br /&gt;
|Balcells&lt;br /&gt;
|s202939&lt;br /&gt;
|[[APPPM Issue Tree]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|35&lt;br /&gt;
|Brynja&lt;br /&gt;
|Gudmundsdottir&lt;br /&gt;
|s202030&lt;br /&gt;
|[[FAST goals]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|16&lt;br /&gt;
|Andrea&lt;br /&gt;
|Pin Morales&lt;br /&gt;
|s205567&lt;br /&gt;
|[[The Business Case]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|16&lt;br /&gt;
|Lena Maria&lt;br /&gt;
|Thyen&lt;br /&gt;
|s202969&lt;br /&gt;
|[[The 7 Habits of Highly Effective People for Successful Leadership]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|35&lt;br /&gt;
|Úlfar&lt;br /&gt;
|Viktorsson&lt;br /&gt;
|s202022&lt;br /&gt;
|[[The 4 Disciplines of Execution]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|16&lt;br /&gt;
|Moritz&lt;br /&gt;
|Rindermann&lt;br /&gt;
|s202976&lt;br /&gt;
|[[Tuckmans model for Team Development]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 29&lt;br /&gt;
|Heiðdís Ósk&lt;br /&gt;
|Pétursdóttir&lt;br /&gt;
|s202025&lt;br /&gt;
|[[Efficiency and Effectiveness]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|31&lt;br /&gt;
|Xabier&lt;br /&gt;
|Martínez de Zabarte&lt;br /&gt;
|s210323&lt;br /&gt;
|[[Scrumban]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|17&lt;br /&gt;
|Aldís Braga&lt;br /&gt;
|Eiríksdóttir&lt;br /&gt;
|s202045&lt;br /&gt;
|[[Blake-Mouton Managerial Grid]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|32&lt;br /&gt;
|Jan Otis&lt;br /&gt;
| Ernst&lt;br /&gt;
|s210433&lt;br /&gt;
|[[RACI Matrix]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|3&lt;br /&gt;
|Julie&lt;br /&gt;
| Finne-Ipsen&lt;br /&gt;
|s153987&lt;br /&gt;
|[[Kahneman - Two Thinking Systems]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|24&lt;br /&gt;
|Maria Eileen&lt;br /&gt;
| Hubbuck&lt;br /&gt;
|s210444&lt;br /&gt;
|[[Risk Management-Identification]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|11&lt;br /&gt;
|Alina&lt;br /&gt;
| Barun&lt;br /&gt;
|s202514&lt;br /&gt;
|[[Maslow&#039;s Hierarchy of Needs]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|24&lt;br /&gt;
|Felix Vinzenz&lt;br /&gt;
|Wütherich&lt;br /&gt;
|s202968&lt;br /&gt;
|[[Emotional Intelligence and Leadership]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|28&lt;br /&gt;
|Ariadna&lt;br /&gt;
|Ramos&lt;br /&gt;
|s191852&lt;br /&gt;
|[[The Work Breakdown Structure (WBS)]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 27&lt;br /&gt;
|Jakob&lt;br /&gt;
|Grønvald&lt;br /&gt;
|s164346&lt;br /&gt;
|[[Maslow‘s Hierarchy of Needs, Motivation in the workplace]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 16&lt;br /&gt;
|Martina&lt;br /&gt;
|Rampazzo&lt;br /&gt;
|s202895&lt;br /&gt;
|[[Earned value management (EVM)]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 2&lt;br /&gt;
|John&lt;br /&gt;
|Fritz&lt;br /&gt;
|s202967&lt;br /&gt;
|[[Learning plan]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 24&lt;br /&gt;
|Henning&lt;br /&gt;
|Duwe&lt;br /&gt;
|s210450&lt;br /&gt;
|[[SWOT Analysis]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 14&lt;br /&gt;
|Søren Emil&lt;br /&gt;
|Kjær&lt;br /&gt;
|s201528&lt;br /&gt;
|[[GANTT]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 23&lt;br /&gt;
|Mathilde Kremmer&lt;br /&gt;
|Broberg&lt;br /&gt;
|s175074&lt;br /&gt;
|[[Corrective and Preventive Actions (CAPA)]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 14&lt;br /&gt;
|Rune Lykke&lt;br /&gt;
|Høg&lt;br /&gt;
|s165012&lt;br /&gt;
|[[The use of the A3 management process]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 35&lt;br /&gt;
|Tinna Hrönn&lt;br /&gt;
|Unudóttir&lt;br /&gt;
|s202032&lt;br /&gt;
|[[Constructive communication]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 17&lt;br /&gt;
|Eva Rún&lt;br /&gt;
|Arnarsdóttir&lt;br /&gt;
|s203214&lt;br /&gt;
|[[Biases in Project Management]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 24&lt;br /&gt;
|Astrid&lt;br /&gt;
|Skovhus&lt;br /&gt;
|s164499&lt;br /&gt;
|[[Getting Things Done (GTD)]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 7&lt;br /&gt;
|Phillip&lt;br /&gt;
|Dyrberg&lt;br /&gt;
|s164503&lt;br /&gt;
|[[Double diamond: A design process model]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 14&lt;br /&gt;
|Amanda Emilie&lt;br /&gt;
|Søborg Berthelsen&lt;br /&gt;
|s154707&lt;br /&gt;
|[[The Johari Window]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 23&lt;br /&gt;
|Nicolai Mossing&lt;br /&gt;
|Madsen&lt;br /&gt;
|s164515&lt;br /&gt;
|[[SMART Goals (Specific, Measurable, Attainable, Relevant, Time-bound)]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 27&lt;br /&gt;
|Marie-Louise Wolfsberg&lt;br /&gt;
|Schmidt&lt;br /&gt;
|s164417&lt;br /&gt;
|[[The Affect Heuristic]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 4&lt;br /&gt;
|Erika Marie&lt;br /&gt;
|Strøm&lt;br /&gt;
|s203224&lt;br /&gt;
|[[Parkinson&#039;s Law in Project Schedule Management]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 16&lt;br /&gt;
|Beatrice&lt;br /&gt;
|Ranzato&lt;br /&gt;
|s202887&lt;br /&gt;
|[[X-Matrix Hoshin Kanri]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 9&lt;br /&gt;
|Helene Waldmann&lt;br /&gt;
|Jørgensen&lt;br /&gt;
|s173891&lt;br /&gt;
|[[Lag &amp;amp; Lead]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 4&lt;br /&gt;
|Zahra&lt;br /&gt;
|Al-Mosawi&lt;br /&gt;
|s193938&lt;br /&gt;
|[[Belbin Team Roles in Project Management]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 14&lt;br /&gt;
|William Axel Linderoth&lt;br /&gt;
|Michaelen&lt;br /&gt;
|s153275&lt;br /&gt;
|[[Design-Build]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 31&lt;br /&gt;
|Jesús &lt;br /&gt;
|Gracia Yoldi&lt;br /&gt;
|s210111&lt;br /&gt;
|[[Kanban in APPPM]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 35&lt;br /&gt;
|Katrín Erla &lt;br /&gt;
|Bergsveinsdóttir&lt;br /&gt;
|s202026&lt;br /&gt;
|[[Contingency plans]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 1&lt;br /&gt;
|Cecilie Marie Raagaard &lt;br /&gt;
|Christensen&lt;br /&gt;
|s160832&lt;br /&gt;
|[[Work breakdown structure (WBS)]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 19&lt;br /&gt;
|Ali Jamal&lt;br /&gt;
|Jomeh&lt;br /&gt;
|s173741&lt;br /&gt;
|[[SMART goals: A goal-setting technique]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 15&lt;br /&gt;
|Tobias &lt;br /&gt;
|Hyldmo&lt;br /&gt;
|s206658&lt;br /&gt;
|[[High performing teams]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 5&lt;br /&gt;
|Samah&lt;br /&gt;
|Said&lt;br /&gt;
|s203228&lt;br /&gt;
|[[Reference class forecasting]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 3&lt;br /&gt;
|Emilie&lt;br /&gt;
|Torp&lt;br /&gt;
|s153320&lt;br /&gt;
|[[Goal Hierarchy]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 3&lt;br /&gt;
|Victor Nørregaard&lt;br /&gt;
|Schwærter&lt;br /&gt;
|s164745&lt;br /&gt;
|[[Milestone Planning]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 9&lt;br /&gt;
|Jacob&lt;br /&gt;
|Ammitsøe&lt;br /&gt;
|s173849&lt;br /&gt;
|[[Authenticity]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 18&lt;br /&gt;
|Anna&lt;br /&gt;
|Bjørn Reland&lt;br /&gt;
|s154556&lt;br /&gt;
|[[Choosing the appropriate medium (oral – written – hybrids)]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 10&lt;br /&gt;
|Wail&lt;br /&gt;
|Atrari&lt;br /&gt;
|s170706&lt;br /&gt;
|[[The Double Diamond Tool: An efficient Project Management Tool]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 10&lt;br /&gt;
|Mohammad&lt;br /&gt;
|Abou Hassan&lt;br /&gt;
|s160101&lt;br /&gt;
|[[Implementing SWOT]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 10&lt;br /&gt;
|Ahmet&lt;br /&gt;
|Akgül&lt;br /&gt;
|s152597&lt;br /&gt;
|[[Smart goals (Specific, Measurable, Achievable, Realistic, and Timely)]]&lt;br /&gt;
|- &lt;br /&gt;
|- &lt;br /&gt;
|Group 2&lt;br /&gt;
|Amalie&lt;br /&gt;
|N. Müller&lt;br /&gt;
|s173675&lt;br /&gt;
|[[Big five personality traits (OCEAN model)]]&lt;br /&gt;
|- &lt;br /&gt;
|- &lt;br /&gt;
|Group 29&lt;br /&gt;
|Pétursdóttir&lt;br /&gt;
|Stefanía Ósk&lt;br /&gt;
|s202044&lt;br /&gt;
|[[Situational leadership - Hersey and Blanchard]]&lt;br /&gt;
|- &lt;br /&gt;
|- &lt;br /&gt;
|Group 10&lt;br /&gt;
|Abdulahi&lt;br /&gt;
|Hayle Hassan&lt;br /&gt;
|s164691&lt;br /&gt;
|[[Stakeholder management]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 27&lt;br /&gt;
|Louise&lt;br /&gt;
|Landschoff&lt;br /&gt;
|s165111&lt;br /&gt;
|[[SCRUM - A Project Management Framework]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 10&lt;br /&gt;
|Sara&lt;br /&gt;
|Alabiidi&lt;br /&gt;
|s164650&lt;br /&gt;
|[[The Blake-Mouton Managerial Grid]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 4&lt;br /&gt;
|Felix&lt;br /&gt;
|Dressel&lt;br /&gt;
|s202965&lt;br /&gt;
|[[The SPALTEN Problem-Solving Methodology as a Decision Making Tool in Project Management]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 11&lt;br /&gt;
|Sandra&lt;br /&gt;
|Nielsen&lt;br /&gt;
|s153370&lt;br /&gt;
|[[Conflict ladder]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 11&lt;br /&gt;
|Lise Munch&lt;br /&gt;
|Nordheim&lt;br /&gt;
|s200400&lt;br /&gt;
|[[McGregor&#039;s X &amp;amp; Y theory]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 2&lt;br /&gt;
|Simon&lt;br /&gt;
|Knutsson&lt;br /&gt;
|s202041&lt;br /&gt;
|[[Earned Value Management (EVM)]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 12&lt;br /&gt;
|Christoffer&lt;br /&gt;
|Askgaard&lt;br /&gt;
|s165098&lt;br /&gt;
|[[Design the team you need to succeed using Belbin&#039;s team roles]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 24&lt;br /&gt;
|Gaute Bø&lt;br /&gt;
|Aaløkken&lt;br /&gt;
|s202065&lt;br /&gt;
|[[Diversity in teams]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 2&lt;br /&gt;
|Lukas&lt;br /&gt;
|Tanzer&lt;br /&gt;
|s200120&lt;br /&gt;
|[[Kanban]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 7&lt;br /&gt;
|Sofie&lt;br /&gt;
|Lundsteen&lt;br /&gt;
|s170285&lt;br /&gt;
|[[Creating effective teams with the use of Belbin&#039;s Team Roles]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 14&lt;br /&gt;
|FIRST NAME&lt;br /&gt;
|LAST NAME&lt;br /&gt;
|STUDY ID&lt;br /&gt;
|[[Applying the Hawthorne studies to project management]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 3&lt;br /&gt;
|Amalie Nordstrøm&lt;br /&gt;
|Nielsen&lt;br /&gt;
|s153272&lt;br /&gt;
|[[The seven characteristic principles]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 14&lt;br /&gt;
|Louise Damborg&lt;br /&gt;
|Frederiksen&lt;br /&gt;
|s185238&lt;br /&gt;
|[[Using Facilitation to Mitigate Bias in a Team Setting]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 1&lt;br /&gt;
|Georg Holger&lt;br /&gt;
|Waage&lt;br /&gt;
|s163819&lt;br /&gt;
|[[Fishbone Diagram]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 28&lt;br /&gt;
|Özgenur&lt;br /&gt;
|Baştuğ&lt;br /&gt;
|s203033&lt;br /&gt;
|[[Change Orders in Construction Projects]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 9&lt;br /&gt;
|Mads&lt;br /&gt;
|Møhlenberg&lt;br /&gt;
|s173879&lt;br /&gt;
|[[A hybrid consisting of Agile and Stage Gate]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 29&lt;br /&gt;
|Svanhvít Birta&lt;br /&gt;
|Guðmundsdóttir&lt;br /&gt;
|s203174&lt;br /&gt;
|[[Project Milestones]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 23&lt;br /&gt;
|Bente&lt;br /&gt;
|Meidahl Münsberg&lt;br /&gt;
|s175068&lt;br /&gt;
|[[Gantt Charts]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 27&lt;br /&gt;
|Frederik&lt;br /&gt;
|Carlsson &lt;br /&gt;
|s164345&lt;br /&gt;
|[[FAST Goals]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 11&lt;br /&gt;
|Tobias&lt;br /&gt;
|Rydahl &lt;br /&gt;
|s200471&lt;br /&gt;
|[[Using DISC assessment for project team management]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 7&lt;br /&gt;
|Mads &lt;br /&gt;
|Støjfer-Hønberg&lt;br /&gt;
|s174303&lt;br /&gt;
|[[SCRUM - An Agile Project Management Framework]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 21&lt;br /&gt;
|Matthieu &lt;br /&gt;
|Buy&lt;br /&gt;
|s202925&lt;br /&gt;
|[[The Five-Factor Model (OCEAN)]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 18&lt;br /&gt;
|Astrid Helene&lt;br /&gt;
|Erecius&lt;br /&gt;
|s171013&lt;br /&gt;
|[[Choosing communication media for negotiation]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 44&lt;br /&gt;
|Zainab&lt;br /&gt;
|Jalal&lt;br /&gt;
|s165491&lt;br /&gt;
|[[Work Breakdown Structure in project management]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 2&lt;br /&gt;
|Anna Felicia Mai&lt;br /&gt;
|Lindström&lt;br /&gt;
|s202046&lt;br /&gt;
|[[Project Status Reporting]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 28&lt;br /&gt;
|Alberto&lt;br /&gt;
|Melloni&lt;br /&gt;
|s202894&lt;br /&gt;
|[[Pre-mortem analysis]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 29&lt;br /&gt;
|Thore Uwe&lt;br /&gt;
|Aye&lt;br /&gt;
|s202746&lt;br /&gt;
|[[Quality Gates in Project Management]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 9&lt;br /&gt;
|Lydia&lt;br /&gt;
|Tsintzou&lt;br /&gt;
|s193745&lt;br /&gt;
|[[SWOT Analysis Guide]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 28&lt;br /&gt;
|Kendra Ana&lt;br /&gt;
|Rodríguez López&lt;br /&gt;
|s200182&lt;br /&gt;
|[[Choosing by Advantages Decision-Making System]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 23&lt;br /&gt;
|Rasmus&lt;br /&gt;
|Engberg&lt;br /&gt;
|s164513&lt;br /&gt;
|[[RDM]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 4&lt;br /&gt;
|Christine&lt;br /&gt;
|Fryland&lt;br /&gt;
|s153875&lt;br /&gt;
|[[Theory X-Y in project management]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 28&lt;br /&gt;
|Manas P.&lt;br /&gt;
|Dalvi&lt;br /&gt;
|s210143&lt;br /&gt;
|[[Effective Tools for Multiple Project Management]]&lt;br /&gt;
-&lt;br /&gt;
|-&lt;br /&gt;
|Group 12&lt;br /&gt;
|Joakim&lt;br /&gt;
|Vollertzen&lt;br /&gt;
|s163947&lt;br /&gt;
|[[Extreme Project Management (XPM)]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 19&lt;br /&gt;
|Shubham&lt;br /&gt;
|Ingole&lt;br /&gt;
|s200092&lt;br /&gt;
|[[Stakeholder Management using Social Network Theory]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 31&lt;br /&gt;
|Alvaro&lt;br /&gt;
|Bello&lt;br /&gt;
|s210447&lt;br /&gt;
|[[Forecasting and estimation techniques]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 09&lt;br /&gt;
|Dorothea&lt;br /&gt;
|Georgiadou&lt;br /&gt;
|s200230&lt;br /&gt;
|[[Risk Register analysis]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 09&lt;br /&gt;
|Maria Konstantina&lt;br /&gt;
|Papaioannou&lt;br /&gt;
|s195550&lt;br /&gt;
|[[Fishbone diagram analysis]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 21&lt;br /&gt;
|Kelvin&lt;br /&gt;
|Scott-Fordsmand&lt;br /&gt;
|s174312&lt;br /&gt;
|[[RiskRegister]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 18&lt;br /&gt;
|Christoffer Friis&lt;br /&gt;
|Hansen&lt;br /&gt;
|s164569&lt;br /&gt;
|[[Identifying risk]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 1&lt;br /&gt;
|Giulia &lt;br /&gt;
|Zanelli&lt;br /&gt;
|s205701&lt;br /&gt;
|[[Earned Value Management - EVM]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 29&lt;br /&gt;
|Tinna &lt;br /&gt;
|Dofradottir&lt;br /&gt;
|s203177&lt;br /&gt;
|[[Adaptive Project Framework]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 23&lt;br /&gt;
|Jonatan Larsen&lt;br /&gt;
|Edry&lt;br /&gt;
|s165499&lt;br /&gt;
|[[The iron triangle as an analytical tool]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 4&lt;br /&gt;
|Mikkel Walther&lt;br /&gt;
|Hellesen&lt;br /&gt;
|s203227&lt;br /&gt;
|[[System Readiness Level Index]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 5&lt;br /&gt;
|Yamila Denise&lt;br /&gt;
|Aviles&lt;br /&gt;
|s203409&lt;br /&gt;
|[[Agile Release Train]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 5&lt;br /&gt;
|Kallina&lt;br /&gt;
|Karamitsiou&lt;br /&gt;
|s202249&lt;br /&gt;
|[[Kahneman&#039;s dual-system thinking]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 19&lt;br /&gt;
|Prasad&lt;br /&gt;
|Jagtap&lt;br /&gt;
|s200109&lt;br /&gt;
|[[Communication Management using Service Blueprint]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 3&lt;br /&gt;
|Johan Holger &lt;br /&gt;
|Rasmussen&lt;br /&gt;
|s210512&lt;br /&gt;
|[[Daniel Kahneman&#039;s two systems of thinking]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 18&lt;br /&gt;
|Sigrún Björk &lt;br /&gt;
|Sævarsdóttir&lt;br /&gt;
|s200165&lt;br /&gt;
|[[The Scrum framework]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 1&lt;br /&gt;
|Francesca&lt;br /&gt;
|Pieraccini&lt;br /&gt;
|s206673&lt;br /&gt;
|[[Double Diamond model]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 15&lt;br /&gt;
|Dionysios&lt;br /&gt;
|Dasopoulos&lt;br /&gt;
|s202916&lt;br /&gt;
|[[Tuckman&#039;s Model for Sustainable Team Development]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 15&lt;br /&gt;
|Joern&lt;br /&gt;
|Appelt&lt;br /&gt;
|s202854&lt;br /&gt;
|[[Intrinsic Motivation]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 23&lt;br /&gt;
|Oliver&lt;br /&gt;
|Karlsson&lt;br /&gt;
|s165080&lt;br /&gt;
|[[Double Diamond Model]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 5&lt;br /&gt;
|Victor&lt;br /&gt;
|Soler Fuertes&lt;br /&gt;
|s206040&lt;br /&gt;
|[[OKR - Objectives and Key Results]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 31&lt;br /&gt;
|João&lt;br /&gt;
|Ferreira&lt;br /&gt;
|s202867&lt;br /&gt;
|[[Psychological safety as a key factor to quality and productivity of Organizations]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 31&lt;br /&gt;
|Timo&lt;br /&gt;
|Scheitinger&lt;br /&gt;
|s202966&lt;br /&gt;
|[[The big five (OCEAN)]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 15&lt;br /&gt;
|Maria-Lito&lt;br /&gt;
|Glykioti&lt;br /&gt;
|s151256&lt;br /&gt;
|[[The role of Emotional Intelligence in Project Management]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 15&lt;br /&gt;
|Hafeez&lt;br /&gt;
|Ahmadi&lt;br /&gt;
|s164137&lt;br /&gt;
|[[ISM Principles of Change]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 18&lt;br /&gt;
|Marie Elly Ulricke&lt;br /&gt;
|Kristensen&lt;br /&gt;
|s144408&lt;br /&gt;
|[[Motivation through Theory X&amp;amp;Y from a Project Management perspective]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 18&lt;br /&gt;
|Christopher &lt;br /&gt;
|Burgdorf&lt;br /&gt;
|s154689&lt;br /&gt;
|[[Simple Multi-Attribute Rating Technique (SMART)]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 5&lt;br /&gt;
|Ishak&lt;br /&gt;
|Zaaimia&lt;br /&gt;
|s164631&lt;br /&gt;
|[[Parkinson&#039;s Law]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 11&lt;br /&gt;
|Sara Ballegaard&lt;br /&gt;
|Laursen&lt;br /&gt;
|s193723&lt;br /&gt;
|[[Organizational Socialization]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 19&lt;br /&gt;
|Ali Waleed&lt;br /&gt;
|Abbas&lt;br /&gt;
|s172841&lt;br /&gt;
|[[Fishbone diagram for root cause analysis]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 17&lt;br /&gt;
|Cecilia&lt;br /&gt;
|Thuy Duyen Nguyen-Cong&lt;br /&gt;
|s184300&lt;br /&gt;
|[[The 7 Habits of Highly Effective People by Stephen R. Covey]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 44&lt;br /&gt;
|Farah&lt;br /&gt;
|Sabri&lt;br /&gt;
|s164740&lt;br /&gt;
|[[Lack of communication in project management]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 1&lt;br /&gt;
|Shakila&lt;br /&gt;
|Khan Malik&lt;br /&gt;
|s173780&lt;br /&gt;
|[[Risk]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 27&lt;br /&gt;
|Asbjørn Martin&lt;br /&gt;
|Kruuse&lt;br /&gt;
|s153470&lt;br /&gt;
|[[Chairing a meeting]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 23&lt;br /&gt;
|Tummas Dímun&lt;br /&gt;
|Mohr&lt;br /&gt;
|s160129&lt;br /&gt;
|[[Project Dashboards]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 27&lt;br /&gt;
|Vanessa &lt;br /&gt;
|Clausen&lt;br /&gt;
|s183302&lt;br /&gt;
|[[Overcoming small-big projects (Gantt)]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 09&lt;br /&gt;
|Emil &lt;br /&gt;
|Ballermann&lt;br /&gt;
|s174393&lt;br /&gt;
|[[Parkinson&#039;s law and how to manage it]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 4&lt;br /&gt;
|Gian Marco&lt;br /&gt;
|Grieco&lt;br /&gt;
|s202893&lt;br /&gt;
|[[Parkinson&#039;s Law: achieving more in less time]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 44&lt;br /&gt;
|Shahad&lt;br /&gt;
|Abdelaziz&lt;br /&gt;
|s122945&lt;br /&gt;
|[[Outsourcing]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 3&lt;br /&gt;
|Tais&lt;br /&gt;
|Christiansen&lt;br /&gt;
|s165131&lt;br /&gt;
|[[Relationship of projects, programs and portfolios]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 4&lt;br /&gt;
|Sana&lt;br /&gt;
|Ilyas&lt;br /&gt;
|s192815&lt;br /&gt;
|[[SCRUM framework]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 5&lt;br /&gt;
|Mia Chrstine&lt;br /&gt;
|Wheitman&lt;br /&gt;
|s206053&lt;br /&gt;
|[[The use of Gantt Charts]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 35&lt;br /&gt;
|Sigurjón Bjarni&lt;br /&gt;
|Bjarnason&lt;br /&gt;
|s202049&lt;br /&gt;
|[[The Work breakdown structure(WBS)]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 19&lt;br /&gt;
|Morten Dam&lt;br /&gt;
|Laursen&lt;br /&gt;
|s200364&lt;br /&gt;
|[[Multiple Project Management: Summary, Theory and Improvement]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 29&lt;br /&gt;
|Céline Engelbrecht&lt;br /&gt;
|Galea-Larsen&lt;br /&gt;
|s147312&lt;br /&gt;
|[[Group Development - The Tuckman Model]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 28&lt;br /&gt;
|Hazal &lt;br /&gt;
|Alawi&lt;br /&gt;
|s180408&lt;br /&gt;
|[[The Double Diamond Framework]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 17&lt;br /&gt;
|Xenia&lt;br /&gt;
|Jørgensen&lt;br /&gt;
|s123633&lt;br /&gt;
|[[Teams - Creation and optimisation]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 11&lt;br /&gt;
|Jonas &lt;br /&gt;
|Bøje Simonsen&lt;br /&gt;
|s154089&lt;br /&gt;
|[[Logic tree and the Answer First Methodology]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 28&lt;br /&gt;
|Kavikrishnan&lt;br /&gt;
|Balakrishnan&lt;br /&gt;
|s164338&lt;br /&gt;
|[[Learning plans for high uncertainty projects]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 2&lt;br /&gt;
|Riccardo&lt;br /&gt;
|Pollacchini&lt;br /&gt;
|s192412&lt;br /&gt;
|[[Complex Project Management (CPM)]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 44&lt;br /&gt;
|Rokiya &lt;br /&gt;
|Ahmed Ramzy&lt;br /&gt;
|s170501&lt;br /&gt;
|[[Lean in construction industry]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 50&lt;br /&gt;
|Avishkar Anil &lt;br /&gt;
|Vadnere&lt;br /&gt;
|s206513&lt;br /&gt;
|[[Strategic Planning using SWOT analysis]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 5&lt;br /&gt;
|Niels  &lt;br /&gt;
|Tietgen&lt;br /&gt;
|s193191&lt;br /&gt;
|[[Microsoft Teams]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 29&lt;br /&gt;
|Bastien&lt;br /&gt;
|Haas&lt;br /&gt;
|s202932&lt;br /&gt;
|[[The 7 habits of highly effective people applied to Management]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 17&lt;br /&gt;
|Jacob&lt;br /&gt;
|Lützhøft Christensen&lt;br /&gt;
|s184113&lt;br /&gt;
|[[Lag and Lead]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Articles_Spring_Term_2021&amp;diff=110731</id>
		<title>Articles Spring Term 2021</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Articles_Spring_Term_2021&amp;diff=110731"/>
		<updated>2022-02-21T14:57:03Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: /* Overview of 2021 Wiki Collections */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Overview of 2021 Wiki Collections=&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable sortable&amp;quot;&lt;br /&gt;
|+Spring Term 2021 Wiki Collections&lt;br /&gt;
|Group name&lt;br /&gt;
|First name&lt;br /&gt;
|Surname&lt;br /&gt;
|Student number&lt;br /&gt;
|[[Article name]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|TAs Example&lt;br /&gt;
|Thomas&lt;br /&gt;
|Giannoulopoulos&lt;br /&gt;
|s192419&lt;br /&gt;
|[[APPM Example 2021]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 12&lt;br /&gt;
|Christian&lt;br /&gt;
|Frøsig&lt;br /&gt;
|s175044&lt;br /&gt;
|[[Belbin&#039;s 9 team roles]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 1&lt;br /&gt;
|Oliver&lt;br /&gt;
|K. Vittrup&lt;br /&gt;
|s163754&lt;br /&gt;
|[[Top-down vs bottom-up estimations]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|44&lt;br /&gt;
|Jeyad&lt;br /&gt;
|M. Baig&lt;br /&gt;
|s153585&lt;br /&gt;
|[[Planning Methods - 3 Levels of Project Planning]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 17&lt;br /&gt;
|Quoc-Khanh Rose-Marie Therese&lt;br /&gt;
|Madsen&lt;br /&gt;
|s123462&lt;br /&gt;
|[[Applying Tuckman’s model for team development]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|31&lt;br /&gt;
|Haoxiang&lt;br /&gt;
|Sang&lt;br /&gt;
|s192258&lt;br /&gt;
|[[Cost control with statistic tools]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 31&lt;br /&gt;
|He&lt;br /&gt;
|Fan&lt;br /&gt;
|s192195&lt;br /&gt;
|[[Work Break-down Structure]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 19&lt;br /&gt;
|Ángel&lt;br /&gt;
|Castro del Olmo&lt;br /&gt;
|s193246&lt;br /&gt;
|[[Stakeholder Engagement and Sustainability in Maritime Spatial Planning]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|44&lt;br /&gt;
|Abdullah Shams&lt;br /&gt;
|Turkmani&lt;br /&gt;
|s153337&lt;br /&gt;
|[[ICT Agreement]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 17&lt;br /&gt;
|Jacopo&lt;br /&gt;
|Renzi&lt;br /&gt;
|s210445&lt;br /&gt;
|[[Double Diamond in Project Management]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 35&lt;br /&gt;
|Helga Sigríður&lt;br /&gt;
|Magnúsdóttir&lt;br /&gt;
|s202027&lt;br /&gt;
|[[Network Planning]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|12&lt;br /&gt;
|Cæcilie&lt;br /&gt;
|Kortbæk&lt;br /&gt;
|163873&lt;br /&gt;
|[[Double diamond]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 18&lt;br /&gt;
|Frithjof Johannes&lt;br /&gt;
|Thiem&lt;br /&gt;
|s202972&lt;br /&gt;
|[[DevOps]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|12&lt;br /&gt;
|Emilie&lt;br /&gt;
|Winther Schmidt&lt;br /&gt;
|163884&lt;br /&gt;
|[[Iron Triangle]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|12&lt;br /&gt;
|Anna&lt;br /&gt;
|Fredgaard&lt;br /&gt;
|s163887&lt;br /&gt;
|[[Active Listening Technique]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|35&lt;br /&gt;
|Ruben&lt;br /&gt;
|Raes&lt;br /&gt;
|s202029&lt;br /&gt;
|[[Iron Triangle of Project Management]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|21&lt;br /&gt;
|Claudia&lt;br /&gt;
|Balcells&lt;br /&gt;
|s202939&lt;br /&gt;
|[[APPPM Issue Tree]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|35&lt;br /&gt;
|Brynja&lt;br /&gt;
|Gudmundsdottir&lt;br /&gt;
|s202030&lt;br /&gt;
|[[FAST goals]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|16&lt;br /&gt;
|Andrea&lt;br /&gt;
|Pin Morales&lt;br /&gt;
|s205567&lt;br /&gt;
|[[The Business Case]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|16&lt;br /&gt;
|Lena Maria&lt;br /&gt;
|Thyen&lt;br /&gt;
|s202969&lt;br /&gt;
|[[The 7 Habits of Highly Effective People for Successful Leadership]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|35&lt;br /&gt;
|Úlfar&lt;br /&gt;
|Viktorsson&lt;br /&gt;
|s202022&lt;br /&gt;
|[[The 4 Disciplines of Execution]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|16&lt;br /&gt;
|Moritz&lt;br /&gt;
|Rindermann&lt;br /&gt;
|s202976&lt;br /&gt;
|[[Tuckmans model for Team Development]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 29&lt;br /&gt;
|Heiðdís Ósk&lt;br /&gt;
|Pétursdóttir&lt;br /&gt;
|s202025&lt;br /&gt;
|[[Efficiency and Effectiveness]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|31&lt;br /&gt;
|Xabier&lt;br /&gt;
|Martínez de Zabarte&lt;br /&gt;
|s210323&lt;br /&gt;
|[[Scrumban]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|17&lt;br /&gt;
|Aldís Braga&lt;br /&gt;
|Eiríksdóttir&lt;br /&gt;
|s202045&lt;br /&gt;
|[[Blake-Mouton Managerial Grid]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|32&lt;br /&gt;
|Jan Otis&lt;br /&gt;
| Ernst&lt;br /&gt;
|s210433&lt;br /&gt;
|[[RACI Matrix]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|3&lt;br /&gt;
|Julie&lt;br /&gt;
| Finne-Ipsen&lt;br /&gt;
|s153987&lt;br /&gt;
|[[Kahneman - Two Thinking Systems]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|24&lt;br /&gt;
|Maria Eileen&lt;br /&gt;
| Hubbuck&lt;br /&gt;
|s210444&lt;br /&gt;
|[[Risk Management-Identification]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|11&lt;br /&gt;
|Alina&lt;br /&gt;
| Barun&lt;br /&gt;
|s202514&lt;br /&gt;
|[[Maslow&#039;s Hierarchy of Needs]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|24&lt;br /&gt;
|Felix Vinzenz&lt;br /&gt;
|Wütherich&lt;br /&gt;
|s202968&lt;br /&gt;
|[[Emotional Intelligence and Leadership]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|28&lt;br /&gt;
|Ariadna&lt;br /&gt;
|Ramos&lt;br /&gt;
|s191852&lt;br /&gt;
|[[The Work Breakdown Structure (WBS)]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 27&lt;br /&gt;
|Jakob&lt;br /&gt;
|Grønvald&lt;br /&gt;
|s164346&lt;br /&gt;
|[[Maslow‘s Hierarchy of Needs, Motivation in the workplace]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 16&lt;br /&gt;
|Martina&lt;br /&gt;
|Rampazzo&lt;br /&gt;
|s202895&lt;br /&gt;
|[[Earned value management (EVM)]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 2&lt;br /&gt;
|John&lt;br /&gt;
|Fritz&lt;br /&gt;
|s202967&lt;br /&gt;
|[[Learning plan]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 24&lt;br /&gt;
|Henning&lt;br /&gt;
|Duwe&lt;br /&gt;
|s210450&lt;br /&gt;
|[[SWOT Analysis]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 14&lt;br /&gt;
|Søren Emil&lt;br /&gt;
|Kjær&lt;br /&gt;
|s201528&lt;br /&gt;
|[[GANTT]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 23&lt;br /&gt;
|Mathilde Kremmer&lt;br /&gt;
|Broberg&lt;br /&gt;
|s175074&lt;br /&gt;
|[[Corrective and Preventive Actions (CAPA)]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 14&lt;br /&gt;
|Rune Lykke&lt;br /&gt;
|Høg&lt;br /&gt;
|s165012&lt;br /&gt;
|[[The use of the A3 management process]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 35&lt;br /&gt;
|Tinna Hrönn&lt;br /&gt;
|Unudóttir&lt;br /&gt;
|s202032&lt;br /&gt;
|[[Constructive communication]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 17&lt;br /&gt;
|Eva Rún&lt;br /&gt;
|Arnarsdóttir&lt;br /&gt;
|s203214&lt;br /&gt;
|[[Biases in Project Management]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 24&lt;br /&gt;
|Astrid&lt;br /&gt;
|Skovhus&lt;br /&gt;
|s164499&lt;br /&gt;
|[[Getting Things Done (GTD)]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 7&lt;br /&gt;
|Phillip&lt;br /&gt;
|Dyrberg&lt;br /&gt;
|s164503&lt;br /&gt;
|[[Double diamond: A design process model]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 14&lt;br /&gt;
|Amanda Emilie&lt;br /&gt;
|Søborg Berthelsen&lt;br /&gt;
|s154707&lt;br /&gt;
|[[The Johari Window]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 23&lt;br /&gt;
|Nicolai Mossing&lt;br /&gt;
|Madsen&lt;br /&gt;
|s164515&lt;br /&gt;
|[[SMART Goals (Specific, Measurable, Attainable, Relevant, Time-bound)]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 27&lt;br /&gt;
|Marie-Louise Wolfsberg&lt;br /&gt;
|Schmidt&lt;br /&gt;
|s164417&lt;br /&gt;
|[[The Affect Heuristic]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 4&lt;br /&gt;
|Erika Marie&lt;br /&gt;
|Strøm&lt;br /&gt;
|s203224&lt;br /&gt;
|[[Parkinson&#039;s Law in Project Schedule Management]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 16&lt;br /&gt;
|Beatrice&lt;br /&gt;
|Ranzato&lt;br /&gt;
|s202887&lt;br /&gt;
|[[X-Matrix Hoshin Kanri]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 9&lt;br /&gt;
|Helene Waldmann&lt;br /&gt;
|Jørgensen&lt;br /&gt;
|s173891&lt;br /&gt;
|[[Lag &amp;amp; Lead]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 4&lt;br /&gt;
|Zahra&lt;br /&gt;
|Al-Mosawi&lt;br /&gt;
|s193938&lt;br /&gt;
|[[Belbin Team Roles in Project Management]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 14&lt;br /&gt;
|William Axel Linderoth&lt;br /&gt;
|Michaelen&lt;br /&gt;
|s153275&lt;br /&gt;
|[[Design-Build]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 31&lt;br /&gt;
|Jesús &lt;br /&gt;
|Gracia Yoldi&lt;br /&gt;
|s210111&lt;br /&gt;
|[[Kanban in APPPM]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 35&lt;br /&gt;
|Katrín Erla &lt;br /&gt;
|Bergsveinsdóttir&lt;br /&gt;
|s202026&lt;br /&gt;
|[[Contingency plans]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 1&lt;br /&gt;
|Cecilie Marie Raagaard &lt;br /&gt;
|Christensen&lt;br /&gt;
|s160832&lt;br /&gt;
|[[Work breakdown structure (WBS)]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 19&lt;br /&gt;
|Ali Jamal&lt;br /&gt;
|Jomeh&lt;br /&gt;
|s173741&lt;br /&gt;
|[[SMART goals: A goal-setting technique]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 15&lt;br /&gt;
|Tobias &lt;br /&gt;
|Hyldmo&lt;br /&gt;
|s206658&lt;br /&gt;
|[[High performing teams]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 5&lt;br /&gt;
|Samah&lt;br /&gt;
|Said&lt;br /&gt;
|s203228&lt;br /&gt;
|[[Reference class forecasting]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 3&lt;br /&gt;
|Emilie&lt;br /&gt;
|Torp&lt;br /&gt;
|s153320&lt;br /&gt;
|[[Goal Hierarchy]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 3&lt;br /&gt;
|Victor Nørregaard&lt;br /&gt;
|Schwærter&lt;br /&gt;
|s164745&lt;br /&gt;
|[[Milestone Planning]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 9&lt;br /&gt;
|Jacob&lt;br /&gt;
|Ammitsøe&lt;br /&gt;
|s173849&lt;br /&gt;
|[[Authenticity]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 18&lt;br /&gt;
|Anna&lt;br /&gt;
|Bjørn Reland&lt;br /&gt;
|s154556&lt;br /&gt;
|[[Choosing the appropriate medium (oral – written – hybrids)]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 10&lt;br /&gt;
|Wail&lt;br /&gt;
|Atrari&lt;br /&gt;
|s170706&lt;br /&gt;
|[[The Double Diamond Tool: An efficient Project Management Tool]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 10&lt;br /&gt;
|Mohammad&lt;br /&gt;
|Abou Hassan&lt;br /&gt;
|s160101&lt;br /&gt;
|[[Implementing SWOT]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 10&lt;br /&gt;
|Ahmet&lt;br /&gt;
|Akgül&lt;br /&gt;
|s152597&lt;br /&gt;
|[[Smart goals (Specific, Measurable, Achievable, Realistic, and Timely)]]&lt;br /&gt;
|- &lt;br /&gt;
|- &lt;br /&gt;
|Group 2&lt;br /&gt;
|Amalie&lt;br /&gt;
|N. Müller&lt;br /&gt;
|s173675&lt;br /&gt;
|[[Big five personality traits (OCEAN model)]]&lt;br /&gt;
|- &lt;br /&gt;
|- &lt;br /&gt;
|Group 29&lt;br /&gt;
|Pétursdóttir&lt;br /&gt;
|Stefanía Ósk&lt;br /&gt;
|s202044&lt;br /&gt;
|[[Situational leadership - Hersey and Blanchard]]&lt;br /&gt;
|- &lt;br /&gt;
|- &lt;br /&gt;
|Group 10&lt;br /&gt;
|Abdulahi&lt;br /&gt;
|Hayle Hassan&lt;br /&gt;
|s164691&lt;br /&gt;
|[[Stakeholder management]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 27&lt;br /&gt;
|Louise&lt;br /&gt;
|Landschoff&lt;br /&gt;
|s165111&lt;br /&gt;
|[[SCRUM - A Project Management Framework]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 10&lt;br /&gt;
|Sara&lt;br /&gt;
|Alabiidi&lt;br /&gt;
|s164650&lt;br /&gt;
|[[The Blake-Mouton Managerial Grid]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 4&lt;br /&gt;
|Felix&lt;br /&gt;
|Dressel&lt;br /&gt;
|s202965&lt;br /&gt;
|[[The SPALTEN Problem-Solving Methodology as a Decision Making Tool in Project Management]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 11&lt;br /&gt;
|Sandra&lt;br /&gt;
|Nielsen&lt;br /&gt;
|s153370&lt;br /&gt;
|[[Conflict ladder]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 11&lt;br /&gt;
|Lise Munch&lt;br /&gt;
|Nordheim&lt;br /&gt;
|s200400&lt;br /&gt;
|[[McGregor&#039;s X &amp;amp; Y theory]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 2&lt;br /&gt;
|Simon&lt;br /&gt;
|Knutsson&lt;br /&gt;
|s202041&lt;br /&gt;
|[[Earned Value Management (EVM)]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 12&lt;br /&gt;
|Christoffer&lt;br /&gt;
|Askgaard&lt;br /&gt;
|s165098&lt;br /&gt;
|[[Design the team you need to succeed using Belbin&#039;s team roles]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 24&lt;br /&gt;
|Gaute Bø&lt;br /&gt;
|Aaløkken&lt;br /&gt;
|s202065&lt;br /&gt;
|[[Diversity in teams]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 2&lt;br /&gt;
|Lukas&lt;br /&gt;
|Tanzer&lt;br /&gt;
|s200120&lt;br /&gt;
|[[Kanban]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 7&lt;br /&gt;
|Sofie&lt;br /&gt;
|Lundsteen&lt;br /&gt;
|s170285&lt;br /&gt;
|[[Creating effective teams with the use of Belbin&#039;s Team Roles]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 14&lt;br /&gt;
|FIRST NAME&lt;br /&gt;
|LAST NAME&lt;br /&gt;
|STUDY ID&lt;br /&gt;
|[[Applying the Hawthorne studies to project management]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 3&lt;br /&gt;
|Amalie Nordstrøm&lt;br /&gt;
|Nielsen&lt;br /&gt;
|s153272&lt;br /&gt;
|[[The seven characteristic principles]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 14&lt;br /&gt;
|Louise Damborg&lt;br /&gt;
|Frederiksen&lt;br /&gt;
|s185238&lt;br /&gt;
|[[Using Facilitation to Mitigate Bias in a Team Setting]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 1&lt;br /&gt;
|Georg Holger&lt;br /&gt;
|Waage&lt;br /&gt;
|s163819&lt;br /&gt;
|[[Fishbone Diagram]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 28&lt;br /&gt;
|Özgenur&lt;br /&gt;
|Baştuğ&lt;br /&gt;
|s203033&lt;br /&gt;
|[[Change Orders in Construction Projects]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 9&lt;br /&gt;
|Mads&lt;br /&gt;
|Møhlenberg&lt;br /&gt;
|s173879&lt;br /&gt;
|[[A hybrid consisting of Agile and Stage Gate]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 29&lt;br /&gt;
|Svanhvít Birta&lt;br /&gt;
|Guðmundsdóttir&lt;br /&gt;
|s203174&lt;br /&gt;
|[[Project Milestones]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 23&lt;br /&gt;
|Bente&lt;br /&gt;
|Meidahl Münsberg&lt;br /&gt;
|s175068&lt;br /&gt;
|[[Gantt Charts]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 27&lt;br /&gt;
|Frederik&lt;br /&gt;
|Carlsson &lt;br /&gt;
|s164345&lt;br /&gt;
|[[FAST Goals]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 11&lt;br /&gt;
|Tobias&lt;br /&gt;
|Rydahl &lt;br /&gt;
|s200471&lt;br /&gt;
|[[Using DISC assessment for project team management]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 7&lt;br /&gt;
|Mads &lt;br /&gt;
|Støjfer-Hønberg&lt;br /&gt;
|s174303&lt;br /&gt;
|[[SCRUM - An Agile Project Management Framework]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 21&lt;br /&gt;
|Matthieu &lt;br /&gt;
|Buy&lt;br /&gt;
|s202925&lt;br /&gt;
|[[The Five-Factor Model (OCEAN)]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 18&lt;br /&gt;
|Astrid Helene&lt;br /&gt;
|Erecius&lt;br /&gt;
|s171013&lt;br /&gt;
|[[Choosing communication media for negotiation]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 44&lt;br /&gt;
|Zainab&lt;br /&gt;
|Jalal&lt;br /&gt;
|s165491&lt;br /&gt;
|[[Work Breakdown Structure in project management]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 2&lt;br /&gt;
|Anna Felicia Mai&lt;br /&gt;
|Lindström&lt;br /&gt;
|s202046&lt;br /&gt;
|[[Project Status Reporting]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 28&lt;br /&gt;
|Alberto&lt;br /&gt;
|Melloni&lt;br /&gt;
|s202894&lt;br /&gt;
|[[Pre-mortem analysis]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 29&lt;br /&gt;
|Thore Uwe&lt;br /&gt;
|Aye&lt;br /&gt;
|s202746&lt;br /&gt;
|[[Quality Gates in Project Management]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 9&lt;br /&gt;
|Lydia&lt;br /&gt;
|Tsintzou&lt;br /&gt;
|s193745&lt;br /&gt;
|[[SWOT Analysis Guide]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 28&lt;br /&gt;
|Kendra Ana&lt;br /&gt;
|Rodríguez López&lt;br /&gt;
|s200182&lt;br /&gt;
|[[Choosing by Advantages Decision-Making System]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 23&lt;br /&gt;
|Rasmus&lt;br /&gt;
|Engberg&lt;br /&gt;
|s164513&lt;br /&gt;
|[[RDM]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 4&lt;br /&gt;
|Christine&lt;br /&gt;
|Fryland&lt;br /&gt;
|s153875&lt;br /&gt;
|[[Theory X-Y in project management]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 28&lt;br /&gt;
|Manas P.&lt;br /&gt;
|Dalvi&lt;br /&gt;
|s210143&lt;br /&gt;
|[[Effective Tools for Multiple Project Management]]&lt;br /&gt;
-&lt;br /&gt;
|-&lt;br /&gt;
|Group 12&lt;br /&gt;
|Joakim&lt;br /&gt;
|Vollertzen&lt;br /&gt;
|s163947&lt;br /&gt;
|[[Extreme Project Management (XPM)]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 19&lt;br /&gt;
|Shubham&lt;br /&gt;
|Ingole&lt;br /&gt;
|s200092&lt;br /&gt;
|[[Stakeholder Management using Social Network Theory]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 31&lt;br /&gt;
|Alvaro&lt;br /&gt;
|Bello&lt;br /&gt;
|s210447&lt;br /&gt;
|[[Forecasting and estimation techniques]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 09&lt;br /&gt;
|Dorothea&lt;br /&gt;
|Georgiadou&lt;br /&gt;
|s200230&lt;br /&gt;
|[[Risk Register analysis]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 09&lt;br /&gt;
|Maria Konstantina&lt;br /&gt;
|Papaioannou&lt;br /&gt;
|s195550&lt;br /&gt;
|[[Fishbone diagram analysis]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 21&lt;br /&gt;
|Kelvin&lt;br /&gt;
|Scott-Fordsmand&lt;br /&gt;
|s174312&lt;br /&gt;
|[[RiskRegister]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 18&lt;br /&gt;
|Christoffer Friis&lt;br /&gt;
|Hansen&lt;br /&gt;
|s164569&lt;br /&gt;
|[[Identifying risk]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 1&lt;br /&gt;
|Giulia &lt;br /&gt;
|Zanelli&lt;br /&gt;
|s205701&lt;br /&gt;
|[[Earned Value Management - EVM]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 29&lt;br /&gt;
|Tinna &lt;br /&gt;
|Dofradottir&lt;br /&gt;
|s203177&lt;br /&gt;
|[[Adaptive Project Framework]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 23&lt;br /&gt;
|Jonatan Larsen&lt;br /&gt;
|Edry&lt;br /&gt;
|s165499&lt;br /&gt;
|[[The iron triangle as an analytical tool]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 4&lt;br /&gt;
|Mikkel Walther&lt;br /&gt;
|Hellesen&lt;br /&gt;
|s203227&lt;br /&gt;
|[[System Readiness Level Index]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 5&lt;br /&gt;
|Yamila Denise&lt;br /&gt;
|Aviles&lt;br /&gt;
|s203409&lt;br /&gt;
|[[Agile Release Train]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 5&lt;br /&gt;
|Kallina&lt;br /&gt;
|Karamitsiou&lt;br /&gt;
|s202249&lt;br /&gt;
|[[Kahneman&#039;s dual-system thinking]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 19&lt;br /&gt;
|Prasad&lt;br /&gt;
|Jagtap&lt;br /&gt;
|s200109&lt;br /&gt;
|[[Communication Management using Service Blueprint]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 3&lt;br /&gt;
|Johan Holger &lt;br /&gt;
|Rasmussen&lt;br /&gt;
|s210512&lt;br /&gt;
|[[Daniel Kahneman&#039;s two systems of thinking]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 18&lt;br /&gt;
|Sigrún Björk &lt;br /&gt;
|Sævarsdóttir&lt;br /&gt;
|s200165&lt;br /&gt;
|[[The Scrum framework]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 1&lt;br /&gt;
|Francesca&lt;br /&gt;
|Pieraccini&lt;br /&gt;
|s206673&lt;br /&gt;
|[[Double Diamond model]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 15&lt;br /&gt;
|Dionysios&lt;br /&gt;
|Dasopoulos&lt;br /&gt;
|s202916&lt;br /&gt;
|[[Tuckman&#039;s Model for Sustainable Team Development]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 15&lt;br /&gt;
|Joern&lt;br /&gt;
|Appelt&lt;br /&gt;
|s202854&lt;br /&gt;
|[[Intrinsic Motivation]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 23&lt;br /&gt;
|Oliver&lt;br /&gt;
|Karlsson&lt;br /&gt;
|s165080&lt;br /&gt;
|[[Double Diamond Model]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 5&lt;br /&gt;
|Victor&lt;br /&gt;
|Soler Fuertes&lt;br /&gt;
|s206040&lt;br /&gt;
|[[OKR - Objectives and Key Results]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 31&lt;br /&gt;
|João&lt;br /&gt;
|Ferreira&lt;br /&gt;
|s202867&lt;br /&gt;
|[[Psychological safety as a key factor to quality and productivity of Organizations]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 31&lt;br /&gt;
|Timo&lt;br /&gt;
|Scheitinger&lt;br /&gt;
|s202966&lt;br /&gt;
|[[The big five (OCEAN)]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 15&lt;br /&gt;
|Maria-Lito&lt;br /&gt;
|Glykioti&lt;br /&gt;
|s151256&lt;br /&gt;
|[[The role of Emotional Intelligence in Project Management]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 15&lt;br /&gt;
|Hafeez&lt;br /&gt;
|Ahmadi&lt;br /&gt;
|s164137&lt;br /&gt;
|[[ISM Principles of Change]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 18&lt;br /&gt;
|Marie Elly Ulricke&lt;br /&gt;
|Kristensen&lt;br /&gt;
|s144408&lt;br /&gt;
|[[Motivation through Theory X&amp;amp;Y from a Project Management perspective]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 18&lt;br /&gt;
|Christopher &lt;br /&gt;
|Burgdorf&lt;br /&gt;
|s154689&lt;br /&gt;
|[[Simple Multi-Attribute Rating Technique (SMART)]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 5&lt;br /&gt;
|Ishak&lt;br /&gt;
|Zaaimia&lt;br /&gt;
|s164631&lt;br /&gt;
|[[Parkinson&#039;s Law]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 11&lt;br /&gt;
|Sara Ballegaard&lt;br /&gt;
|Laursen&lt;br /&gt;
|s193723&lt;br /&gt;
|[[Organizational Socialization]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 19&lt;br /&gt;
|Ali Waleed&lt;br /&gt;
|Abbas&lt;br /&gt;
|s172841&lt;br /&gt;
|[[Fishbone diagram for root cause analysis]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 17&lt;br /&gt;
|Cecilia&lt;br /&gt;
|Thuy Duyen Nguyen-Cong&lt;br /&gt;
|s184300&lt;br /&gt;
|[[The 7 Habits of Highly Effective People by Stephen R. Covey]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 44&lt;br /&gt;
|Farah&lt;br /&gt;
|Sabri&lt;br /&gt;
|s164740&lt;br /&gt;
|[[Lack of communication in project management]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 1&lt;br /&gt;
|Shakila&lt;br /&gt;
|Khan Malik&lt;br /&gt;
|s173780&lt;br /&gt;
|[[Risk]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 27&lt;br /&gt;
|Asbjørn Martin&lt;br /&gt;
|Kruuse&lt;br /&gt;
|s153470&lt;br /&gt;
|[[Chairing a meeting]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 23&lt;br /&gt;
|Tummas Dímun&lt;br /&gt;
|Mohr&lt;br /&gt;
|s160129&lt;br /&gt;
|[[Project Dashboards]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 27&lt;br /&gt;
|Vanessa &lt;br /&gt;
|Clausen&lt;br /&gt;
|s183302&lt;br /&gt;
|[[Overcoming small-big projects (Gantt)]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 09&lt;br /&gt;
|Emil &lt;br /&gt;
|Ballermann&lt;br /&gt;
|s174393&lt;br /&gt;
|[[Parkinson&#039;s law and how to manage it]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 4&lt;br /&gt;
|Gian Marco&lt;br /&gt;
|Grieco&lt;br /&gt;
|s202893&lt;br /&gt;
|[[Parkinson&#039;s Law: achieving more in less time]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 44&lt;br /&gt;
|Shahad&lt;br /&gt;
|Abdelaziz&lt;br /&gt;
|s122945&lt;br /&gt;
|[[Outsourcing]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 3&lt;br /&gt;
|Tais&lt;br /&gt;
|Christiansen&lt;br /&gt;
|s165131&lt;br /&gt;
|[[Relationship of projects, programs and portfolios]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 4&lt;br /&gt;
|Sana&lt;br /&gt;
|Ilyas&lt;br /&gt;
|s192815&lt;br /&gt;
|[[SCRUM framework]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 5&lt;br /&gt;
|Mia Chrstine&lt;br /&gt;
|Wheitman&lt;br /&gt;
|s206053&lt;br /&gt;
|[[The use of Gantt Charts]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 35&lt;br /&gt;
|Sigurjón Bjarni&lt;br /&gt;
|Bjarnason&lt;br /&gt;
|s202049&lt;br /&gt;
|[[The Work breakdown structure(WBS)]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 19&lt;br /&gt;
|Morten Dam&lt;br /&gt;
|Laursen&lt;br /&gt;
|s200364&lt;br /&gt;
|[[Multiple Project Management: Summary, Theory and Improvement]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 29&lt;br /&gt;
|Céline Engelbrecht&lt;br /&gt;
|Galea-Larsen&lt;br /&gt;
|s147312&lt;br /&gt;
|[[Group Development - The Tuckman Model]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 28&lt;br /&gt;
|Hazal &lt;br /&gt;
|Alawi&lt;br /&gt;
|s180408&lt;br /&gt;
|[[The Double Diamond Framework]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 17&lt;br /&gt;
|Xenia&lt;br /&gt;
|Jørgensen&lt;br /&gt;
|s123633&lt;br /&gt;
|[[Teams - Creation and optimisation]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 11&lt;br /&gt;
|Jonas &lt;br /&gt;
|Bøje Simonsen&lt;br /&gt;
|s154089&lt;br /&gt;
|[[Logic tree and the Answer First Methodology]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 28&lt;br /&gt;
|Kavikrishnan&lt;br /&gt;
|Balakrishnan&lt;br /&gt;
|s164338&lt;br /&gt;
|[[Learning plans for high uncertainty projects]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 2&lt;br /&gt;
|Riccardo&lt;br /&gt;
|Pollacchini&lt;br /&gt;
|s192412&lt;br /&gt;
|[[Complex Project Management (CPM)]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 44&lt;br /&gt;
|Rokiya &lt;br /&gt;
|Ahmed Ramzy&lt;br /&gt;
|s170501&lt;br /&gt;
|[[Lean in construction industry]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 50&lt;br /&gt;
|Avishkar Anil &lt;br /&gt;
|Vadnere&lt;br /&gt;
|s206513&lt;br /&gt;
|[[Strategic Planning using SWOT analysis]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 5&lt;br /&gt;
|Niels  &lt;br /&gt;
|Tietgen&lt;br /&gt;
|s193191&lt;br /&gt;
|[[Microsoft Teams]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 29&lt;br /&gt;
|Bastien&lt;br /&gt;
|Haas&lt;br /&gt;
|s202932&lt;br /&gt;
|[[The 7 habits of highly effective people applied to Management]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group 17&lt;br /&gt;
|Jacob&lt;br /&gt;
|Lützhøft Christensen&lt;br /&gt;
|s184113&lt;br /&gt;
|[[Lag and Lead]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
|Group&lt;br /&gt;
|William&lt;br /&gt;
|Vossgård&lt;br /&gt;
|s213015&lt;br /&gt;
|[[Risk Register for Engineering Projects]]&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_Registering_for_Egineering_Projects&amp;diff=110726</id>
		<title>Risk Registering for Egineering Projects</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_Registering_for_Egineering_Projects&amp;diff=110726"/>
		<updated>2022-02-21T14:35:51Z</updated>

		<summary type="html">&lt;p&gt;Williamvoss: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[Risk Registering for Egineering Projects]]&lt;/div&gt;</summary>
		<author><name>Williamvoss</name></author>
	</entry>
</feed>