Skip to main content

About this free course

Download this course

Share this free course

Mastering systems thinking in practice
Mastering systems thinking in practice

Start this free course now. Just create an account and sign in. Enrol and complete the course for a free statement of participation or digital badge if available.

4 Multiple-cause diagrams

Figure 4 Format for a multiple cause diagram

Purpose

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. They are 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. They can be derived from an influence diagram or developed anew. Sequential multiple cause diagrams are similar to activity sequence diagrams. They also share similarities with systems dynamics diagrams that you may encounter in the wider literature.

Elements

System boundary (optional)

Phrases

Arrows, which may be labelled

Title.

Conventions

  1. Inclusion of a system boundary is optional but highly recommended.
  2. The phrases (e.g. aaa, bbb, ccc, ddd, etc.) relate to the state of ‘things’ (e.g. flat battery). But, as the diagram is developed, it is preferable to describe the relevant variables associated with those things (e.g. decreased charge level in battery). Phrases may also represent events (e.g. corrosion of terminal).
  3. Arrows do not necessarily mean causes. They may be read as meaning ‘contributes to’, ‘leads to’, ‘enables’ or similar terms (but not ‘means’).
  4. The diagram may be entirely sequential, or it may contain loops.
  5. A title defining the system of interest is essential.

Guidelines

  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. Because the arrows may represent different kinds of contribution/cause, it may be helpful to label them.
  3. It is not necessary to put blobs around phrases, although if it improves clarity you can. Boxes, with their ‘designed system’ implications, are best avoided.
  4. It helps in checking a draft to ensure that each individual relationship is clear. Insert any necessary intermediate variables/factors if not.
  5. This type of diagram does not distinguish between necessary and/or sufficient causes (for example, in Figure 4, 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 necessary 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 it is to be read sequentially, rather than as a snapshot representation.

Now go back to Week 4 [Tip: hold Ctrl and click a link to open it in a new tab. (Hide tip)] .