Multiple cause diagrams

Format for a multiple cause diagram


This type of diagram is used to explore why a given event happened or why a certain class of events tends to occur. It is not intended to predict behaviour, but may be used to develop a list of factors to bear in mind when considering comparable circumstances in the future. It is also useful for finding out why something went wrong or keeps recurring, e.g. through a causal loop, so that steps can be taken to prevent its recurrence. It can be derived from an influence diagram or developed anew.



  1. Inclusion of a system boundary is optional but recommended.
  2. The phrases (aaa, bbb, ccc, ddd, etc.) relate to a state or an event e.g. ‘flat battery’ or ‘battery goes flat’. But, as the diagram is developed, it is preferable to describe these factors in terms of a variable (something that has a value that can go up or down) e.g. ‘amount of charge in battery’.
  3. Arrows indicate the causal connections between the phrases, and are read as phrase at tail of arrow causes phrase at head of arrow, e.g. ‘leaving lights on’ causes ‘flat battery’.

  4. In a more developed diagram, with variables rather than states, the arrow is better read as ‘affects’ e.g. ‘length of time lights are left on’ affects ‘amount of charge in battery’.
  5. In general arrows are not labelled. However, it is acceptable to do so if you wish to add information about the type of causal connection e.g. ‘length of time lights are left on’ reduces ‘amount of charge in battery’ (to emphasize that an increase on one leads to a decrease in the other). Or ‘leaving lights on’ contributes to ‘flat battery’ (to emphasize that this is unlikely to be the only cause).
  6. The chain of causal connections may be entirely sequential, or it may include loops.
  7. A title defining the system of interest is essential.


  1. In constructing such a diagram you normally begin at the factor/event to be explained and work backwards. A diagram should include more than one such end factor only if contributory factors were related, and explaining both events is important.
  2. It is not necessary to put blobs around phrases, although if it improves clarity you can. Boxes, with their ‘activity sequence diagram’ implications, are best avoided.
  3. It helps in checking a draft to ensure that each individual relationship makes sense. If the meaning is not obvious then be more specific or insert any necessary intermediate causes.
  4. Take care not to combine two factors into one e.g. ‘battery is flat and car won’t start’. This can prevent your identifying differences in their causes or consequences, and therefore potential points of intervention.
  5. This type of diagram does not distinguish between necessary and/or sufficient causes (for example, in the figure above, Event aaa and Event bbb may both be necessary if Event ccc is to occur; or either may be sufficient to cause Event ccc). If the distinction is important for your purpose you will need to annotate your diagram to indicate this.
  6. It is not essential to indicate a system boundary on a multiple-cause diagram, particularly if it has been developed from an influence diagram that already has one. Drawing such a diagram may well, however, develop your ideas about where to draw a boundary and so identify a system of interest.
  7. It is important to remember that this diagram type, while superficially resembling an influence diagram, is different in that the words at either end of an arrow represent events that may happen or values that may change. In an influence diagram these words represent components of a system e.g. people or sub-systems.