3 Drawing systems diagrams

This section also mainly involves watching a video, albeit longer than others as it has to cover several different diagrams.

It should be viewed in one sitting but there are points when you may want to stop the video and think about what has been said or to refer again to the Diagram Guidelines to better understand the key features of each diagram type.

Two other things to note before you start:

Firstly, you will see on the video some diagrams prepared or collated by me but which have been redrawn to make them clearer to read. The originals were much scruffier and harder to read as these were diagrams I drew for myself to help me think about the complex situation I was investigating. So do not worry if your attempts at diagramming, whether done now or in the future, do not look as clean or as clear as those presented.

Secondly, these diagrams demonstrate different kinds of diagrams, mostly representations of a complex situation first presented as text. As you work through the video I will explain how I developed some of these diagrams and what I was thinking about at the time as tried to make sense of the article shown below.

As I noted earlier these diagrams have different purposes and are based on conventions. Before you watch the video on drawing diagrams you first need to study the purposes and conventions of the three types of systems diagram I will be using:

These are:

• systems maps
• influence diagrams
• multiple cause diagrams.

You can find information on these in:

• the Diagram Guidelines [Tip: hold Ctrl and click a link to open it in a new tab. (Hide tip)]  

• the article Beware of the human factor (which is the complex situation I am looking at).

You may find it helpful to make notes or draw a spray diagram to capture the key features of the situation described, which is what I do at the beginning of the video, so please do not look at the video until you have made some sense of the article for yourself.

Download this video clip.Video player: A deep dive into diagramming

Show transcript|Hide transcript

Transcript: A deep dive into diagramming

ANDY LANE

I am sure your first reaction on reading this article was where do I start to make sense of that using diagrams? Fortunately I am not asking you to do that. Instead I will show you how, once you get going, and begin to understand what each type of diagram can be used for, things begin to fall into place. This takes some time so bear with me as I work through a number of different diagrams.

From drawing my spray diagram of the complex situation in the article I am certainly struck by the size of the branch at the bottom dealing with the possible causes of failure. The other feature that stands out for me is how many different organisations and government departments or agencies are involved over long time scales and involving so much money.

So far I have simply tried to produce a summary of the situation. I now want to move on to look at different aspects of it. The first is to look at the structural components of a possible system of interest. To do that I drew a systems map starting with the title.

The title should be a short description of what the diagram is trying to represent. It helps focus my attention on the most appropriate components. In this case I have gone for a rather straightforward look at all the organisational relationships involved. I have also abstracted up a level to show clusters of organisations such as ‘Government departments’ and ‘Commercial contractors’ rather than list all the specific ones mentioned in the article. In the end I have only got two subsystems as I thought for a while about where to place the public. Although not specifically mentioned in the article, many of us, the public, are being affected by this system but it is not clear that we are seen as being part of it. You may disagree, and that’s ok as long as you give your reasoning. The point is that this is my representation of the situation and it is already making me think more deeply about it.

However, I was dissatisfied with this systems map as it did not tell me too much that I did not get from just reading the article so I decided to draw another one that focused on the functions the different groups performed rather than the organisations themselves.

Looking at this second systems map notice that I have also changed the title to reflect my change in emphasis. This time I have 3 sub-systems which seem to cover the main functions as I see it of initiating, providing and using the new IT projects. Also the public are inside the system as users, in some form, of the IT projects. Perhaps I should not have left them outside in the last map. Training appears twice, once as training for the IT professionals and once as staff in the relevant user organisations needing to be properly trained. Outside the boundary I have elements which affect the system but are not necessarily affected by it. For instance, the state of the economy will influence how much tax payers’ money there is to spend and the drive to implement policies that require IT support. If those IT projects fail then there will be some impact on the economy but it will be negligible in nearly all cases.

This has certainly given me a new slant on the situation but I need to move on to other diagram types to investigate it further.

This is because maps of this kind are very useful when you want to get a quick overview of how the structure of a situation is perceived. However they don't describe flows and processes occurring over time nor the links between components and you have to make the judgements about how much detail to include. For example, in drawing my second system map I decided to leave out the different reasons for failure of the IT projects. That's because my purpose in drawing the map was to see the main features of the possible system for arriving at hopefully successful IT projects and not to investigate the process by which many have appeared to fail.

Nevertheless systems maps can often be usefully developed into a somewhat richer type of diagram by including lines or arrows to indicate where important relationships exist between particular blobs. Such diagrams are called influence diagrams and the next diagram shows one that I developed from my second systems map.

I want to make a number of general points about this influence diagram before discussing what I was thinking as I drew it.

First, though an influence diagram is often developed from a systems map, drawing it normally involves more than just adding lines or arrows to a systems map as it's important to keep the number of crossed lines to a minimum and to keep lines fairly short.

Second, you may well want to regroup and redefine some of the blobs to reduce the number of lines and to make their meaning more readily apparent. If you compare my second systems map and this influence diagram you will see several changes in the blobs but what you may be wondering is what do the arrows actually mean? Quite what an arrow means in an influence diagram would depend on the particular diagram and its content but in general terms it does mean influence although sometimes the term “influence” is pretty vague. For example, it's slightly odd in this influence diagram to read only of the impact of “choice of technology” on “software” as the latter does also influence the former. Nevertheless, I gathered the impression from the article that it was more often the technology that dictated which software was used rather than the other way round. I may be wrong but at least I have exposed it as an issue to look at further.

If it isn't clear to you what kind of relationship is implied by a particular arrow, it probably won't be clear to anyone else either, so the way to check a diagram is to read it back to yourself and ask: “Is that how I see things?” or “Does that correspond to the thinking I'm trying to represent?”.

Another point about drawing these influence lines is that you have to be very selective and make choices. Every blob in this influence diagram could legitimately have been linked to every other blob I dare say. For example, the “public” has occasionally influenced “policies” in some way, but putting in all the influence lines would clutter up the diagram, and you wouldn't tell what it was mainly about. So the general principle once again is a matter of representing the most important relationships, selecting and choosing, and that involves judgement. It is for all these reasons that I have dropped the sub-system boundary lines and slightly changed the wording in some of the blobs, in order to make it clearer to me. But this is just my first stab at an influence diagram. I then went on to produce this revised one.

Looking in detail at this revised influence diagram you will notice first of all that I have left off the systems boundary. I have done this because I am only looking at the elements within the system and I identified what was outside in the environment last time. I have also brought together elements of organisations from my first systems map and functions from my second systems map and used a thicker arrow to indicate stronger influences. Thus I see the government departments and the IT companies as strongly influencing the technology and software which then strongly influences the users or user needs. My impression, partly influenced from reading about IT failures elsewhere, is that either IT projects are foisted on the hapless users without enough consideration of what the user wants. Or a piece of technology or software originally developed for one purpose is then adapted for a new purpose and found to be wanting. It is not wrong to bring in these additional understandings as long as they are acknowledged or the reasoning for constructing the diagram this way is explained.

To review the system represented in the revised influence diagram you have to remember that it's no longer a simple translation of the text. It represents my thinking about the relationships which may exist amongst the various agencies and groupings.

That thinking took shape as I was drawing the diagram because I had to answer questions like “how much influence is this likely to have on that?” and “how can I simplify all this?” and “which things are the most important?” The result is a particular view of how the system might be. I've guessed at some things and I've guessed that some are more strongly linked than others. The point I'm making is that my thinking about the system of interest and how its components may be related developed as I was drawing the diagram. I reacted to my first draft by having additional ideas about what might be going on. This is another important lesson about the purpose of drawing diagrams. Just as with speech and writing, I usually don't know exactly what I think until I've expressed it.

Now that I have identified possible lines of influence I want to extend my investigation of the article to look more specifically at the causes of failed IT projects. To do that I have drawn a multiple cause diagram to represent part of the article.

To draw the multiple cause diagram I went back to my spray diagram. Starting with the end point of ‘failed IT projects’ I looked for likely chains of cause and effect that would lead up to this end point. Because the article gives various views and is not as detailed as I would like I have had to infer some of the links. That is not wrong. I am trying to create a model of the situation based on my thinking. When I have built it I then need to test it by checking through the logic of each link and chain and also seek supporting evidence. In other words, drawing the diagram enables me to ask more focused and pertinent questions when trying to diagnose what is happening in the situation portrayed. And if I am happy with my representation then I can start to ask myself what would be the consequences of intervening here or there.

Well, looking at my multiple cause diagram and re-reading the article I am not all that happy with it. First it says nothing about how projects fail. Some are cancelled, some are late, some even seem to have teething troubles but do eventually work and so on. Second there are more human factors and more groups of people involved. Where have the government departments and agencies gone for instance? However, I was struck at the lack of an obvious link back from ‘failed IT projects’ to anybody other than management. This may just be my representation but it could be a significant reason why there have been so many disasters.

So, I went back to my pen and paper to revise this multiple cause diagram.

This revised multiple cause diagram is verging on having too many components and links for clarity. There are also too many crossed lines. I can always improve on the presentation but for now it is the improved understanding I want to concentrate on. As I noted earlier, the definition of failure is actually varied and the expectations of what IT can deliver is important. That is why I have the small vicious circle at the top of the diagram running from ‘government policy’ to ‘many people affected’ through ‘high expectations’. I also feel that I have been trying to cover all possible reasons for failure and yet some are probably specific to certain projects. The common features appear to be to do with poor project management, the level of training skills among both the software developers and the users and matching needs with the software available.

To recap, I've introduced three simple, but powerful, types of diagram for representing a system of interest: a systems map, an influence diagram and a multiple cause diagram. I have also explained some of my thinking when I drew them. I hope that you have gained some valuable insights from this into how diagrams can be an essential tool in the system practitioner’s toolkit.

End transcript: A deep dive into diagramming

Download

A deep dive into diagramming