The concept of the fishbone diagram and the reverse fishbone diagram
A fishbone diagram helps identify the cause and effect relationship that exists in every system.
The fishbone diagram
The head of the fishbone diagram is the effect; the bones (typically six) in the fishbone diagram are the generic causes behind every effect. Kaouru Ishikawa (1915-1989), a renowned Japanese engineer, identified the generic causes in the fishbone diagram as the six Ms: Machines, Manpower (people), Methods (Processes), Mother Nature (Environment), Money and Measurement.
Once you have your effect, you then can start identifying what the causes are behind that effect. For example, if in the fishbone diagram the effect is “Poor Quality,” one of the causes below the Manpower bone might be “Lack of Training.”
The reverse fishbone diagram: a case study
In my case, I use the fishbone diagram for solutions and outcomes as well; however, I call it the reverse fishbone diagram. You put the solution or outcome in the head (effect) of the fishbone diagram and ask yourself, what do I need in place to ensure this solution or outcome is met? The answers will then be split between the bones, helping you put together a better-rounded project plan.
Below is an example of the application of the reverse fishbone diagram concept. The concept of the reverse fishbone diagram was applied to a project I was leading for Metronet Rail (Metronet Rail looks at maintaining part of the London Underground).
The SAP to Ellipse project
After the integration of one business unit into another one within Metronet, the information systems of those two business units needed to be consolidated. The project objective was to transfer data from a SAP system into an Oracle-based system called Ellipse. Without going into too many details of the project, let’s say this required a full team of three information specialists and a core team of five other part-time members. A project plan was put in place by the information specialists for the transfer of data from SAP into Ellipse. This was all well and good and covered what I like to call the “hard” aspect of the project, but I also wanted to ensure that the project was going to be successful from a “softer” perspective (people, processes, culture etc.).
The execution of the reverse fishbone diagram
To achieve this, I organized a session with the core team of the project, and we created a reverse fishbone diagram to help identify all the critical aspects that had to be in place to ensure a successful project.
In the head of the fish, the project team put the desired outcome (effect), which in this case was simply “SAP to Ellipse Project Successful.” Looking at the generic causes (the bones), the team initially identified 13 critical aspects that needed to be in place to achieve a successful outcome of the project.
For example, under the Measurement bone, the team identified that we needed to have a regular project steering committee every two weeks with the project sponsor to update him on the project and resolve risks and issues. On the Machine bone, we identified that we needed “organized access to both systems for members of the core team.” And so on and so forth.
The fishbone diagram: lessons learned
Some of the items on the fishbone diagram might seem obvious, but as a project manager who had no experience or knowledge in the information system field, this tool helped me identify all the “softer” actions I needed to take to ensure a successful project. Each one of these items on the fishbone diagram ended up on my project plan with start and end dates, action owners and predecessors.
This fishbone diagram is the first draft that was put together as a team. As the project advanced, I kept adding components to the fishbone diagram, hence improving, as a consequence, my project execution.
The reverse fishbone diagram also helped me make sure I was covering “all the bases.” I achieved this by constantly reviewing the fishbone diagram with the core team and asking a question about a bone that I felt lacked content. The “Mother Nature” bone on the fishbone diagram, for example, which covers softer things such as business environment and culture, often lacked “meat,” so I would push the team for answers, asking, “Is there anything else we can do from a cultural perspective to ensure a successful outcome?” The answers were then added to the bone, and if validated, added to the project plan.
The project was delivered on time and under budget. I like to think that the reverse fishbone diagram contributed to a big part in making this project successful.