||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.
- system boundary (optional);
- arrows (which may occasionally be labelled);
- Inclusion of a system boundary is optional but recommended.
- 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’.
- 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’.
- 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’.
- 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).
- The chain of causal connections may be entirely sequential, or it may include
- A title defining the system of interest is essential.
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
- 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
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.
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.
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.
- 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.
- 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.