Skip to main content
    QHSEtech
    Updated
    All glossary terms
    Content date: · No individual check logged· AI use

    Fishbone Diagram

    Also known as: Ishikawa diagram, Cause-and-effect diagram

    Definition

    Also called an Ishikawa or cause-and-effect diagram: a chart grouping the possible causes of one problem under category branches for a team to test.

    Editorial definition: The QHSE Standard, updated 3 October 2026 · https://qhsetech.com/glossary/fishbone-diagram

    Scope: It lists possible causes; none of them is a finding until evidence supports it.

    What a published review says about the diagram

    An article in the Global Journal on Quality and Safety in Healthcare, held in the PMC archive of the US National Library of Medicine, describes a cause-and-effect diagram as a visual aid that shows how the factors behind one effect relate to it, in a shape that resembles the bones of a fish, and notes that it is also called an Ishikawa diagram after its creator. The head holds the problem. The long bones carry the possible main causes and the short bones the contributing factors and specific causes. For a classic diagram the article gives the usual categories as materials, methods, equipment, environment and people, and its drawing steps say to label each long bone with a relevant category.

    The article is candid about limits. A fishbone could generate both irrelevant and relevant potential causes, and acting on the irrelevant ones may lead to changes that do not address the problem. It adds that the tools do not generate ideas for change automatically. It suggests team brainstorming on notes, repeating rounds until ideas run out, and a multi-voting step to pick the most likely causes, which are then tested or checked against data. If several root causes exist, a separate diagram for each may be needed. The article's case study concerns needlestick injuries among staff, so the tool is not confined to product quality.

    OSHA's incident investigation page asks investigators to look past immediate causes and says the contributing factors nearly always trace to deficiencies in equipment, procedures, training or other parts of the safety and health programme. A fishbone is one way to lay those out, though OSHA's page does not name it. The ADB note on the five whys lists the Ishikawa, or fishbone, diagram among other tools to try when the technique does not direct attention to one of the usual root-cause areas, such as materials, equipment, methods or people. This page is general information, and the sources above describe the diagram as a tool.

    Sources opened :

    What a fishbone record holds in software

    • The problem statement in the head, limited to one effect and written from facts.
    • The category headings chosen for this problem, stored so the diagram can be redrawn.
    • Each possible cause under its category, with who proposed it and when.
    • Sub-causes entered as branches and kept with their parent.
    • A status for every cause: unverified, supported by attached evidence, or ruled out with the reason.
    • The vote or discussion used to choose which causes to test, with the participants.
    • The data collected or change trialled for each selected cause and what it showed.
    • Links to the investigation or nonconformance the diagram belongs to and to the actions that followed.

    Fishbone diagram, 5 whys and category sets

    A fishbone maps possible causes by category, while a 5 whys chain follows one thread down. The two are often combined, as the PMC article notes. Category labels such as manpower, methods, machines, materials, measurement and environment are another set in use, and the article lists a different one, so neither is a standard. A tool that fixes the headings shapes what a team thinks to ask, so check whether they can be edited. A finished diagram is a list of hypotheses and not a finding.

    A hypothetical example: chipped drawer fronts

    This case is invented to show how a diagram session runs and describes no real firm. A cabinet workshop sees chipped edges on drawer fronts coming off its routing line. The team draws the effect in the head and uses five categories: people, methods, equipment, materials and environment. Over two rounds on sticky notes they list fourteen possible causes. Each person then puts three marks on the causes they think are likeliest. Three collect most of the marks: a router bit that may be worn (equipment), a feed speed taken from a sheet written for a different board thickness (methods) and boards that may arrive damp at the edges (materials).

    Each of the three gets a test. The tool log shows when the bit was last changed, a trial on one shift with a new bit is counted against the old rate, and edge moisture is measured on a sample of boards. The bit and the speed sheet are confirmed as contributors. The moisture readings are within the supplier's stated range, so that cause is marked ruled out with the reading attached. The other eleven causes stay on the diagram as unverified. Actions follow for the two confirmed causes, and the chip count per shift is reviewed a month later.

    Common misunderstandings about the fishbone diagram

    • A full diagram looks like an analysis but is a list of possibilities. The PMC article warns that it can produce irrelevant as well as relevant causes.
    • The categories are prompts and not answers. A cause that fits no heading still belongs on the diagram, and one that fits two can be repeated under both.
    • One diagram serves one problem. Several effects, or several separate root causes, may need several diagrams.
    • A vote is not evidence. Multi-voting helps a team choose what to test first, and a cause counts as supported only when data or observation backs it.
    • It is not only a quality-department tool. The article's case concerns injuries to staff, and the same layout serves safety and environmental problems.

    How the fishbone diagram relates to other glossary terms

    The diagram organises possible causes, so its neighbours are the methods that test them and the places the results go.

    • 5 whys: follows one chain of questions downwards and is often combined with a diagram.
    • Root cause analysis: the wider activity of which the diagram is one tool.
    • Non-conformance: the quality record that a cause analysis usually belongs to.
    • Hierarchy of controls: a way to rank the options once hazard-related causes are confirmed.

    Records and evidence that usually exist for a fishbone analysis

    • The diagram itself, as an image or structured data, with date and participants.
    • The problem statement.
    • Evidence for each cause chosen for testing.
    • Test results, measurements or data samples.
    • Reasons for ruling causes out.
    • Actions raised and the later effectiveness check.

    What a software tool needs to capture for a fishbone diagram

    • Category headings that can be edited and are stored with the diagram.
    • Causes held as structured entries, not only as a picture, so they can be searched and counted.
    • A status field on each cause with room for evidence and a reason when it is ruled out.
    • More than one diagram per event or nonconformance.
    • A record of participants and of any voting used to select causes.
    • Export of both the image and the data.
    • Links from confirmed causes to actions, and version history.

    Catalog profiles documenting root cause analysis

    The profiles listed record a root-cause capability. Drawing cause-and-effect diagrams, or keeping the evidence for each cause, is not established by that and is worth testing in a demonstration.

    Same rule for every product: tagged “Root Cause & Investigation”, “Incident Management”, “Incident Reporting”, “CAPA Management”, “Quality Management”, “Safety Management”, “EHS Management”, “Occupational Health”, “Risk Assessment”, “Risk Management”, “Food Safety”, “Audits & Inspections” or “Barrier Management”, with a sourced root cause analysis capability in its record, or one the vendor stated to us, labelled as vendor-stated. Documented and conditional capabilities qualify; check the linked scope before treating a module as included.

    Tekmon pays for a sponsored placement (above); its place in this list follows the same rule as every entry. How lists are ordered

    All 49 matching profiles are shown. Documentation review, not hands-on testing or a claim of compliance.

    Related software

    Frequently asked questions

    Does a standard require a fishbone diagram?

    None of the sources opened for this page requires it; they describe it as a tool. A customer, certification body or your own procedure may name methods, so check what applies to you.

    Which categories should the bones use?

    The PMC article gives materials, methods, equipment, environment and people as the usual categories of a classic diagram and says to label each bone with a relevant one. Choose headings that fit the problem and record them.

    How many causes should a diagram show?

    The sources set no target number. The article suggests brainstorming until ideas run out, then multi-voting to pick the likeliest causes and testing those against data.

    More quality terms

    Related guides