Fishbone diagram
(→Application of the Fishbone Diagram) |
(→Application of the Fishbone Diagram) |
||
| Line 18: | Line 18: | ||
When using the fishbone diagram it is particularly useful to do so on a large surface -such as e.g. a whiteboard, with lots of space for categories, subcategories, and causes, since the team cannot know at the beginning of the process just how many of these will be needed. Following is a step by step guide to using the fishbone diagram<!--ref to LBSpartners-->: | When using the fishbone diagram it is particularly useful to do so on a large surface -such as e.g. a whiteboard, with lots of space for categories, subcategories, and causes, since the team cannot know at the beginning of the process just how many of these will be needed. Following is a step by step guide to using the fishbone diagram<!--ref to LBSpartners-->: | ||
| − | # The investigated problem should be written in the far right side of the whiteboard and a horisontal line to the left of it. Some make it an arrow aiming at the problem <!--ref to LBSpartners and CityProcessManagement-->to illustrate that this is the effect of the causes that are to be identified. But whether it is an arrow or just a line is of no consequence to the functionality of the diagram and is so up to the personal preferences of the team. | + | # The investigated problem should be written in the far right side of the whiteboard and a horisontal line to the left of it. Some make it an arrow aiming at the problem <!--ref to LBSpartners and CityProcessManagement-->to illustrate that this is the effect of the causes that are to be identified. But whether it is an arrow or just a line is of no consequence to the functionality of the diagram and is so up to the personal preferences of the team. <br /><!--insert image of this step--><br /> |
| − | <!--insert image of this step--> | + | # Now the categories -or causes for the problem, should be written a good distance of to each side of the line -there should also be some distance between the categories themselves. Lines ar drawn from each category to the line. Again these lines could be made into arrows<!--ref to CityProcessManagement--> or not<!--ref to Wong-->. <br /><!--insert image of this step--><br /> |
| − | <br / | + | # The appropriate subcategories or "sub"-causes can now be fitted into each of the categories by making horisontal lines on either side of the line connecting a category and "spine" of the fish, and writing the subcategory or cause in it. Whether subcategories are needed or not is largely up to the team and how detailed they want to do the diagram. It is entirely possible to solve the problem without a subcategory -in this case what would otherwise be the subcategory is now a cause. An example could be that for a category named "People" a cause could be "Employees not showing up for work". In this case the team could decided that this a root cause and a brainstorm on how to solve the problem could be to change the way employees are paid to depending on how much time they spend at work or put a limit on how many sick days employees are allowed. Another action could be that the team decides that "Employees not showing up for work" is a subcategory to which there is the cause "Employees bully each other". Now the team can brainstorm other ways to manage the problem, and will probably reach other conclusions than in the previous scenario. If the first scenario happens it is likely that that the work environment will worsen further and that one or more employees will leave the company. This of course creates new problems for the company as it is symptom treatment rather than doing something about the root of the problem, the root cause, which as it turns out the team had not managed to find after all. To find the root cause the team must continually ask why this happens. Why do the employees not show up for work? Why are the employees bullying each other? This approach is called "The Five Whys" as this is the approximate amount of whys a team will need to ask in order to reach the root cause<!--ref to Cityprocess and asq-->. <br /> <!--insert image of this step--> <br /> |
| − | # Now the categories | + | # Once the causes have been found the team can grade them in regards to how easy to fix or control they are and how likely they are to happen. This will help the team prioritising which causes to treat and how to manage their time and effort. A way of grading this could be, "Very Easy", "Somewhat Easy", "Not Easy" and "Very Likely", "Somewhat Likely", "Not Likely". The causes the team should focus on have the combinations "Very Easy-Very Likely", "Very Easy-Somewhat Likely", and "Somewhat Easy-Very Likely"<!--ref to Wikipedia and LBSpartners-->. |
| − | <!--insert image of this step--> | + | |
| − | + | ||
| − | # The appropriate subcategories or causes can now be fitted into each of the categories by making horisontal lines on either side of the line connecting a category and "spine" of the fish, and writing the subcategory or cause in it. Whether subcategories are needed or not is largely up to the team and how detailed they want to do the diagram. It is entirely possible to solve the problem without a subcategory -in this case what would otherwise be the subcategory is now a cause. An example could be that for a category named "People" a cause could be "Employees not showing up for work". In this case the team could decided that this a root cause and a brainstorm on how to solve the problem could be to change the way employees are paid to depending on how much time they spend at work or put a limit on how many sick days employees are allowed. Another action could be that the team decides that "Employees not showing up for work" is a subcategory to which there is the cause "Employees bully each other". Now the team can brainstorm other ways to manage the problem, and will probably reach other conclusions than in the previous scenario. | + | |
| − | + | ||
| − | + | ||
| − | # Once the causes have been found the team can grade them in regards to | + | |
Revision as of 09:25, 19 September 2017
The Fishbone diagram is named for its resemblance to a fishbone with the investigated problem being in the place of the head and the identified root causes coming out of the spine (see picture). It is also called an Ishikawa diagram after its creator Kaoru Ishikawa or a Cause-and-Effect diagram. Identifying the root causes of a problem makes it a valuable tool in Risk Management, as it can help the team figuring out how best to handle this with ARTA.
This article will focus on the fishbone diagram. It will consider how the diagram is appropriately used in Risk Management as well as its purpose ans limitations. It will also touch upon tools that can be used in conjunction with the diagram to strengthen a project's management of risks. The article will be based on previous literature on the subject.
Contents |
The Purpose of the Fishbone Diagram
The purpose of the fishbone diagram in risk management is to identify various root causes of a potential problem for a project or program. It does so by having the user brainstorm over various causes for the problem and then sorting them into various categories each illustrated as a rib the "spine" in the diagram. A rib might have more subcategories and so might each of these categories, see the Illustration. The process of making new "ribs" on the fish continues until the team agrees, that the root cause has been reached. The fishbone diagram facilitates communication in the team as it requires the team members to discuss the likelihood and impact each of the identified causes might have on the project. As in how likely each cause is to cause the problem. This allows the team to treat the problem as according to ARTA by handling the root causes of the problem. When using the diagram a diverse team can be an advantage as the team is likely to identify more causes, but it is also very important to have a common ground on which to grade the likelihood and impact of each root cause, which can be difficult for a too diverse team as each member will tend to focus on the categories they are the expert in. As such they not be able to relate the likelihood and impact of the root causes of their own categories to those of the other categories. This can potentially lead to some root causes being underestimated while others are overestimated, so that some root causes will not get the attention and contingency plans they deserve and need because it is given to other root causes. Thus the problem might happen anyway without an effective contingency plan. This goes to show, that proper communication and a common ground or standard on which to grade the impact and likelihood of a cause is very important when using the fishbone diagram. A less diverse team might have an easier time finding this common ground or standard, but in return it is likely that they find all the relevant root causes or will have the knowledge to make the appropriate contingency plans. Here a diverse team means that that the members have different strengths in the form of a category for the diagram. As an example think of a team from a start-up company making a new car. The team might be discussing something as open as why the car is not selling well. There might be someone in the team who is the expert on the car as a product, and someone who is the expert on the market wants and needs, etc. But without an expert on the sales channels the team might overlook that all of the car distributors have agreements or contracts with other and bigger car fabricants that means they are either not interested in or allowed to do business with the start-up company. Here expert simply means that this person is in charge of that specific aspect of making or selling the car and in the light of this naturally will have more knowledge about this category than the other team members.
Application of the Fishbone Diagram
When a team is doing risk management they will often need several fishbone diagrams as each one only corresponds to one problem while several problems may arise during a project. A problem could, as suggested earlier be something like the risk of customers not buying a car. Thus the problems are the risks the team will want to manage. It is also called an effect which is how the diagram also got the name Cause-and-Effect diagram. When using the fishbone diagram it is particularly useful to do so on a large surface -such as e.g. a whiteboard, with lots of space for categories, subcategories, and causes, since the team cannot know at the beginning of the process just how many of these will be needed. Following is a step by step guide to using the fishbone diagram:
- The investigated problem should be written in the far right side of the whiteboard and a horisontal line to the left of it. Some make it an arrow aiming at the problem to illustrate that this is the effect of the causes that are to be identified. But whether it is an arrow or just a line is of no consequence to the functionality of the diagram and is so up to the personal preferences of the team.
- Now the categories -or causes for the problem, should be written a good distance of to each side of the line -there should also be some distance between the categories themselves. Lines ar drawn from each category to the line. Again these lines could be made into arrows or not.
- The appropriate subcategories or "sub"-causes can now be fitted into each of the categories by making horisontal lines on either side of the line connecting a category and "spine" of the fish, and writing the subcategory or cause in it. Whether subcategories are needed or not is largely up to the team and how detailed they want to do the diagram. It is entirely possible to solve the problem without a subcategory -in this case what would otherwise be the subcategory is now a cause. An example could be that for a category named "People" a cause could be "Employees not showing up for work". In this case the team could decided that this a root cause and a brainstorm on how to solve the problem could be to change the way employees are paid to depending on how much time they spend at work or put a limit on how many sick days employees are allowed. Another action could be that the team decides that "Employees not showing up for work" is a subcategory to which there is the cause "Employees bully each other". Now the team can brainstorm other ways to manage the problem, and will probably reach other conclusions than in the previous scenario. If the first scenario happens it is likely that that the work environment will worsen further and that one or more employees will leave the company. This of course creates new problems for the company as it is symptom treatment rather than doing something about the root of the problem, the root cause, which as it turns out the team had not managed to find after all. To find the root cause the team must continually ask why this happens. Why do the employees not show up for work? Why are the employees bullying each other? This approach is called "The Five Whys" as this is the approximate amount of whys a team will need to ask in order to reach the root cause.
- Once the causes have been found the team can grade them in regards to how easy to fix or control they are and how likely they are to happen. This will help the team prioritising which causes to treat and how to manage their time and effort. A way of grading this could be, "Very Easy", "Somewhat Easy", "Not Easy" and "Very Likely", "Somewhat Likely", "Not Likely". The causes the team should focus on have the combinations "Very Easy-Very Likely", "Very Easy-Somewhat Likely", and "Somewhat Easy-Very Likely".
It should be noted that though this is presented as a step by step guide it might be that the team e.g. fills out a category before making the next or once having filled out all the categories realise that some of the causes from several of the categories are connected and is better treated in a new category made just for them. It is possible to go back in the steps to alter the output of it. It means that team didn't know all they thought they did at the beginning and is figuring out something new about the project. If the team used any tools or methods to find the categories or causes, the team might need to go through those again to make sure they have all relevant categories or causes, if this is the case.
