Fishbone diagram

From apppm
Revision as of 16:09, 18 September 2017 by Karoline (Talk | contribs)

Jump to: navigation, search

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

The Team

Common ways it is used

Limitations of the Fishbone Diagram

What the tool will not achieve

Tools it is often used in conjunction with to achieve the end goal

Suggested literature not covered by the DTU License

References

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox