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.