Business course

T306

MANAGING COMPLEXITY: A systems approach

Block 2 Managing and learning with Information Systems

Prepared for the course team by Simon Bell and Jake Chapman with case study material by David Bicknell, Helga Drummond, Trevor Livesy, Peter Rawlins and John Robson

Copyright # 1.1

SUP 80180 8The Open University2005

First published 2000. Second edition 2004

Copyright #

All rights reserved. No part of this publication may be reproduced, stored in a retrieval

Edited, designed and typeset by The Open University

2 Block 2

2005 The Open University

system, transmitted or utilised in any form or by any means, electronic, mechanical,

1.1

SUP 80180 8

photocopying, recording or otherwise .

This edition produced for use by the Arab Open University.

Contents

Block 2 aims 5

Part 1 Introducing Information Systems 9

1 Introduction 9 1.1 The authors 12

1.2 The learning cycle and Block 2 13

1.3 Structure of Block 2 14

1.4 Structure of Part 1 17

2 What is an Information System? 17 2.1 The Financial Technical Services case study 20

2.2 A brief history of Information Systems 23

2.3 Summary of Section 2 26

3 What is Information? 27 3.1 What is data? 32

3.2 Information in context 36

3.3 Summary of Section 3 38

4 The systemic learning cycle: being, engaging, contextualizing, managing 39 4.1 Learning from mistakes 40

4.2 Can an Information System learn? 42

4.3 Your learning process 45

4.4 The systemic learning cycle as a method 46

5 Reflecting on learning in Part 1 46

Part 2 Using the hard systems method for managing Information Systems on the Taurus project 49

1 Approaches to managing Information System projects 49 1.1 Criticisms of hard systems thinking and practice 53

2 Stage 1 of the systemic learning cycle: being systemically aware of the Taurus project 56 2.1 The Taurus project: sources of information 57

2.2 Studying the Taurus project case study materials 58

3 Stage 2 of the systemic learning cycle: engaging with the Taurus project through the hard systems method 61 3.1 Overview of the hard systems method 62

3.2 The stages in the hard systems method 66

4 Stage 3 of the systemic learning cycle: contextualizing your approach to the Taurus project through a consultant’s use of the hard systems method 72 4.1 Consultant’s terms of reference 72

4.2 Consultant’s report on the Taurus project by Trevor Livesey 73

Contents, Aims, Learning outcomes 3

5 Stage 4 of the systemic learning cycle: managing the complexity of the Taurus project with the hard systems method 88

6 Conclusions on the hard systems method for the Taurus project 89

7 Summary 90

Part 3 Using the soft systems method for managing Information Systems on the Taurus project 91

1 The need to consider soft issues in Information System projects 91 1.1 The reasoning behind soft systems thinking and practice 93

2 Stage 1 of the systemic learning cycle: being systemically aware of the Taurus project 95

3 Stage 2 of the systemic learning cycle: engaging with the Taurus project through the soft systems method 95 3.1 Overview of the soft systems method 97

3.2 The stages in the soft systems method 99

3.3 Criticisms of the soft systems method 113

4 Stage 3 of the systemic learning cycle: contextualizing your approach to the Taurus project through a consultant’s use of the soft systems method 115 4.1 Consultant’s terms of reference 116

4.2 Consultant’s report on the Taurus project by John Robson 117

5 Stage 4 of the systemic learning cycle: managing the complexity of the Taurus project with the soft systems method 126

6 Conclusions on the use of the soft systems method for the Taurus project 128

7 Summary 129

Part 4 Reflections on Block 2 131

1 Introduction 131

2 The story so far 131

3 Logical frameworks: a systematic and systemic reflection 134 3.1 Reflecting on Taurus 136

3.2 Reflection upon the HS-method and the SS-method 145

4 A systemic reflection on Block 2: experiencing and observing again 150

SAQ answers and comments 152

Appendixes

Appendix A Glossary 176

References 181

Acknowledgements 183

Course Team 184

4 Block 2

Aims The aims of this block are to:

1 Introduce the Information Systems (IS) domain in systemic terms.

2 Develop your use of systems forms of investigation in and beyond the IS domain.

3 Enable you to make use of your previous learning in the IS domain.

4 Provide two case studies for you to develop your learning.

5 Introduce you to three different methods of analysis within the IS domain which have wider value in situations of complexity

Learning outcomes At the end of this block you should be able to:

^ Investigate complex domains using soft and hard systems approaches.

^ Compare and contrast hard and soft approaches.

^ Apply a logical framework to your project plan.

^ Make use of systems diagramming and modelling skills in the IS domain.

Part 1

At the end of this part you should be able to:

Distinguish, provide definitions of and recognize true and false uses of the following terms: information, data, capta, knowledge, Information Technology, Information System, data structure (Activities 1, 3 and 6; SAQs 7, 9 and 10)

Give examples of technical and organizational issues in the IS domain (Activities 2, 6 and 11; SAQ 3)

Distinguish between the use of the word system to describe collections of entities ‘out there’ (in the real world) and as a device for clarifying thinking about issues (Activities 4, 5 and 8; SAQ 2)

Describe the main stages of development in IS (Activities 9 and 10; SAQ 8).

Explain why only human beings can convert data to information (Activities 9 and 10; SAQ 8)

Give examples of the subjective component of data (SAQs 4 and 8)

Recognize ways in which different perspectives, investments or states of being can significantly affect the information extracted from a given set of data (Activities 12 and 13; SAQs 1, 4 and 5)

Explain, in a few sentences, why blame inhibits the constructive completion of learning cycles (Activity 15; SAQ 13)

Apply learning cycles, as a method, to IS case studies (Activity 14; SAQs 13 and 14)

Describe two or three sources of complexity in the IS domain (Activities 11 and 16)

Use diagramming tools to represent issues in IS case studies (SAQ 5)

Contents, Aims, Learning outcomes 5

Explain, in a few sentences, why technology can constrain the completion of learning cycles in the commissioning and development of Information Systems (Activities 16 and 17)

Provide examples of your own learning as a result of reflecting on your experience (Activities 18 and 19)

Part 2

At the end of this part you should be able to:

Briefly describe the style and nature of methods used to plan and analyse IS projects

Describe and explain the main stages of the hard systems method (Activities 21, 22 and 23; SAQ 28)

Use the hard systems method as one approach to analysing a case study (Activity 20; SAQ 29)

Outline the main strengths and weaknesses of the hard systems method (SAQ 24)

Relate the stages of the hard systems method to the learning cycle (SAQs 23 and 25)

Reflect critically and systemically on the use of hard systems method for analysing complex situations (SAQ 16)

Distinguish between the use of hard systems thinking and practice as a method and a methodology (SAQs 15 and 26, 27)

Part 3

At the end of this part you should be able to:

Briefly describe the reasons for considering soft issues when planning and analysing IS projects (Activities 24 and 25; SAQ 32)

Describe and explain the main stages of the soft systems method (Activities 26 and 27; SAQ 31)

Use the soft systems method as one approach to analysing a case study (SAQs 36 and 37)

Outline the main strengths and weaknesses of the soft systems method (Activity 27)

Relate the stages of the soft systems method to the learning cycle (SAQ 33)

Reflect critically and systemically on the use of soft systems method for analysing complex situations (SAQs 30, 31 and 36)

Distinguish between the use of soft systems thinking and practice as a method and a methodology (SAQ 30 and 34)

Part 4

Restate the key features of the hard and soft systems methods (SAQs 42, 43, 45, 46, 47 and 48)

Construct a logical framework as a technique for analysing projects (SAQ 49)

6 Block 2

Compare and contrast the hard and soft systems methods using logical frameworks (Activity 28; SAQ 49)

Explain further the distinctions between systemic and systematic (SAQs 38, 40, 41 and 44)

Reflect further on your own learning and practice (SAQ 39)

Contents, Aims, Learning outcomes 7

8 Block 2

Part 1 Introducing Information Systems

1 Introduction Information Systems (IS) can be understood in a range of different ways, they can be considered as a range of different things and they have a history of providing a range of different problems. Managing IS is seen by many – as this block will demonstrate – as managing a complexity. Block 2 investigates and explores the Information Systems domain. It also introduces some systems approaches and provides systemic means to manage the complexity.

Here at the very beginning it is useful to spell out some conventions to try and avoid confusion later. Throughout this block ‘System’ with a capital indicates the use of the term to name a collection of computers, software and other technology that is widely regarded as comprising an Information System. The word system, with a lower case ‘s’, refers to the ‘system of interest’ of a systems practitioner. Under some circumstances these two uses of the word may coincide, that is the system of interest may consist of exactly the same components as those included in the System. It is, nevertheless, useful to retain this distinction.

In this first part of the block IS are reviewed in terms of what people say they are (and thus what people say information is), their history, what they do and the ways in which they are planned. We will start with a brief look at some examples of Information Systems – some of which may be familiar, either from your own experience or from news stories.

A modern personal computer is a remarkably reliable device. It can store and process millions of words, figures, even pictures, extremely quickly and faultlessly. The computer system is not just 99% reliable – which would mean that one in every 100 keystrokes would put the wrong character on the screen – its reliability is indistinguishable from 100%. This technological achievement is in sharp contrast to the notorious failure rate in the large Information Systems in which these computers are embedded. As any regular reader of the computer press can attest it seems that not a week goes by without another large scale failure. Boxes 1 to 4 give some of the headline stories that serve to illustrate the scope of the problem.

Box 1 British Gas consumers turn heat up over bills

British Gas’s hastily built £150m billing system plunged the company into an ever-deepening crisis last week as the Gas Consumers Council demanded action from industry watchdog Ofgas. The council called in Ofgas after it emerged that 100 people were sent letters saying they each owed £10.7m. Up to 1,000 others received letters from debt collectors and disconnection notices.

British Gas risks accusations of incompetence, stated council chairman Ian Powe, because it has admitted putting a prototype system into production before it was fully tested. Complaints about British Gas have doubled over the past six months.

Two weeks ago Computer Weekly reported how British Gas Trading’s new national billing system failed to send bills to 12,000 customers then followed up with 12,000 final demands.

1 Introduction 9

British Gas was forced to draft an extra 2,400 people in to cope with hundreds of irate callers who were jamming its phone lines. British Gas revealed it has been forced to replace its entire communications network, at a cost of £6m, and double the capacity of its mainframe. ‘We needed more processing space than we thought,’ said a British Gas spokesman.

(Computer Weekly, 17 October 1996)

Box 2 £2.6bn DSS system fails to hit targets

The Department of Social Security’s quest to save 20,000 jobs as a result of Europe’s biggest civil computerization project has ended with the department increasing the number of its staff. Computer Weekly has also learnt that the department, having already gone 250% over budget with the project, is planning to spend a further £750m to integrate systems to provide a ‘one- stop shop’ for benefit claims – although this was one of the key aims of the original project.

(Computer Weekly, 28 March 1996)

Box 3 The Tiptree company

The Tiptree company was justifiably proud of its reputation. In 1992, it had won the British Book Awards distributor of the year, the greatest achievement in its 27 year history. But getting to the top is one thing. Staying there can be harder. So Tiptree decided to buy a £1.5 million warehousing system to handle greater volumes and speed up delivery of books to its thousands of bookshops, the library suppliers and other literary outlets.

But teething troubles with the new systems set off a chain reaction of unpredictable events that led to the company losing at least one of its biggest customers and facing large claims for compensation. Staff worked treble shifts to clear a backlog of deliveries, though the problems lasted for nearly six months. And this was supposed to have been a state-of-the-art system.

This is a little unfair. The technology itself behaved almost impeccably – and that was the problem. It was utterly unforgiving of human fallibility ... When a pallet was retrieved that was not the one picked by the computer, the system’s electronic map of the location of books was wrong.

(Collins and Bicknell, 1997, p. 101)

Box 4 Scottish Power bags the wrong customers

More than 1,000 British Gas Trading customers in Kent and Sussex were transferred to a competitor, Scottish Power, because of a bug in deregulation IT systems and human error. The problem led to Scottish Power taking down its systems for two days to identify the cause of the defect.

Consumers knew nothing of the problems until they received a courtesy letter from British Gas thanking them for their custom and expressing regret over their decision to switch supplier.

The mistake occurred after Scottish Power’s computers sought to identify which households were leaving British Gas by tracing their meter number, known as the ‘M’ number. Although the systems correctly located the right street, they sometimes picked the wrong house numbers.

Up to 1,000 gas consumers who requested a transfer were left as British Gas customers and 1,000 who had not asked for a switch were transferred to Scottish Power. Scottish Power, which prides itself on its modern IT systems, said: ‘We’re admitting it was us. We’re determined to get to the bottom of what caused the problem.’

(Computer Weekly, 3 April 1997)

10 Block 2 Part 1 Introducing Information Systems

These are not exceptional stories. Computer Weekly is the UK’s largest computer newspaper and is widely read by computer professionals. Its executive editor, Tony Collins, and US editor, David Bicknell, have written a book on the subject. They note that ‘There is scarcely an industrialized country that has not seen its businesses seriously damaged by computer disasters. More than 60% of new computer projects fail’. They go on to say

Any regular reader of the computing trade press, and increasingly the front pages of the national newspapers, could be forgiven for believing that computer managers are either genetically disposed to failure, or that common sense flies out of the window as soon as big money is allocated to a major information technology project.

This may seem an overly harsh impression. Not all computing projects fail – only most of them. Now and again serendipity sees a company or a government department buying and implementing a system that does as much as half of what was originally intended.

(Collins and Bicknell, 1997, p. 13)

One of the suggestions in their book is that disasters could have been avoided:

if the costs of the new system had been calculated meticulously and then multiplied by three. Seasoned project managers will say this advice is nonsense – that to multiply a project’s cost by three will render the system uneconomic and kill it before it is born. Our response would be ‘Fine – so kill it. Isn’t it better to anticipate the real costs than to learn of them only when millions have been spent?’

(Collins and Bicknell, 1997)

You have already encountered two examples of serious failures in Block 1. At the end of the CSA case study there was reference to the fact that the failure of the CSA’s Information Systems more than wiped out all the savings it had made in the first three years of its life. Later reference was made to the failure of a new system introduced to the London Ambulance Service in 1992. This failure jeopardized people’s lives because the new system failed to respond quickly and in some cases even lost the details of 999 calls.

So what is going on? Computers are becoming cheaper and cheaper, but projects regularly run over budget. Businesses are encouraged to ‘computerize’ to gain efficiency – and then struggle to cope with customer queries and book orders. Some commentators see the problem as being driven by the technology – participants become so absorbed by what the technology can do that they forget the business or administrative reasons for using the computer. Suppliers see the problem in terms of inadequate specifications – they deliver what was requested by the client, only to be told that it was not what was wanted. From the client’s perspective the delays, cost escalations and failure to deliver the necessary performance are all evidence of incompetence by those designing and delivering the system.

1 Introduction 11

ACTIVITY 1

What is your position regarding Information Systems?

Record your reactions to the issues raised about Information Systems failures in your Learning Album. You should include your personal reactions and perspectives and any stakeholding you might have in the general area of ‘Information Systems’. Are you comfortable working with computers? What explanations would you offer for the sorts of failures described above? Do you have any strong emotional reactions to any of the stories of failures? Have you been involved in any yourself, either developing a system or being a user of a system?

ACTIVITY 2

Recall a failure in your life and your reactions to it

Most people do not find it easy to admit or dwell on areas where, in their own estimation, they have failed – so this may not be an easy activity to complete. I urge you to do so since it will enable you to engage more deeply with much of the material that follows. The failure does not have to be especially large or dramatic and it can be in any area of your life. Once you have identified it notice your reactions, emotional, mental and physical. What, if anything did you learn from the failure? Did you make use of any conscious learning process? Make notes in your Learning Album.

1.1 The authors

Having recorded your own perspectives on the Information System domain it is time for us (as authors) to introduce ourselves and declare our interests and perspectives – and the meanings behind the icons that represent our ‘voices’ in the text.

Very briefly let me introduce myself as the main author of Block 2. My name is Simon and I come to this course as both an academic interested in systems thinking, complexity, management and information systems and also as a practitioner – making use of systems approaches in professional practice. At the time of writing I am working on an IS development project in China. Picking up on the Juggler metaphor used in Block 1, I am interested in the ways in which I can be a practitioner in the context of the IS domain. This is the real world situation in which I have found myself engaged and I think there are many managing issues, which arise here. For me, this block represents both an opportunity to develop my thinking about systems and IS and also as a learning experience. I would describe my experience as a voyage of discovery – for me it is this sense of discovery, which is exciting.

The ‘Eye of Horus’ – which I chose as an icon symbolizes systems and holistic thinking – it is an ancient symbol of life, intelligence, mystery and emergence via renewal. I have always liked the Horus myths in Egyptian history – there seem to be endless insights contained in them – and the symbol appears to me to be both aesthetically pleasing and evocative of ancient truth.

The ‘Risen sun’ – the icon chosen for Jake – is also an ancient symbol linked to renewal and life. The symbol is mythic (myth being interpreted here in its first meaning as a hidden truth rather than a false idea) establishing light as both the physical medium of sight but also the light of the mind – truth. To me the symbol is evocative of emergence, sight, vision and clarity.

Learning Album

Learning Album

Simon writes ...

12 Block 2 Part 1 Introducing Information Systems

My name is Jake and I have been involved in writing course materials at the OU since 1970, so I am an old hand. My interest in computers started when I moved to the Systems department in 1980. I quickly became an enthusiast and was one of the team that introduced computing to Technology courses in the mid 1980s. Over the last 20 years I have started and managed a business based upon the development of software for evaluating energy use in homes. The software is sold to customers, such as architects and builders, and used in consultancy work. I retired 5 years ago as Managing Director of the business; it is now a thriving concern with 30 staff and a national reputation in the area of energy conservation. I have very strong commitments to personal growth, which requires a continued process of self-inspection and reflection, and to approaching issues systemically in which the views of all participants are taken into account.

Since I, Jake, am the main author of Part 1 of Block 2 I thought I would share with you my initial reactions to the Information Systems failures set out above. Like most people I had read stories of the catastrophic failures of some computer systems, but I was genuinely shocked when I discovered the scale of the problem. When I was researching material I logged onto the Computer Weekly website (http://www.computerweekly.com) and used the site’s search engine to look at projects for the National Health Service (NHS), Department of Social Security (DSS) and so on. I was stunned by the number and frequency of the disasters being reported. Since then I have also read a lot of books and papers analysing the causes of the failures – and it quickly becomes obvious that there is no simple explanation. In my time of writing programs and selling them to customers I have had my fair share of embarrassing moments and learned to never ever under-estimate how difficult it is to develop reliable software. I have also learned that there is no such thing as software free of bugs (errors in software that cause it to malfunction in some sense). All I now expect is that the bugs are sufficiently few and minor and obscure that they will not impair my customers’ satisfaction – and like most successful software companies we have achieved that objective. So I have a high level of involvement and investment in this area, but not in the large-scale systems that attract the headlines and cause such massive cost overruns.

One thing has become clear to me in all my reading is that there is not much learning taking place – neither by the purchasers of these large computer systems nor their suppliers. This is a theme to which I will return later. For now complete the following SAQ and then read my answer – which is at the end of Block 2.

SAQ 1

Speculate on the reasons why there may not be learning about how to avoid failure by either the purchasers or suppliers of large Information Systems. Make notes of the factors you consider may be most important.

1.2 The learning cycle and Block 2

Before going on to look at the structure of the block it is useful to look briefly at the conceptual framework within which it was written. As noted in Block 1 experience and learning from experience is a major theme running throughout this course. Block 1 also briefly introduced David

Jake writes ...

Simon writes ...

1 Introduction 13

Kolb’s model of experiential learning. The major benefit of Kolb’s approach is the way in which all elements of life are brought together in the experience – providing a holistic or systemic context in which to think.

As with all good ideas, Kolb’s original notion has been adopted (and adapted) by numerous academics and practitioners – you may notice some differences in the way it is described and used in Block 1 and Block 2. There are however a number of key phases to the fourfold cycle which are common to almost all the approaches derived from Kolb’s model. These are shown on the left in the following list. Descriptions of their basic meanings are given on the right:

^ Experiencing the world – being systemically aware.

^ Reflecting on the experience – engaging with the complexity.

^ Abstracting the experience – conceptualizing the approach. Thinking about new systems of interest and changes that might be made. This can also be described as ‘deciding’ or ‘identifying’.

^ Experimenting with or modelling the new system (or acting) – managing the complexity.

The last of these phases, experimenting with the new system, can lead to another pass through the cycle as one experiences the new system, and so on.

You might have recognized the terms on the right. They are the four ‘balls’ of systemic practice that are juggled in Block 1. The terms appear in the titles of the sections for this block and they will appear frequently in Block 3.

The main adaptation to Kolb’s cycle for this block is that it is no longer closed but with act following act the learning cycle is now an element of a learning spiral.

Throughout Block 2 this learning cycle is used as the basic framework for working through examples of the various elements of IS. Representations of the spiral appear in the margin as you work through this block to help you place where you are in the cycle.

1.3 Structure of Block 2

There is a lot to study and digest in this block, so I’ll start by describing how the material is organized and what the main aims are of the parts. The significance of some of the aims and the organization of the block will not make full sense until you have read right through to the end. My aim is to provide you with a map and some signposts now so that you do not get lost in the detail later.

First I should explain that within the framework of the learning cycle much of this block is going to be structured around case studies. Ideally I would have liked to have you make use of whatever involvement or experience you have with Information Systems in your life. In practice this would be so variable from one student to the next that I could not find a way to base the material on your own personal experience. So I have had to create the contexts in which the main analysis and discussions will take place. However if you are engaged with Information Systems in your everyday life then I urge you to use this in your learning over the next few weeks. Activities that will prompt you as to how to do this are included throughout the block. If you do not have a personal experience on which to base responses to these activities then you should reflect on the material in the different case studies.

Jake writes ...

14 Block 2 Part 1 Introducing Information Systems

There are five weeks allocated to this block. I recommend that you allocate one week for each of the four parts and the final week for the TMA. The volume of reading is greatest in Part 2, where the main case study is introduced, and least in Part 4.

Briefly the contents of the four parts of Block 2 are as follows:

Part 1 Introducing Information Systems

This starts with a critical examination of what is popularly meant by an ‘Information System’ and how this is related to the ‘systems of interest’ introduced in Block 1. This leads naturally to a detailed look at exactly what is meant by ‘information’, and some of the issues underlying the failures start to come into focus. There is also an explicit discussion of how to consider the process of learning in this domain. Along the way you’ll also be introduced to the history and quite a lot of the terminology of Information Systems.

Part 2 Using the hard systems method for managing Information Systems on the Taurus project

The first section in this part of the block introduces the main case study (Taurus); it is used in all the remaining parts of Block 2 and Block 3 and may also form part of the TMA. The case involves the development of an IS for managing transactions in the London Stock Exchange. Like other Information Systems, this can be seen formally, quantitatively and systematically as an entity to be planned to do a highly specific job. The hard systems method is applied to the case study to illustrate both the insights that can be gained in its use and to illustrate how it can be used by a systems practitioner.

Part 3 Using the soft systems method for managing Information Systems on the Taurus project

It has long been recognized that many of the problems and challenges within the Information Systems domain are informal and qualitative in character. In Part 3 a soft systems method is applied in order to provide a different perspective upon the Taurus case study introduced in Part 2.

Part 4 Reflections on Block 2

The case study and the soft and hard explorations of it are reviewed making use of the logical framework approach. This provides a valuable way of looking back over Block 2 as well as introducing a tool that you may find very useful in your own project work.

The overall structure of Block 2 is set out in Figure 1. Take a close look at Figure 1 now. You can see that I have represented each part of the block by a learning cycle, a spiral of experience, reflection, decision and experimentation that generates new experience. As Simon mentioned earlier, throughout Block 2 we will be making use of these four cycles as a map to describe where you are in the overall process of the learning which the block involves. I will return to the learning cycle in more detail in Section 3 of this part. Block 2 is an integral whole and to gain the learning outcomes you will need to read and work on the whole block – each part builds upon the last – in the same way that this block builds upon Block 1.

Block 2 does not set out to teach you about the computer technology (hardware and software) employed in Information Systems. Particular

1 Introduction 15

examples or cases may refer to specific pieces of hardware or software, but you do not have to remember these or their significance. In order that the details of the technology should not obscure the issues for you a glossary of technical terms has been provided in Appendix A. Inevitably, if you are not familiar with computers you might find it a little difficult to engage with some of this material – but don’t worry. In writing this block Simon and I have done our best to minimize this potential problem.

The Activities at the beginning of this section asked you to record your observations in your Learning Album. Subsequent Activities don’t ask you to do so explicitly but I strongly recommend that you record all your thoughts, reflections and reactions in your Learning Album – not least because several of the later Activities refer back to earlier ones. This is especially important given the aims and learning outcomes concerned with learning cycles.

There are also several SAQs used throughout the text. If you like to skim read a text before embarking on detailed study then skip the SAQs in your first read through. However when you are studying the material in detail the SAQs are essential. Some are testing your comprehension, others invite you to extend or apply the concepts. In the latter case detailed answers are provided at the end of the block where you can compare your answer with

Learning cycle 2. Introduction to the Taurus case study and the HSM approach to understanding it. Review of the HSM consultants report in terms of systems ideas

Learning cycle 3. SSM approach to Taurus. Review of the SSM consultants report in terms of systems ideas

Learning cycle 4. A review of the learning process using Logical Frameworks and SSM

Aims of PART 1 Introduce the IS domain Provide you with the means to understand the nature of complexity in this domain Enable you to develop your capacity to explore the various elements of the domain

Aims of PART 2 Provide a case study for you to engage with Introduce the HSM as a systemic form of enquiry in IS Provide you with the opportunity to review a consultants use of HSM Enable you to reflect upon the HSM process systemically

Aims of PART 3 Introduce the SSM as a systemic form of enquiry Provide you with the opportunity to review a consultants use of SSM Enable you to reflect upon the SSM process systemically

Aims of PART 4 Provide you with opportunities to analyse the case study and the two systemic explorations Develop the use of Logical Frameworks as a means to develop comparative understanding of IS projects Introduce the use of reflection in IS projects

Learning cycle 1. Introduction to the block, learning cycles, Information Systems, theories of intervention, SSM and HSM

Figure 1 An overview of the block relating each part to a pass through a learning cycle

16 Block 2 Part 1 Introducing Information Systems

mine or Simon’s. Please note that, in the cases of SAQs extending or applying the concepts, our answers are not necessarily more ‘correct’ than yours. They are provided simply to give you an idea of the sort of response that is expected. In some cases the answers to SAQs contain new teaching material.

Finally you should consider making use of the T306 computer conferences as an aid to study, especially for those items that you find puzzling or difficult. Other people’s perspectives on problems or concepts can often be invaluable, leading to new insights or deeper understanding.

1.4 Structure of Part 1

To complete this Introduction I want to provide you with a little more detail of what comes next in this part of the block. In Section 2 the term ‘Information Systems’ will be examined in detail. This will include a review of the epistemological position set out in Block 1 and taking care about the use of the word ‘system’. I’ll also introduce the first short case study and a brief history of Information Systems.

The critical analysis of Information Systems leads naturally to the main topic of this part of the block, namely what is meant by information. This is a word widely used in everyday speech and in several different technical senses. As you’ll see in that section, some of the problems with Information Systems lie in the difficulties of pinning down exactly what is meant by ‘information’.

Section 3 returns to the issue of learning cycles. I’ll discuss these at three different levels, all of which shed some light on your learning process in this block – or I least I hope they do!

Section 4 is concerned with a longer case study that I will use to draw together the main ideas of the block. This will also give you an opportunity to practise your own skills at engaging with a case study in the IS domain.

2 What is an Information System? One of the things that struck me when I was reading material on Information Systems was the implicit assumption that the concept itself was not problematic. In articles in academic journals, reports in the computing press and stories in newspapers this assumption was common throughout. Perhaps it is only people who write or read courses on systems that are alerted to the fact that what different authors mean by Information Systems might be different!

ACTIVITY 3

What does an Information System mean to you?

Start by noting what the phrase means to you without too much reflection. One of the most influential teachers I had, whilst carrying out PhD research in Physics at the Cavendish Laboratory in Cambridge, said that until you could explain a concept to an 8-year old child you had not yet understood it thoroughly. I have often found this a useful gauge by which to evaluate both my own and other people’s understanding. Imagine then that an 8-year-old child has asked you ‘what is an Information System?’ How would you respond?

Jake writes ...

Learning Album

2 What is an Information System? 17

Look back at the extracts from press reports in Boxes 1 to 4 at the beginning of Section 1. What definitions of Information System are implicit in what was written there? Are there any differences from your own conception of what an Information System is?

If an 8-year-old were to ask me what an Information System was I would offer an answer along the following lines.

It consists of a number of computers, connected together, often by telephone lines, in such a way as to assemble information, usually in the form of numbers, and make it available to different people. Data, in the form of numbers or words, is usually entered by one group of people, sometimes data is automatically collected by things such as checkout tills at supermarkets. Once data has been entered it is stored and organized so that other people can look at it in different ways using their computers.

I think this is more or less consistent with the general use of the phrase, though you may have come up with something more succinct or with a slightly different emphasis. The key parts of an adequate explanation are:

^ the combination of computer and communication technology;

^ the entry or collection of data of some kind which is stored and manipulated;

^ making the stored data available to users.

ACTIVITY 4

How would you distinguish Information Technology from Information Systems?

Start by constructing a simple explanation of what Information Technology (IT) or Information and Communication Technology (ICT; this term is often used interchangeably with IT) means to you. Then contrast this with your own explanation of Information Systems (IS). Is there any difference? If so what is it?

For many people there is no difference between IS and IT. This is not necessarily incorrect; it is simply reflecting the fact that people use these phrases in significantly different ways. When I make a distinction between the terms it is one of emphasis more than content. For me IT is focusing more on the hardware, the actual computers, printers, network cables and modems, and the software used within the hardware, operating systems, databases, communication programs, spreadsheets and so on. An Information System is focusing on the use of these components to provide some sort of information service, so using the phrase ‘Information System’ includes data entry, storage and presentation to end users. In practice almost all Information Technology is used in an Information System and certainly all Information Systems involve the use of Information Technology.

The Oxford Dictionary of Computing (Illingworth, 1986) describes Information System as:

A computer-based system with the defining characteristic that it provides information to users in one or more organizations. Information systems are thus distinguished from, for example, real- time control systems, message switching systems, software engineering environments, or personal computing systems.

Learning Album

Information System

18 Block 2 Part 1 Introducing Information Systems

My co-author, Simon Bell, took a slightly different approach and came up with the following:

An Information System is a thing, a noun, but a noun with a process or verb attached. An Information System is the means whereby structure and process is provided to information, so information is given a sender and a receiver – this relationship is very important – and a range of technologies arise in the interface between them. I usually assume that IT is an element of IS. Information Technology relates to the vast range of hardware and software which performs the functions of conducting signals from sender to receiver. These technologies are not really of primary interest to this block, although their interface with organizations and processes is the basis for much of the analysis which will be undertaken here.

It is easy for people such as Simon and me to state that the details of the technology used, the hardware and software, are not of primary interest because we are already completely familiar with them. But if you do not regularly use IT and even find the technology intimidating, then the details of the technology can be a serious issue. As I mentioned earlier a glossary of technical terms is included at the end of the block to assist with this.

An interesting example of technological awareness arose when I was researching the failure of the London Ambulance Service. It turns out that the Information System delivered to the Service did work. But what happened was that over a few days the System would become increasingly sluggish until eventually it seized up altogether. After a restart it would then work for a few days and get slower and slower – and seize up again. There were two contributory factors to this behaviour.

All computers run software in memory (also known as RAM). In a large IS there are usually lots of parts of the software which take their turn in either collecting, transmitting, processing, storing or displaying data. Each piece of software will use memory for holding the data it is manipulating. The first factor causing trouble was that one small part of the software was taking some computer memory each time it was used, but not releasing that memory when it had finished its task. Each time this part of the software was used a new part of the memory was taken and not given up. Over time more and more memory was tied up by this process, leaving the rest of the software less memory to operate with. Software with inadequate memory will run slower and slower.

The second factor was that the IS was written in an early version of a development language known as Visual Basic (VB). Now VB is a very useful tool for quickly developing screen layouts and obtaining reactions from end users. It is not so useful as an implementation tool because it runs very slowly. Anyone who has programmed in VB and used other development tools will be horrified that a time critical system such as an Ambulance Service IS was delivered written in VB.

A suitable metaphor would be the use of a milk float as the front line ambulance service! Milk floats are reliable transportation vehicles, but they have a top speed of about 10 mph. They are quiet and provide a smooth ride – but they are not a suitable means to take people to hospital in an emergency! Similarly VB is an excellent development tool and very widely used for prototyping all sorts of Information System to obtain user feedback at an early stage – but it is the last tool to use for a time critical

2 What is an Information System? 19

application such as routing of ambulances following 999 calls. Before leaving this topic I should say that recently VB has been considerably enhanced as a development tool and whilst still not delivering the fast response of other tools, now provides adequate service in all but the most time critical situations.

As I stated earlier the important thing is not the hardware and software used in Information Systems but the relationships of those engaged in the design, operation and use of Information Systems. In particular why, as noted by Tony Collins and David Bicknell in their book, are 60% of them regarded as failures?

ACTIVITY 5

Describe an Information System with which you are involved

It is extremely likely that you interact with one or more Information Systems in your daily life. They are found in the workplace, at the local library, the supermarket, or if you telephone for quotes for insurance or travel tickets. Consider an IS you are familiar with and describe it as far as you are able and construct a systems map of it. Also record the degree to which you feel familiar with or intimidated by, the technology involved. To what degree do you understand how the IS works? As a user or client are you frustrated by a lack of understanding? What is your pet hate about the IS you have described?

You may have noticed that whenever I have referred to an Information System I have retained capital letters for both words. This is because I now wish to embark on a more detailed examination of the meaning of these words and relate them to the ways in which information and systems are used in systems work. Before reading further complete the following SAQ and read my answer.

SAQ 2

Does the use of the word ‘system’ in the phrase ‘Information System’ correspond to its use in Block 1? If so explain the similarity; if not explain the difference.

2.1 The Financial Technical Services case study

In Section 1 I pointed out that more than 60% of Information Systems were regarded by those who purchased them as failures. So more than half of all Information Systems never reach the stage of being used. Clearly something is going wrong in the design and commissioning stage of these Information Systems. For this reason it is useful to extend our view of Information Systems to include their design and commissioning. The following short case study provides a useful starting point.

In Box 5 Sue Brown, an IS consultant, relates her experience of an IS project in which she was consulted by a company called Financial Technical Services. Remember if you come across technical words that are unfamiliar look them up in the glossary (Appendix A).

Learning Album

T552

Jake writes ...

20 Block 2 Part 1 Introducing Information Systems

Box 5 Sue’s story ...

The organization I was working with as an independent consultant was fairly specialist – an insurance business called Financial Technical Services (FTS) dealing in a highly specialized area. They take on the insurance for oil tankers and the like, sometimes just insuring parts of a voyage or organizing groups of insurance brokers who would cover an entire voyage. It is a high risk, high profit business which depends upon fantastic communications and high speed processing. The Directors are not mugs either. They had invested over the years in all kinds of IT based systems and generally they have been successful. Their problem was that they had never stored all the information on each insurance case in a consistent and accountable manner. The firm of accountants working for the FTS was worried about the company’s tax situation because of this poor accounting. My job was to set out a proposal for the development of a new Information System which was to be focused on a database holding all the historical information relating to individual insurance cases or projects as well as current information. The database had to hold all the basic information about each insurance case, date, time, client, nature of the insurance cover, other brokers involved if any, etc. It also had to be capable of providing data for further analysis if necessary. For example it should allow the users of the system to investigate various alternative paths to handling and costing each case as well as making aggregated analysis of quarterly/annual business.

I set about designing the system. I did not use any specific approach or methodology but I applied a quick approach which I have often applied before in my practice. It involved finding out what was needed by the client, considering if what they set out was logical, assessing the options and developing an overall plan.

So, first I spent a lot of time (in terms of the time available to me), several days, talking to the brokers working for the company and interviewing the Directors about their needs. The idea of a potential IS started to shape up. One problem I had was the legacy of the existing IT based processes already in use. The company worked almost entirely with standard software packages linked to a central database. The computers were all networked but the networking itself did not allow multiple users to all have access to one database at the same time. I knew that the incoming IS would need to be linked to international IS on the Internet and that it would need to allow several users – maybe as many as 10 at a time – to use the database at the same time. The specification for a workable system began to build up and so did the perceived complexity. Should I work with existing, well-known technologies, buy in some custom software or develop a new IS just for these clients? There were some options. The only existing IS I could buy for the client was related to a package called Sun Accounts but this would need considerable remodelling and I wondered if it might be cheaper just to develop a new IS from scratch. It is hard to assess the cost of editing existing IS over the costs of developing new IS altogether. I initially thought I might be able to adapt an IS to work with Microsoft Excel spreadsheet (the main software in use at the time) but decided that this just could not provide enough flexibility and would not give the users information in a manner which would be meaningful to them.

So the plan as finally presented was a new IS, designed in Visual Basic to hold the information, linked with the Internet and capable of downloading modelling information into Excel as users demanded. I planned the IS development in a project manner, with several steps, allowing the client to evaluate each step. Dates for certain amounts of work to be completed were specified against given percentages of the overall spend. I also provided clauses for them to call the contract off if they thought the costs or schedules were slipping too much at each point. I wanted to be sure that the information provided by the IS would be useful and that the IS would progress and adapt as the client inevitably developed their view of what they wanted. Finally I went to the Directors with my plan.

2 What is an Information System? 21

They thought about it but rejected it. I was paid for my feasibility work but I lost the contract. I subsequently found that I had lost out to a large computer company based in the city. They had heard through the grapevine about the job and were big suppliers of Sun Accounts software. Rather than coming and talking to the client as I had done they arranged for a presentation and wowed the Directors into signing on the dotted line within a week with a very compelling performance. It seemed to me that they just said the Directors could have whatever data in whatever format they asked for without any kind of analysis. Essentially they convinced the client with their portfolio of powerful clients, good presentation, confidence and complete authority.

The funny thing was that unlike my gradual, modest IS with lots of get-out clauses and evaluation points, the system they opted for, when I last heard was twice over budget, well over schedule and had not provided any of the information that the client originally requested. Just another disappointing IS project!

(Adapted by Simon Bell from notes taken in his interview with Sue Brown)

The account set out in Box 5 provides lots of examples of the complexities and management problems which are so often represented in the press and the media for those involved in the IS domain. Not only are the data and Information Systems complex – being full of numeric and or factual detail and technological variables (Internet, databases and so on) – but the people management side of the domain is also highly problematic. In the account Sue describes what appears to be a sensible approach with plenty of consultation with the client and a gradual, modest System being suggested. But the clients do not eventually choose this process, rather they are impressed by a flamboyant and authoritative approach suggested by a large firm of experts with a known product for sale. It appears that FTS would rather hand over the task and the responsibility to someone else or another agency which appeared to be willing to manage the complexity and associated problems away for them. Unfortunately this was shown subsequently not to work.

SAQ 3

Produce a rich picture of the case set out above in order to develop your understanding of what Sue is saying. Take about 20 minutes on this. When you have completed the diagram take a look at the example I have set out at the back of this block. You might like to compare your ideas to those of your colleagues on the computer conference.

SAQ 4

Consider the different perspectives of Sue, the Board of Directors and the city company who won the contract. In what ways do they differ? What are the differences in their purposes and engagements with the situation?

SAQ 5

Draw a systems map of the FTS Information System from:

(a) the director’s perspective;

(b) Sue’s perspective.

22 Block 2 Part 1 Introducing Information Systems

2.2 A brief history of Information Systems

In keeping with the approach recommended in Block 1 we will now turn our attention to the history of Information Systems. The history may help you to position different perspectives on IS as well as providing a framework for considering the interaction between the technologies used and the social structures and organizational frameworks in which they were employed.

One authoritative view is provided by Elias Awad, in his formative book on the development of IS as management tools (management information systems or MIS). Awad suggests five major epochs or periods of technological change (1998, pp. 11–12) which have occurred within the IS domain. Each period is related to changes in technology and changes in thinking and approaches to technology.

Epoch 1. The early days which Awad labels as a period of isolated computing. In this period (the early 1960s) the hardware of the computer system was all important. The computer was a clever device which clever people like scientists made use of to develop large and powerful computer applications for science and commerce. In assessing this epoch in terms of its main features, assumptions and applications the outline is as follows:

Features: Mainframe computers are the only technology available – these are few and far between and occupy entire floors of large office buildings.

Assumptions:Computers are for experts, ordinary people cannot use computers. Computer experts engineer the uses of IT and they are generally remote from the needs and physical locations of potential users.

Applications: The main applications running on computers are data- focused, payroll type functions and large-scale scientific data analysis.

Epoch 2. Awad describes this as the period of consolidated computing. This period (in the early to mid 1970s) is exemplified largely by a surge in the functions of which a computer is capable (a feature which is now a constant of all computer epochs) and a high demand for computer programmers. This corresponds to a migration of developmental interest from the scientist and hardware to the programmer and software.

Features: Mainframe computers still predominate but the ironically labelled ‘mini’ computers are of growing importance. Computer technology now occupies large rooms rather than entire floors of buildings.

Assumptions: Users are still not central to the IS; the focus for IS is now the control code which drives its functionality. No attempt was made here to produce a user-friendly interface (i.e. the use of the IS was not intuitive, the user had to have specific, often written instructions on how to use it).

Applications: Still very heavy on data processing – for example, typical applications include general ledger and inventory control. A specific example is processing the assignments of thousands of Open University students.

Epoch 3. At this time it is widely recognized that Systems designed by remote experts rather than the professionals working inside businesses generally result in dissatisfaction. This recognition seems to have been the key event which led to the third epoch of management controls and restraints. This is the period (in the late 1970s) when the enforcement of standards by managers began to improve the ease with which systems could be used directly by users without specialist intervention.

Simon writes ...

2 What is an Information System? 23

Features: Mainframe, mini and elementary micro computers. Micro computers were often disliked and referred to as a ‘blip’ by the computer experts at this time – they were often not regarded as being ‘serious computing’.

Assumptions: Managers now manage the IT/IS function. This has led to the situation where computer experts are ‘in house’ and under management control, in order to make effective changes for the organization.

Applications: With the beginning of crude user interfaces, the period was the first where the needs and ambitions of users begin to be the most important force in the development and consolidation of IS at all levels. This is a period in which IS begins to mature as a serious domain. However, it is questionable whether the information and system were yet seen as being as important as the technology.

Epoch 4. The approach evident in epoch 3 still does not allow easy access to computer power. The further development of micro computers ushered in the (much celebrated) rising role of the user in the early to mid 1980s – focusing on applications software, distributed computing to remote offices and IT applications being generated and applied far from the computer laboratory.

Features: Networks of micro computers usually run by mini computers.

Assumptions: The expert is increasingly seen as the facilitator of user needs. Organizational management increasingly recognizes that there is need for strict control of the computer function if the user is to be able to work effectively with and through the technology.

Applications: There is another surge in development of applications, software packages and networks of computers running linked databases. But – is the IS focused on providing meaningful information or data?

Epoch 5. In the late 1980s, following the trend above the industry focused more on the user/machine interface. The advent of genuine graphic user interfaces such as that developed by the Xerox corporation at Palo Alto Research Park, later adopted by Apple Corporation and then taken up and made popular to the mass market by Microsoft with Windows. The endeavour was to make users and computers more equal in the struggle of communication. The keynote for this process have been the development of what some have called (and others fiercely contested) user friendly approaches.

Features: Desk based personal computers (PCs) are the basis for most office systems – both stand alone and networked.

Assumptions: Technology should be as invisible as possible as should be the experts (the rise of telephone help-lines). Computers are as useful as users can make them.

Applications: Accountancy and other specialized functions but this period is best known as seeing the rise of the ‘big three’ – word-processing, database and spreadsheet software and the ease with which data can be moved between them.

Awad refers to MIS across this period but, before going on I want to think of IS in the late 1990s and bring the chronology up to the millennium. To this end I offer the following sixth epoch.

Epoch 6. The passing of remoteness. In the period of the 1990s the connectivity of computers has taken on an entirely new appearance with

24 Block 2 Part 1 Introducing Information Systems

computers being equipped with modem capacity and linkage to the World Wide Web (WWW). Through the Web individuals with computers can gain access to a wide range of sites for commercial, educational and recreational uses. Corporations are ‘going global’ taking advantage of the 24 hours a day productivity available. Related to the development of the mega-corporation is the development of global brands (e.g. in soft drinks, burgers and jeans). There is also the less savoury side of the WWW – it provides access to the pornographic, the degrading and the unethical. Software has become more enabling, particularly multimedia authoring and groupware (software aimed at allowing groups to work together at distance – for example the FirstClass software used by the Open University throughout the 1990s). The connectivity of the Internet linked to the software available has meant that the focus remains on the user and issues of the nature and form of the interface between person and technology and person and person via the technology is becoming critical. Data is also growing in importance. The newspapers now regularly include features on ‘information overload’ as professionals in all walks of life struggle to keep on top of the growing mountain of data and information.

Features: The networked, multimedia PC and the rise and rise of the Microsoft Windows interface and the Intel chip (known as WINTEL).

Assumptions: We are all users and information consumers. Information is the biggest global business – Castells (1996) calls this the ‘Rise of the Network Society’.

Applications: Computer conferencing, integrated ‘office’ suites of software, electronic mail, the blending of computer, telephone and TV technologies.

The history of Information Systems has been represented by numerous other authors but another useful and complementary diagrammatic representation has been set out by Ward (Ward et al., 1990). Ward identifies three eras of IT/IS development as shown in the Figure 2.

1970s 1980s 1990s

data processing

management information systems

IS/IT developments

strategic information systems

business opportunities

Figure 2 Three eras of IS/IT development

2 What is an Information System? 25

ACTIVITY 6

Map the six epochs onto Ward’s three. How does the decision making intrinsic to the different tasks involved in data management, management information systems and strategic information systems set out in Ward’s approach relate to the forms of technology and the assumptions set out in that of Awad? What do the six epochs mean for you in terms of your experience of IS?

The historical development of computing and Information Systems has, associated with it, a change in the mindset or perspectives of the main stakeholders. I can illustrate this with a description of the mind sets characteristic of the first and sixth epochs.

Epoch 1 mindset: The computer expert is the centre of the System. The computer expert is given the necessary support to indicate priorities and to control the process of providing automated procedures to alleviate problems. The user is peripheral to the needs of the data processing department and generates problems for the computer expert to solve.

Epoch 6 mindset: The user is said to be the centre of the System. The user is given the necessary support to indicate priorities and to begin to decide on what information (and therefore what data) is needed by whom and to do what. The computer expert is a ‘technologist’ and as such is peripheral to the user’s problem solving and acts as counsel and support to the user.

SAQ 6

Assume that the six epochs can be characterized as follows.

1 Mainframe hardware focus.

2 Programmer focus.

3 Management control focus.

4 User focus.

5 Interface focus.

6 Global focus.

(a) Which epoch most adequately describes your experience of the Open University in terms of its attitude to IT and IS?

(b) Which epoch do you think would be most appropriate for your needs?

(c) Which epoch assumptions do you think Sue Brown was working most closely with?

ACTIVITY 7

To which epoch would you assign the IS you described in Activity 5?

Use all the characteristics of each epoch in making your assignment. You may find that the IS with which you are engaged has characteristics of more than one epoch. What does this tell you about the classification into epochs?

2.3 Summary of Section 2

In this section we have examined what is meant by an Information System and distinguished it from Information Technology and ‘systems of interest’ (as defined in Block 1).

Learning Album

Learning Album

26 Block 2 Part 1 Introducing Information Systems

Information Technology is taken to be the hardware and software characteristically used in Information Systems, whereas Information Systems themselves also include the processes of data entry or capture, the processing and communication of the data and its presentation to a spectrum of end users in a suitable format.

‘Systems of interest’ are the conceptual entities created by systems practitioners to aid engaging with complexity. In some circumstances the ‘system of interest’ may exactly coincide with the Information System, nevertheless the distinction between the two terms should be retained.

The FTS case study, dealing with the design and commissioning of an IS, was introduced and used for some preliminary exercises.

Finally the historical development of Information Systems was described and related to different perspectives and mindsets.

3 What is Information? The previous section examined what was meant by Information Systems and unpacked some (but not all) of the confusion around the use of the word System. The aim of this section is to tackle the other word, Information. This is an altogether trickier area, as you’ll see.

ACTIVITY 8

How would you explain to an 8-year old what information is?

As in Activity 3, before reading further have a go at a short explanation of what information is, that could be understood by an intelligent 8-year old.

You might find it helpful to think of a specific example of something that you regard as information. What is it that makes it information to you?

The example I used was the price of HBOS shares. This is information to me because my wife and I received free shares when the Halifax Building Society converted to a bank a few years ago (this has since merged with the Bank of Scotland to form HBOS). When I thought about this I realized that although this was information to me it would not be regarded as information by most people. What made it information for me was my ‘investment’ in HBOS. So my explanation of what information is developed into ‘a communication that tells me about something in which I am interested’.

I do not claim that this is a definitive definition, but it captures the essence of being relevant to my interests. Liebenau (1990) examined a wide range of definitions or descriptions of information from a variety of places. Each of the definitions given in Box 6 is based upon a particular context, all of which use the word information regularly.

As Liebenau says himself:

These definitions are all problematic. They contradict one another and therefore we are left to choose the best definition or the best combination of definitions for our purposes.

(Liebenau, 1990, p. 3)

Jake writes ...

Learning Album

3 What is Information? 27

Box 6 Definitions and descriptions of information

Information is knowledge communicated concerning some particular fact, subject, or event.

The communication or reception of knowledge or intelligence.

Knowledge obtained from investigation, study, or instruction.

The terms ‘information’ and ‘data’ are sometimes used synonymously with ‘information,’ supplanting ‘data’ in contexts where the emphasis is on the broad, grand or useful aspects: ‘information processing,’ ‘information network,’ ‘information interchange’.

Information is only a measure of the difficulty in transmitting the sequences (i.e. messages) produced from one source to another.

Data are language, mathematical, or other symbolic surrogates which are generally agreed upon to represent people, objects, events and concepts ... Information is the result of the modelling, formatting, organizing or converting data in a way that increases the level of knowledge for its recipients.

The distillation of data through its being processed results in the creation of information.

The meaning of information is precisely the reduction in uncertainty.

Information is a pattern or design that rearranges data for instrumental purposes.

Information is data recorded, classified, organized, related or interpreted within context to convey meaning.

Information is the reduction of uncertainty. In information theory, one ‘bit’ of information is the amount required to allow one to choose between two alternatives.

(Liebenau, 1990, p. 2)

This is clearly an unsatisfactory position. It may also be unnecessary since, if my earlier observation about personal relevance is correct, the situation may become more amenable to understanding if we adopt a different epistemological position. As a starting point you should read the extract from Information, Systems and Information Systems – Making Sense of the Field (Checkland and Holwell, 1998) in Box 7.

Box 7 Data, capta, information and knowledge

Making sense of the field of IS requires a very clear concept of what ‘information’ is, but given the present confused state of the field it is perhaps not surprising that there is at present no well-defined definition of such terms as ‘data’ and ‘information’ upon which there is general agreement. It is noteworthy that a current encyclopaedia of software engineering (Morris and Tamm, 1993) contains no entries for either ‘data’ or ‘information’. Indeed one entry asserts that

Computer programming is concerned with the processing of information or data. (present authors, emphasis added). (page 87)

If there were general agreement on the meaning of ‘data, and ‘information’, the terms could be taken as given. Without such agreement, some analysis is necessary.

Anderton (1991) gives some useful examples which illustrate that there are subtleties associated with the idea of information and its communication to others.

28 Block 2 Part 1 Introducing Information Systems

(a) A motorist is travelling at 30 km/hr. The speedometer indicates 30 km/hr. Does the motorist have information about his speed? Apparently, yes. But actually the mechanism is stuck and although the indication happens to be correct, the driver receives no information.

(b) A traveller plans to fly to another country but can do so only if she is free from smallpox. She has some medical tests in the afternoon and arranges with her doctor that if the results are positive the airport desk will be called before 5pm. At 5pm she checks with the desk and finds that no message has been received. She thus receives the information that she is free of smallpox. Yet no physical event has occurred: nothing, apparently, has carried the information.

(c) A newspaper arrives at a football supporter’s house. In it he reads the score: England 1 Italy 2. The supporter has the information that Italy has won the game. Five minutes later a friend arrives with a Xerox copy of the newspaper report. The supporter receives no information about the game; he knew the result already. His brother, incidentally, who has not seen the newspaper, receives the information from the Xerox that England played Italy yesterday, a fact he had not previously known. (page 57)

To these instructive cameos we may add a further real but somewhat bizarre example.

At a conference held at Edinburgh University, one of the authors of this book occupied a room in the Pollack Halls of Residence. From the room there was a good view of some of the rock faces known as Salisbury Crags in Holyrood Park. These have attracted rock climbers for many years, and details of 20 climbs here were published as long ago as 1896. It was therefore amusing to read in the present rock climbing guide, which describes 50 climbs in detail, that

at present climbing on any cliff in the park is strictly illegal and anyone caught doing so is likely to be prosecuted. The route descriptions in this section of the guide are reproduced purely for their historical interest ...

Now, to any red-blooded climber the message conveyed is perfectly clear, though it is not what the words say. To a rock climber, the guidebook is saying: here are descriptions of some good climbs, go and enjoy them, but be discrete, keep a low profile, and have a good story ready! In other words the information the guidebook conveys is virtually the opposite of what the text actually says! Clearly, creating and conveying information is not a simple business.

We need to find an account of ‘data’, ‘information’ and the relation between them which will make sense of examples such as these. This will need a careful use of language beyond that in normal everyday conversation. And the exploration should not start from the words themselves, such as ‘data’ and ‘information’, asking: what do they mean? Rather, we should take Popper’s advice (1972):

One should never quarrel about words, and never get involved in questions of terminology ... What we are really interested in, our real problems, ... are problems of theories and their truth. (page 310)

Popper suggests that if you find yourself arguing about the meaning of words, always a fruitless exercise, the thing to do is to accept your opponent’s definitions and get down to arguing about the real problem! Here the problem is to develop at least a skeleton theory of what distinctions it is useful to make in order to understand the business of arriving at ‘knowledge’, the theory including an account of what the process is which leads us to make use of the words which mark the distinctions, such words as ‘data,’, ‘information’ and ‘knowledge’. In the words of Winograd and Flores (1986): ‘As observers we generate distinctions in a consensual domain’ (page 50), that is to say, a cognitive domain in which knowledge can be shared. Let us see what distinctions it may be useful to make in order to understand IS.

3 What is Information? 29

From data to capta

We can start by accepting the obvious: that there are myriad facts about the world. It is fact that the authors of this book were born in Birmingham, England and Melbourne, Australia, and that they are both, at the time of writing, working at Lancaster University. Such facts are in principle checkable; if disputed, evidence can be produced to support or refute them. There is a plethora of such facts, some agreed by all, some disputed, some accepted as meaningful by all, some private to an individual or group who defines them as a result of particular interests. Consider an example of this latter category. There must in principle exist the following fact: the number of octogenarian widows living alone in Wigan. This is a meaningful concept, though it may be the case that no one has ever ascertained the actual number of such widows. Most people would not want to know this fact anyway; but it could be a significant fact to which attention is paid by a researcher examining the operation of geriatric support services in Wigan.

This suggests that there is a distinction to be made between the great mass of facts and the sub-set of them which we select for attention, those to which we pay heed. The obvious word for the mass of facts is ‘data’, from the Latin dare, meaning ‘to give’. But there is no ready-made word for the small fraction of the available data which we know about or pay attention to, or create. At Lancaster during the action research programme which has seen the development of SSM [soft systems methodology], we have found it useful in discussion to refer specifically to that data which we have decided is relevant and which we therefore know we want to collect. We refer to such data as ‘capta’, from the Latin capere, meaning ‘to take’ (Checkland 1982) and that is the word we shall use here.

Data are a starting point in our mental processing. Capta are the result of selecting some for attention, or creating some new category – such as ‘the number of octogenarian widows living alone in Wigan’ in the example above – or being so surprised by some items of data which pass across our gaze that we begin to pay them attention. In the first of the earlier examples from Anderton, (a) above, the position of the speedometer needle at 30 km/hr is an item of data; it becomes part of the driver’s capta when he pays attention to it – though that example also reminds us that we may need to check that the apparent facts of the situation are what they seem to be.

Turning data into capta is a very familiar mental process, so familiar in fact that it has become completely transparent to us: we do it all the time without noticing the process occurring, which is presumably why we have here found it necessary to make up the word ‘capta’. Also, it is by no means the end of our mental processing.

From capta to information and knowledge

Having selected, paid attention to, or created some data, thereby turning it into capta, we enrich it. We relate it to other things, we put it in context, we see it as a part of a larger whole which causes it to gain in significance (Holwell 1989). The phrase which best captures this is probably ‘meaning attribution’. The attribution of meaning in context converts capta into something different, for which another word is appropriate: the word ‘information’ will serve here, this definition being close to the way the word is often used in everyday language.

This process, which can be both individual and/or collective, by which data is selected and converted into meaningful information, can itself lead to larger structures of related information for which another word is needed; we may use the word ‘knowledge’. Such structures of information may be expected to have greater longevity than many items of information which are only ephemerally meaningful and relevant. For example, at a particular point in time in a home furnishing company, managers might select as capta, from all their sales data, the figures concerning the sales of a new expensive kitchen chair, aggregated separately for each sales area over the last three months. In the context of introducing this new product, these capta would yield information concerning, for example, the readiness of people in different geographical areas, classified socio-economically, to buy a basic but expensive product. This would itself contribute to updating the company’s larger-scale slower-moving knowledge of the home furnishing market.

30 Block 2 Part 1 Introducing Information Systems

The process by which data are turned into knowledge is shown in Figure [3]. It is suggested that in this process it is useful to mark or highlight three distinctions created by our actions of: selecting data; attributing meaning to this selected data; and building larger structures of meaningful data. And it is further suggested that we use the words data, capta, information and knowledge to describe the four products defined by making these three distinctions.

cognitive (appreciative)

settings context, interests

facts

selected or

createdfacts meaningful

facts

larger longer- living structures

of meaningful facts

suitable words: DATA CAPTA INFORMATION KNOWLEDGE

Figure 3 The links between data, capta, information and knowledge (Checkland and Holwell, 1998)

The scheme of Figure [3] allows us to make sense of Anderton’s intriguing examples quoted above. The first one (in which the speedometer is stuck) reminds us that apparent facts are not necessarily true: there is in principle a need to have available processes by means of which we can try to check the accuracy of data. In the second example, (b) above, the absence of any message conveys information to the traveller, so that nothing, apparently, has carried the information. This emphasizes the importance of context in acquiring information from data. The arrangement made by the traveller with the doctor establishes a context in which the absence of any message before 5pm itself conveys meaningful information. In the third example the existence of the match and the final score are part of the football supporter’s capta, and he will no doubt convert the score into information of interest to him – such as, perhaps, England’s prospects of qualifying for the World Cup. Neither the existence of the match nor the score were part of his brother’s capta. The score tells the brother who won the match but also that the match itself had taken place, a new item of capta for him. Of course, if he is not interested in football he will not attribute the same meaning to it as his football-follower brother, so meaning attribution may be personal or shared.

This illustrates a very important point. The analysis has led us to use the word ‘information’ to describe ‘capta’ (itself selected ‘data’ which gets our attention) to which meaning has been attributed in a context which may be any or all of cognitive, spatial and temporal.

In the final example above, in which the anonymous writer of the rock climbing guide to Salisbury Crags manages to convey a message which is virtually the complete opposite of what the words say, we have a very subtle situation. It is another example of the important part which context plays in creating information. Many people glancing at the guide would of course accept at face value the statement about the illegality of climbing in Holyrood Park. But the writer, being embedded in the culture of rock climbing, knows its knowledge base, its attitudes and its values. He knows that fellow climbers will get the message; what is more, if challenged at the crag he or she will no doubt adopt an air of injured innocence! This example is the equivalent on paper of situations familiar enough in everyday life: situations in which information (in the full sense of the word) can be passed between knowing members of a particular culture by no more than a tone of voice, the gesture of a hand or a wink.

The most important feature of this analysis of data, capta, information and knowledge is that the act of creating information is a human act, not one which a machine can accomplish. It is the human being who can attribute meaning to the selected data which has been highlighted for attention, this

3 What is Information? 31

being done in a context which may well be shared by many people but may also be unique to an individual. Of course the designer of a system which processes focused-on data (i.e. capta) into a more useful form will have the aim of making the processed capta correspond to some obvious categories of information which will be meaningful to many different people. But attributing meaning to the processed data is a human ability, and a particular attribution may be unique to one individual. No designer can guarantee that his or her intended attributions of meaning will be universally accepted. In the house furnishing example discussed above, the geographically-tabulated capta concerning the sales of the new chair in the three months after launch will yield different information to different people. The salesman will gain information about his bonus payments; the managing director will learn something relevant perhaps to the strategic future of the company; the production planner may take from it the need to recruit more process workers or obtain more raw materials for the furniture factory.

This emphasizes that the phrases in common usage, ‘information system’, or ‘management information system’, are ill-chosen. What such systems cannot do, in a strict sense, is provide unequivocal information; what they can do is process capta (selected data) into useful forms which can imply certain categories of information. They cannot, however, guarantee that the capta will be interpreted in this way by people making use of the system’s outputs. In fact the phrases in common use in the early days of computers, namely ‘data processing (DP) system’ or ‘electronic data processing (EDP) system’, were more accurate than the phrases which have unfortunately replaced them both in everyday speech and in the professional field of IS. It would be a good idea to return to the earlier language, but this is unlikely to be achieved. After all, people working in IT will probably wish the word ‘management’, as in ‘management information system’, to be associated with their activity since it implies a higher level activity and maybe better career prospects!

(Checkland and Holwell, 1998, pp. 86–92)

SAQ 7

Provide short statements of what Checkland and Holwell mean by the four key terms, data, capta, information and knowledge. To what degree do you feel that they have resolved the epistemological issues?

3.1 What is data?

Checkland and Holwell’s definitions place the realm of information in an observer-dependent light. Information will vary with the perception of the individual who is attributing the meaning. However Checkland and Holwell are willing to accept that there are unambiguous ‘facts’ or ‘data’ out there in the world and that the starting point for producing information is simply the selection of the relevant data from the mass available. I find this an oversimplification of the situation. I will illustrate it by some personal examples.

Box 8 The difficulties of selecting data

In the late 1970s I was involved in an exercise that enabled Open University students to fill in a questionnaire and subsequently receive detailed advice on how to improve the energy efficiency of their home. One of the important questions that they had to answer on the questionnaire was ‘how many windows are there in your home?’. This sounds like one of those simple bits of data that can be collected unambiguously. Examine Figure 4. How many windows are there in this illustration? Answers on the questionnaire ranged from 1 to 6. The computer program that processed the data assumed that the item illustrated in Figure 4 was a single window – so the people who responded 3 or 6 obtained some weird advice!

32 Block 2 Part 1 Introducing Information Systems

Figure 4 How many windows?

While managing a software business I was responsible for setting up a network of salespeople who would cover different areas of the country. The contract with each salesperson was that they would receive monthly commission on the sales that they had made in that month. We therefore set up a database to receive all the orders and allocate them to the relevant salesperson. We naively imagined that the number of sales was a data item that could be determined unambiguously. Nothing could be further from the truth. When exactly does a sale occur? When the salesperson thinks they have made the sale or when we receive the purchase order? Do we count all the purchase orders received from people in the salesperson’s area, or just those they have visited? And if we only include those they have visited, how recently? If they made a visit two years ago and we now receive an order should they receive commission on that sale? And what about customers who don’t pay or who send the goods back as being inappropriate? And what about national organizations where there is one purchasing office (usually in London) that deals with sales in all the regions! There are ways of resolving all these ambiguities – but only by introducing rules based upon an understanding of what is going on – and with the agreement of the sales force!

I saw a Horizon programme about the probability of a meteor or comet fragment impacting on a centre of population. Until fairly recently scientific opinion was that this was such a remote possibility that it was not worthy of investigation. A few ‘nut case enthusiasts’ set about looking for evidence of large and small-scale impacts. The startling conclusion, now agreed by the scientific community, is that the Earth is subject to several major impacts each century, and many smaller ones. The probability that a centre of population will be hit by one of these is still small, but a hell of a lot larger than previously imagined!

These examples all illustrate that what might at first seem to be ‘data’ is itself subject to significant uncertainty and a large observer-dependent component. There is a school within the philosophy of science that asserts that all data depends upon a theory which defines it as a useful data item. When you include in the collection of ‘theories’ the ways in which we conceptualize and think about the world, you can see that all data is heavily dependent upon a subjective element. What makes this hard to see is that

1 it is impossible for an individual to step outside all conceptualizations;

2 the conceptualizations and theories that define what we commonly regard as data are those that are shared within our culture.

It is only when we come up against examples of other people using a different theory or different conceptual framework that the assumptions we are making all the time about ‘data’ become even visible.

3 What is Information? 33

SAQ 8

In each of the three examples given in Box 8, identify the theoretical or conceptual assumptions that were challenged and how these changed the perception of ‘data’.

ACTIVITY 9

Identify examples of theory dependence of data in your own experience.

The way to go about this is to think about times when you have been involved in arguments with other people about something that you normally regard as data. Or maybe it was a time when you suddenly realized you were making an assumption that other people were not making. I find that good documentary programmes often have this ability – so they may be a source for you to examine.

Once you have identified your own example, articulate what the conceptualization or theory was that was determining your assumptions regarding some ‘data’.

It has become clear to me that there are no ‘theory independent’ data. All data or facts depend upon a prior conceptual or theoretical framework to be intelligible. This does not mean that the data or facts are in some sense arbitrary. You cannot have a theory of gravity that says planets repel one another because it would be inconsistent with observations of the motions of the things called planets. However the way that one makes observations about planets, or anything else, has to be determined by a theoretical framework that makes assumptions about the nature of reality. What is remarkable is that there exist conceptual frameworks that are as successful as the ones which have enabled technology to develop to the point where we regularly look at pictures of what is happening on the other side of the world, are able to fly there within a day and can send people who live there e-mails which arrive shortly after being sent! But the success of these technologies should not lull you into the belief that either the theories or the facts are in some sense absolutely true. History teaches us again and again that conceptual frameworks can be successful – and also fundamentally flawed.

In addition to the theory dependence of data there is an issue involving personal perspectives and investments that affects ‘data’. In the previous examples the issue as to what was and was not a sale, was extremely important to the salespeople involved in the project. It was not a matter of academic debate; their pay depended upon the outcome. Under such circumstances individuals can suffer severe ‘factual distortion’. Most people experience this when they become emotionally engaged with a situation or person. There are aphorisms that acknowledge these distortions; seeing those you love through rose coloured spectacles, or those you hate as incapable of any good. These are all examples of bias, the colouration of facts and data to suit a particular orientation or perspective on the world.

It is surprisingly difficult to avoid bias. One of the reasons for stressing that you should include your position whenever you use systems thinking is to make your own possible bias clear to yourself and others. I am most suspicious when an individual claims to being ‘completely objective’ in their assessment of a situation. I do not believe it is possible to be

Learning Album

34 Block 2 Part 1 Introducing Information Systems

completely objective, and anyone claiming such a position strikes me as either totally unaware of their own bias or trying to conceal it – neither of which provides me with confidence in their assessment.

So where have we got to in terms of understanding information? It seems to me that the distinctions drawn by Checkland and Holwell are valid and that their conceptual framework assists in examining Information Systems. In order to include the subjective element of data it is necessary to include something on the underlying conceptual frameworks involved. Here is my attempt at this:

Data are distinctions or facts based upon a conceptual or theoretical framework that is widely shared within a culture.

Capta are a subset of data deemed to be of interest to a specified group of individuals who share the same theoretical and conceptual frameworks for these items and also have some interest in them.

Information describes the way in which the content of the capta (i.e. selected data) affects the shared conceptualization of the world.

SAQ 9

Using the above classification scheme ascribe the following descriptions to one of the three categories. Where possible identify the shared conceptual or theoretical framework:

(a) The HBOS share price has increased today: communicated to an HBOS shareholder.

(b) You scored a grade 1 on your last TMA: communicated to you and me.

(c) It is raining outside: communicated to a passenger on Concorde.

(d) I owe Barclaycard £451.79: communicated to an Amazonian tribesman.

SAQ 10

Reread the FTS case study in Box 5 using these distinctions about data and information.

(a) Do these distinctions make any difference to your appreciation of the case?

(b) Consider the various items referred to as information. What actually are they?

(c) Does the author of the piece (Sue) use ‘information’ in more than one sense?

ACTIVITY 10

Review your understanding of what information is.

Refer back to your notes on what information is (Activity 8) and make further comments on how your understanding has changed. What are the main differences between your previous view and your current understanding? What were the main factors that influenced you to change your view on what information is?

data

capta

information

Learning Album

3 What is Information? 35

ACTIVITY 11

Identify data and information in the IS in which you are involved.

Refer to the Information System you described in Activity 5 and considered in Activity 7. What are the data for this IS? On what shared conceptualization do they depend? What is the information provided by the IS (if any)? Is there any ambiguity in the information provided by the IS? Do all clients or users of the IS interpret the outputs in the same way? If not what are the sources of the different interpretations?

3.2 Information in context

So far I think I have established two core ideas. The first is that data depends upon a prior theory or conceptualization of the world. Provided the theory or conceptual framework is shared with others then the data will appear as being ‘given’ and ‘objective’. The second core idea is that information is data that has been selected and given meaning by interested recipients. This was a central argument in the Checkland and Holwell extract; machines and computers can only reproduce data, only human beings can impart that data with meaning and thereby create ‘information’. The same extract emphasizes the role of context in the way that a person extracts or obtains information from the data. This is the aspect I wish to explore further now.

In order to achieve this I am going to change the context of the material you are reading. I could develop an example of people in a business meeting, each with their own context, being given the same data and deriving quite different information from that data. But that would make it hard to distinguish for the issues of personal bias and shared conceptualizations already discussed. So I am going to use a Sufi story to illustrate the role of context. I would like you to note your own reactions as you tackle this material.

First let me say a little about the Sufis by way of introducing the context of the story itself. The Sufis are a widespread group of people who follow a spiritual tradition that is not part of any religious system. They have practices that provide them with experiences of other realms but are not part of any formal organization and there is no requirement on them to believe in some theology. Thus some Sufis will refer to God as an explanation of their experiences, others will refer to Allah, and others to Spirit. The emphasis in their system is on personal experience, not on dogma or belief.

The Sufis have existed throughout Europe and Asia for thousands of years. They have been persecuted by all the religious systems, especially the various versions of Christian and Moslem religions. In order to protect themselves from persecution, and to keep their knowledge available but not obvious, they developed a tradition of story telling. The stories are usually funny; this helps the listener to remember the details of the story. However the stories also have several different levels of ‘hidden’ or ‘esoteric’ meaning. In order for a novice in Sufi studies to comprehend the hidden levels of a story he or she would need to have had a certain level of personal experience. So the context in which the information becomes available to the listener is the listener’s own experience – of spirit and their own psychology.

Here is the story. It has been brought up to date, but retains the multi- layer meaning:

Learning Album

36 Block 2 Part 1 Introducing Information Systems

Two gentlemen of unsteady gait waited impatiently at the bus terminal late at night, long after the buses had ceased to ply. A couple of hours passed before they realized, in their drunken stupor, that the last bus had gone. Seeing several buses parked in the depot, they decided to borrow one and drive themselves home.

To their disappointment, they couldn’t find the bus they wanted. ‘Can you believe it’, said one, ‘A hundred buses and not a single number 36 in the whole lot!’

‘Never mind’ said the other. ‘Lets take a 22 up to its last stop and walk the rest of the two miles home.’

(de Mello, 1989, p. 93)

Clearly this is a memorable funny story. I have heard it, indeed told it, dozens of times and I still laugh every time I hear it. It has that quality of good jokes – it touches on the absurd in a comic and unexpected way. So that is the first level of meaning.

What do you think is the second level meaning?

Well the second, hidden, level of meaning is about the significance of contexts, in particular the way that preconceptions limit our ability to perceive things clearly. The two men in the story are stuck in the notion that only a bus displaying a specific number can follow a specified route. But this is simply an absurd version of the ways in which we are all stuck in our assumptions and contexts. The scientists who discounted the possibility of meteor strikes were sufficiently stuck in that view to not see the evidence of previous strikes. Our theories and conceptualizations of the world severely condition our ability to see things ‘as they are’. So you can see why I selected this story – the first hidden layer of meaning is exactly the context dependence of information.

By the way the personal experience that is required in order to be able to immediately see this meaning is to have seen through the limitations of one’s own personal history. This is accomplished in the Sufi tradition by a combination of exercises, including meditation, self observation and being confronted by one’s teacher(s).

There is another layer of meaning beneath this. Reflect on the story for a moment to see whether you can see what it is.

The third level of meaning relates to the inebriated state of the old gentlemen. Clearly within the story the men are intoxicated with alcohol; that is what is clouding their judgement. In everyday life people are intoxicated with desires, and this intoxication colours their judgements in an even more profound fashion. These are not necessarily urgent desires associated with lust or greed, but are the everyday desires to stay alive and be well regarded by others. If you were to notice what you are thinking whilst you act during the day you would find, like everyone else who has persisted at the exercise, that a very large part of your mental activity and subsequent actions are taken up with these desires – or the avoidance of the associated fears (the fears of death and rejection). There is nothing wrong with this, it is just that by being so preoccupied we are unable to perceive the world clearly. There is a persistent context driving a great deal of the ‘information’ we perceive in life – and most people are completely unaware that this is the case.

3 What is Information? 37

The personal experiences that are necessary for someone to immediately perceive this level of meaning in the story are associated with overcoming the fear of death and rejection. This requires the person to experience beyond any doubt that they are not simply a body.

Most Sufi stories are said to have four levels of meaning. I do not have the ability to perceive a fourth level of meaning to convey to you! But I trust that what this Sufi story has conveyed to you is the significance of one’s own personal contexts in being able to perceive information. This is the main reason why self reflection and awareness were emphasized as an important component in ‘being’ a systems practitioner in Block 1. The Sufis take the process of self awareness much much further, and by so doing become aware of more subtle contexts and meanings. As a result they are able to exercise more choice in leading their lives – this is why they often describe their practices and system as one of ‘self liberation’.

ACTIVITY 12

Summarize your epistemological position regarding information

With reference to your earlier work in Activities 10 and 11, start by writing your own version of the main ideas introduced earlier as statements of what data and information are. Then reflect on your experience with the Sufi story. How has this modified your understanding about information?

ACTIVITY 13

Identify your own context in the IS in which you are involved

Refer to the Information System you described in Activity 5 and considered in Activities 7 and 11. What is your own personal context in relationship to this IS? What are the contexts of other participants in the System? To what degree do they share your context?

SAQ 11

Identify Sue Brown’s main context in the FTS case study. How does your explicit awareness of this context colour your perception of the case study i.e. how does it change the meaning that you extract from the data represented by her account of the case?

3.3 Summary of Section 3

This section has examined the concepts of data, information and knowledge in some detail. The words are widely used to represent a range of different ‘things’ and ‘ideas’.

The extract from Checkland and Holwell demonstrated that

1 information arose in a wide variety of contexts, some of which appeared paradoxical;

2 information consists of data that is meaningful to a particular human being in a particular context;

3 only human beings can invest data with meaning;

4 knowledge arises within an individual as data and information are integrated into longer term and larger conceptual structures.

Learning Album

Learning Album

38 Block 2 Part 1 Introducing Information Systems

The ‘objectivity’ of data assumed by Checkland and Holwell was challenged by a series of examples. The conclusions from this were

(a) all data depends upon a prior conceptual or theoretical framework;

(b) the conceptualizations and frameworks on which our perceptions of data are based are themselves very difficult to perceive because they are taken for granted;

(c) data can be regarded as facts or observations based upon a conceptual or theoretical framework that is widely shared within a culture;

(d) both data and information have a significant subjective basis.

Finally a Sufi story was used to illustrate that as well as a conceptual framework for defining data, and the personal meanings required to convert data to information, there is also a personal context that enables an individual to be aware of data/information/knowledge. That personal context is the individuals ‘beingness’ which in turn depends upon their experience and self awareness.

4 The systemic learning cycle: being, engaging, contextualizing, managing

In Section 1 we gave a brief overview of learning cycles and how they were used in Block 2. Learning cycles themselves may strike you as an odd topic to occupy a section in a block concerned with Information Systems. However by the end of this section I trust that the relevance will be clear. For starters it should be clear to you by now that this course is not simply concerned with imparting facts and ideas; its overall aim is to enhance your ability to act in the world constructively (whatever that means for you). Hence the emphasis in Block 1 of the various aspects of practice: being, engaging, contextualizing and managing. In order to achieve this action orientation it is essential that you are provided with tools, techniques and methods that enable you to make use of the knowledge you gain in your life. The learning cycle is one device for accomplishing this.

SAQ 12

Without looking back to Block 1 (or Section 1 of this part!) reconstruct the learning cycle diagram. It has four main stages, see how many of them you can recall and whether you can deduce the missing elements from your experience of the course to date.

ACTIVITY 14

Relate the learning cycle to Information Systems

Before you attempt this activity make sure that you have attempted SAQ 12 and checked your understanding with the answer. In this activity I want you to speculate, without being too rigorous, on the ways in which the learning cycle might relate to Information Systems – at least as far as we have considered them so far in this block. How would you relate it to the failures documented in Section 1? And is it relevant to the definition of System and system as discussed in Section 2? And what about the distinctions between data, capta, information and knowledge developed in Section 3?

Jake writes ...

Learning Album

4 The systemic learning cycle: being, engaging, contextualizing, managing 39

4.1 Learning from mistakes

Intellectually it is obvious that everyone learns by making mistakes. The first time you attempt to do something it will be described as ‘beginners luck’ if you accomplish it correctly. Once a person has decided that they wish to accomplish or master something then they will set about finding out how to do whatever it is. They will read about it, perhaps observe others doing it and probably receive instruction on how to do it. But up to that point it is all just words, concepts and images stored in the mind. It is not until the person acts that they will discover the significance of all those words, instructions, images and ideas. As the person attempts to do whatever they set out to do they engage in learning. They will compare their performance with what they have read or observed or been told and make adjustments. They may try to use the prompts or images employed by masters of what they are learning. They will inevitably make errors, fall over, miss notes, forget important aspects and generally fail. It is only through the failure that the person is able to assess their ability and what they have to pay attention to next. The trouble is that many people have been given rather thorough aversion therapy to deny failures and pretend that they do not happen.

This aversion therapy is applied by most cultures, but has been brought to near perfection by the materialistic culture of the West, now eagerly copied and emulated in most areas of the world. Teachers and parents reward success and castigate failure. The people who are held up as examples are those who do not fail. The role models are the champions at sport, the stars of the examination or concert halls, the people who make lots of money and live in grand houses and star in successful movies. Who wants to own to being a failure in this culture?

ACTIVITY 15

Review your own attitude(s) to failure.

Look back to the notes you made in Activity 2 which asked you to recall a failure in your own life. How difficult was it for you to recall one? What were your emotional reactions to whatever it was you described as a failure? To what degree were you willing to share and admit this failure to others?

This emphasis on the personal emotional investment in not failing is significant in the context of the continuing stream of IS failures referred to in Section 1, and which will be elaborated further as you complete this block. Put yourself in the position of the manager in a large company who has commissioned a large new Information System costing, say £1 million, and you discover that it will not do what is required. What do you do? Well first of all you get on to the suppliers and threaten them with all sorts of dire consequences if they do not deliver what you expected. For their part they are already working on their next contract, they have to in order to keep the money rolling in to pay all the expensive programmers. So the supplier claims that the terms of the contract have been fulfilled and claims that what has been delivered fulfils the specification. So what could be recognized by both parties as a failure becomes a dispute over liability and specifications. When the dispute is finally resolved or forgotten each party will go away imagining themselves the injured party and resolving to make the contract tighter or the specification better next time they are involved in such a project. Indeed IS procurement contracts are now a lot more thorough and everyone pays a lot more attention to

Learning Album

40 Block 2 Part 1 Introducing Information Systems

the specification of the System before such contracts are signed. So there appears to be some learning – but it is focused on how to make other people behave differently, it is based on a blame story in which the person themself is blameless. So the individual does not learn because they do not recognize their mistakes. Even when the disaster is repeated over and over again the parties involved continue to blame the other side and fail to learn.

There are other factors that contribute to this lack of learning in the delivery of Information Systems. One of the most significant is that it may be in the interests of all involved to keep the ‘failure’ concealed. The suppliers certainly do not want their failures publicized, they only want to call attention to their successes since this is what will attract new clients to them. The organization commissioning the System also has no interest in publicizing the failure since it will decrease confidence in the organization and its activities in the world. The cases that come to light most often are those that occur in government departments, since the affairs of these are open to public scrutiny. Banks, insurance companies, private health care companies and so on are likely to be just as vulnerable to failures in the IS domain, but would not wish these to be known since such events would seriously impair their public image.

The problem is encapsulated in a quotation from Tyrell Burgess (1979, pp. 117–157). Writing about learning and education he said it was about ‘creating contexts in which it was safe to fail’.

SAQ 13

Reflect on the arguments presented in this section. Is the problem that some part of the learning cycle is not being completed? Or does the problem lie elsewhere?

As the answer to SAQ 13 indicates, in the general domain of Information Systems all the steps of the learning cycle appear to be completed, yet the suppliers and purchasers of these Systems have yet to learn how to avoid disaster. So there is more to learning than just going through the steps of the learning cycle. Indeed it is relatively simple to complete the learning cycle and learn nothing! Here are some of the faults and traps that can occur at each stage in the cycle.

Experiencing or observing. Is the experience fully received? Are there components of what is happening that are being denied? Is the individual open to experiencing negative emotional states, such as distress? In general to what degree is the experience constrained by the individual or collective theory about what can occur?

Thinking or reflection. The way a person thinks is itself constrained by their categorization of the world (which is why systems approaches emphasize taking multiple perspectives and thinking in different ways). To what degree is the individual open to being wrong? To what degree are core beliefs constraining thinking about the experience? In the case of organizations is there a culture or prohibition on questioning certain key aspects of the collective experience?

Decision or conceptualizing. Has the reflection significantly changed anything? In cases where the individual or organization is thinking in terms of blame the only change will be a stronger commitment to that explanation of events. If a certain type of explanation is reinforced and yet

4 The systemic learning cycle: being, engaging, contextualizing, managing 41

yields the same unsatisfactory experience then something is clearly wrong – and it is usually being stuck in a blame story that does not cause any change in knowledge or decisions. Just the decision to question whether the blame story is correct is enough to open the cycle to genuine learning.

Action or intervening. Is the action, the way of intervening or engaging with the situation, any different? Even when there has been real progress in an individual’s understanding about a context there may be a fear or reluctance to act differently. If the action is unchanged then the experience of the situation is unlikely to change significantly. Some people who have understood this will sometimes act differently even when their understanding remains stuck – they know that changing how they act will cause a new experience which may well assist them to break out of their fixed perceptions, beliefs and theories. However without subsequent reflection and conceptualization the opportunity to learn will again be lost.

4.2 Can an Information System learn?

One of the observations that struck me strongly as I was reading the IS literature was ‘Computers tend to be much less flexible than the paper based systems they replace’ (Collins and Bicknell, 1997, p.16).

ACTIVITY 16

Does this observation concur with your own experience?

Reflect on the ways in which you have interacted with computers, both personally, with a computer at home, in the workplace or elsewhere and impersonally via agencies such as banks and travel agents. To what degree do you think that computers have increased or decreased flexibility?

There were two reasons why this quote stood out for me. First it corresponds very well with my experience of large scale Information Systems. Interacting with such systems, through work or dealing with large organizations, I have often been struck by the inflexibility involved. ‘We cannot do that because there isn’t an option on the system’ is an all too familiar response.

This is in sharp contrast with my experience of personal computers. For me the PC has enormously increased the flexibility of the way I work, carry out research and communicate with friends and colleagues. The area it has enhanced the most is the one I am currently engaged in, writing. I can keep dozens of documents open, move text from one to the other, change my mind, pull in an illustration, send versions to colleagues for instant comment by e-mail as well as checking my spelling and grammar and creating decent looking documents.

So why is there this discrepancy between the large and small scale computer Systems? When I thought about this it occurred to me that one possible reason was that a particular definition of information was in some sense frozen into the large scale System. This did not happen on the small scale because the use of the computer is as a tool, not as a provider of ‘information’. In many ways my use of my PC could be regarded as an Information System; I am continually entering data, organizing it in ways that are meaningful to me and extracting it later on. But it is quite different from the large scale Information Systems which are used by tens, hundreds, even thousands of users.

Learning Album

42 Block 2 Part 1 Introducing Information Systems

The Systems that are used by many users have to have defined data structures and procedures for exchanging data between different computers – without these the large Systems simply would not work at all. But as soon as decisions are made about the data items that have to be entered then other, new items, are excluded. As soon as computers are linked together so that they can exchange data items then any change on one computer has to be matched by an equivalent change on all the other computers with which it exchanges data. So once the Information System has been implemented the decisions about data structure and so on cannot easily be changed; they are effectively frozen.

4.2.1 Data structures in Information Systems

People unfamiliar with the details of computer technology are often surprised at the rigidity of these constraints. Let me give you a trivial, but illustrative, example. It is decided to create a database to store customer names and addresses. The computer has to allocate a certain amount of space to each item in the name and address. It is decided that the surname will have a space of twenty characters. This will be followed by the first address line which has a space allocated of thirty characters. These fixed allocations are used within the computer to locate the position where the surname and address items start. Also when one computer communicates to another the items in the store are simply transferred as a stream of characters – because both the sending and receiving computers use the same storage structure the data will be ‘received’ correctly.

Incidentally there is always pressure to make these space allocations as small as possible so as to conserve storage space, both within the computer’s memory and on storage devices such as disk and tape. With very large databases an extra ten characters of space associated with each name (which in almost all cases will be unused) can add 100 megabytes to the storage requirements.

Now consider how to handle the surname ‘Fortesque-Wittgenstein’ – which unfortunately has 22 characters! There are three options

1 the data is not entered;

2 the data is entered in a truncated form;

3 the data structure is revised to accommodate the longer name.

If option 3 were adopted on one computer, but not on the others, then when the data is sent from one machine to the other the last two characters of the name would actually appear in the first line of the address. Worse, this error would displace all the data from the structure in the receiving computer and produce gibberish.

If option 2 is adopted then the unlucky person receives mail addressed to ‘Fortesque-Wittgenste’ – which is not satisfactory. Now you see why the preferred response is ‘We cannot do that because there isn’t an option on the system’!

If you think this example is oversimplified then consider the extract in Box 9, which is taken from another article describing British Gas’s problems with its billing system, referred to at the very start of the block.

4 The systemic learning cycle: being, engaging, contextualizing, managing 43

Box 9 British Gas billing system

‘So what went wrong? Taylor said, when introducing a £150m tariff billing system last year, apparently minor software problems had repercussions that nobody could have predicted. The task had been to transfer the customer data from 12 regional datacentres on to one ICL IDMS [Information and Data Management System] database. That required 9.7 billion items of data to be migrated: 308 items every second of every day for two years.

The database had been designed with military rigidity. The aim was to make its structure so inflexibly efficient that all data entered on to it would meet sharply-defined criteria. This, among other things, would ensure that the information on the database could be retrieved quickly, reliably and without wasting system resources. But the design of the database proved too unyielding for the data that was transferred into it.

There were apparently minor inconsistencies, for example between the field sizes, of the old data and new databases. The result was that the system rejected some of the migrated data. And, although the number of rejections was tiny, along with other problems, they caused the system to collapse.

(Computer Weekly, 20 March 1997)

ACTIVITY 17

What aspects of data and information are frozen in the IS with which you are engaged?

This activity refers to the Information System that you identified in Activity 5 and have elaborated on in Activities 7,11 and 13. What are the constraints on the data that can be entered and extracted from the System? Are there other data items that would enhance the usefulness of the System? Is the implicit definition of data and information still appropriate?

There are many consequences that result from the necessary freezing of data structures by the requirements of the technology. First many users of the System will deduce that the System is being driven by technology rather than by their requirements – which to a degree is correct. Second the freezing of the data structure and definitions will reinforce a positivist attitude towards the world, data and information. It will encourage the view that there is a fixed world-out-there and tend to diminish the subjective and social aspects of the definition of data and information.

Third there is no simple way for the frozen data structure to be changed in the future. This is a serious liability because:

(a) it is extremely unlikely that the initial design will be ‘perfect’. One of the reasons for this is that clients of such systems are rarely able to articulate all their requirements clearly;

(b) with projects that take years to implement, the data requirements are likely to change, and thus be out of date even before the System is implemented;

(c) the introduction of the System will itself generate change within the organization, both social changes and changes in the perceived data requirements.

SAQ 14

Relate each of the items (a) to (c) above to a learning cycle linked to the Information System. What is the effect on each learning cycle of the inflexibility?

Learning Album

44 Block 2 Part 1 Introducing Information Systems

4.2.2 So can an Information System learn?

The short answer to the question raised at the beginning of this section is ‘No – but they need to’. Once an Information System has to be used by a number of users then the technology imposes a set of constraints which means that the data structures have to be fixed at a certain time. This constraint inhibits essential learning cycles associated with the specification of the System itself, the evolution of the organization’s needs over time and the changing roles of users within the organization. In a way the technology freezes a particular context, a particular definition of data and a particular form of information, all of which are liable to significant change over time and as a result of the introduction of the System itself. The example in Box 10 illustrates a number of these points.

Box 10 The ‘Millenium Bug’

The ‘Millenium Bug’ was an issue created by the inflexibility of data structures (and the unexpected longevity of some IS!). In the early days of computing the constraints imposed by the shortage of memory and storage space meant that every aspect of the program had to be optimized to use as little space as possible. In the 1950s and 60s programmers used the last two digits of the year to represent the year in the date. Thus 1st January 1958 was stored as 010158. By implication 010100 is 1st January 1900. But in 1999 it was more likely to mean 1st January 2000. The difference is merely a matter of 100 years! But this is easily enough to cause systems to malfunction in innumerable ways. So to solve the Millenium Bug programmers had to find ways of correctly interpreting dates after the end of 1999. And they were usually constrained to do so without changing the data structure, since that would involve too many other changes to the systems. One of the more popular solutions was to assume that all dates ending in 00 to 30 refer to dates after the year 2000. But of course this is no use if dealing with people born before 1930 – and in any case simply recreates the problem in another 29 years time.

4.3 Your learning process

The learning cycle was introduced in Block 1 as a vehicle for emphasizing the need for you to take responsibility for your own learning by continually reflecting on your own experience. As indicated there, and reiterated throughout the course, this reflection on experience is the basis of most systemic approaches to complex issues. This is not an accident; over the years it is what countless practitioners have found works, and it is the skill you are being encouraged to learn. And the way to learn it is by actually doing it. Don’t be put off if you don’t get things right the first time – failure can often provide a richer learning experience. It is only by doing it, sometimes with success, sometimes not, that your ability to learn in this way will be enhanced.

This puts you in a double-loop, or second-order, learning context (sometimes called Mode 2 learning). You are assimilating a method of learning at the same time as you are applying it to a specific domain. Once you are practised at the method of learning you will know how to apply it effectively – but how do you learn about a method of learning? The method is recursive – which means that it can be used on itself. So if you are improving at using the learning cycle method then you should find that you can reflect on your experience of using the method and learn how to use the method more effectively.

4 The systemic learning cycle: being, engaging, contextualizing, managing 45

ACTIVITY 18

Reflect on your experience of learning by ‘reflecting on experience’

Your learning album is a key resource in this process. I suggest that you look back over a topic that has recurred throughout this block, such as the definition of information or the reasons for IS failures, and reflect on how you now think about and conceptualize the issue. How has your thinking changed and developed? Has it been a linear process? Or can you recognize iterations where you reconceptualized as a result of new insights. Also have you made any decisions about how to approach IS case studies differently?

4.4 The systemic learning cycle as method

In Sections 4.1 and 4.2 I employed the learning cycle method in a different way. As well as encouraging you to reflect on your own learning process, I used it as a method for engaging with the issues around Information Systems. In fact I was adapting it to different facets of the issues as I perceived them, so in these examples the learning cycle was being used as a method. I did this by asking myself the questions ‘what learning is going on here?’ and ‘is there anything blocking the completion of learning cycles?’. As I think you will agree these were fruitful questions to ask and have shed considerable light on the roots of the persistent failures in the IS domain.

When I started writing this section I was unsure whether using learning cycles as an approach to issues would yield any benefits. I was therefore pleasantly surprised when it became clear to me that freezing data structures was a serious impediment to adaptation and learning in Information System design and operation. You should be willing to use learning cycles as one of the systems approaches for engaging with complex situations (especially those that involve obvious or repeated failures since it is in these cases you might expect learning is somehow being obstructed or distorted). As you will see later in the block the formal systems approaches are designed to take the practitioner through a structured learning cycle, often more than once.

5 Reflecting on learning in Part 1 In Block 2, Part 1 you have experienced what information systems are (Section 2), reflected on what they comprise (Section 3), connected and made decisions on how they can be managed and learned from (Section 4). You have therefore applied the learning cycle to the part as a whole.

By the time you reach here you will have finished your first week’s work on this block. Before reading my summary complete the following activity.

ACTIVITY 19

Note the main things you have learned in Part 1

Reflect on the material that you have read to date. Starting with the reports of disasters in Section 1, the discussion of what Information Systems are in Section 2, the debate around information and data in Section 3 and learning cycles in Section 4. What are the things that stand out for you? How have your theories and understandings of Information Systems changed over the week?

Learning Album

Simon writes ...

Jake writes ...

Learning Album

46 Block 2 Part 1 Introducing Information Systems

My expectation is that your understanding and experience of Information Systems will have been enriched by the material in this part. I deliberately chose some dramatic examples to focus on a problematic domain. Most people’s difficulties with Information Systems do not end up costing millions – but they can nevertheless be frustrating and disabling. If you have any insight into why and how this happens then you will be better able to respond to difficulties in this domain in the future.

My biggest concern is that you might be leaving this part of the block with a clear view about why things go wrong with Information Systems projects and what the solution is. It is all too easy to be misled by partial evidence, or get caught in a particular ‘solution’ view of the world that subsequently becomes part of the problem.

5 Reflecting on learning in Part 1 47

48 Block 2 Part 1 Introducing Information Systems

Part 2 Using the hard systems method for managing Information Systems on the Taurus project

1 Approaches to managing Information System projects

Having in Part 1 briefly introduced the Information Systems domain and demonstrated some of its complexities and inherent problems. This part goes on to look at approaches to managing those complexities and analysing IS failures. It goes on to introduce one such approach in more detail: the hard systems method (HS-method). This method can be used both as a systemic and systematic form of inquiry. Its use is explored through investigating the main IS case study in this block – the Taurus project. This part also provides you with the opportunity to review a consultant’s use of the HS-method and to reflect systemically upon use of the HS-method through following the learning cycle.

Part 1 has gone some way in exposing what is meant by Information Systems (IS). Before moving on to look specifically at two different systems methods for analysing IS projects (the HS-method in this part and the soft systems method in Part 3), I want to briefly review how IS projects are usually planned and developed. Remember that I am not attempting to teach the many formal approaches to IS analysis and design or how to design IS as a technical process – but I am interested in helping you understand something about the overall approaches, methodologies, methods, tools and techniques used by IS people working on IS projects. By understanding this context I hope you will be able to make more sense of the Taurus project which we will be examining later in this part and in Part 3.

To plan an IS the analyst/planner needs to face a series of choices – I show these in the hierarchical activity sequence diagram of Figure 5. At the top level I show the approach taken when planning an IS. The approach is the overall way in which the analyst undertakes the process (see Block 1 Part 3). Numerous researchers and IS practitioners have written about the approaches analysts can take to investigate an IS. Perhaps one of the best known is Robert Galliers (1992). Working from his writings it is possible to infer several approaches to developing IS, for example laboratory experiments, field experiments, surveys, forecasting, simulation, and action research (incidentally these are broad categories that apply to other projects as well as to IS ones). It is not necessary to go into any detail on each approach, suffice to say that these approaches can be:

^ more technology focused or more people focused;

^ more organization or more process focused; or

^ more quantitative or more qualitative in their application.

(These characteristics relate closely to the definition of ‘approach’ provided in Block 1, where some approaches tend towards both subjectivity and holism whereas others tend to be more narrowly defined as tending towards science and objective analysis). Furthermore some approaches,

Simon writes ...

1 Approaches to managing Information System projects 49

like action research, provide more potential for participation in the analysis and design process for local users, while others, e.g. laboratory experiments and surveys, seem more prone to an exclusively quantitative and ‘objective’ tendency on the part of the IS developer.

When a general approach has been chosen then a specific method is selected. This is at the middle level of the planning hierarchy/process. As with an approach and to some extent governed by it, a method can be focused on quantitative matters of data and facts and figures or it can be more concerned with human resource management and social matters. However a method can also be used to review and reflect upon the development and direction of an IS project, when it becomes more properly known as a methodology. So I have also included methodology alongside approach at the top of the diagram. That is not to say that everyone makes or uses such a distinction between method and methodology in practice.

SAQ 15

Before reading on, can you differentiate between method and methodology drawing upon the discussion in Block 1 and other sources?

Discussions about what are methods and what are methodologies abound in the IS literature. I think it is safe to say that most of the methodologies described revert to methods when they are applied in practice. By this I mean that although in theory each methodology can be, to some extent, self-analysing, and can be reflected upon in terms of its principles, each also tends to become a method, a set of procedures, tools and techniques when applied to the development of the IS itself. Keep these definitions in mind because generally speaking when methodology is discussed in the literature what is actually being covered is method.

What is the approach I will adopt to IS planning?

Which methodology will I use to help reflect on the methods and

techniques I use?

with the chosen approach?

Of the range available which IS method will I apply to the situation that fits in

Given my chosen approach and method, what tools and techniques will enable

me to plan effectively the IS in question?

Figure 5 An activity sequence diagram of approaches/methodologies, methods and tools/techniques for IS development

50 Block 2 Part 2 Using the hard systems method for managing Information Systems on the Taurus project

A point to keep in mind in the use of any method for IS is the time scale. It can take months to undertake a full analysis and design for an IS which is highly detailed, requires the latest technology and is designed to serve numerous clients. The situation which can then arise is that the IS is poorly planned with insufficient attention to the details which are vital for effective and efficient operation. In all IS analysis and design work there is an essential trade-off between resources (e.g. time, money) and precision (e.g. the efficiency of program code, the rapidity of calculation). But, as we shall see later in the main case study, even when there is an abundance of time and money IS projects can still be fatally flawed from the outset.

There are many books dealing with specific IS methods if you wish to know more about them. David Avison and Guy Fitzgerald (1995) describe a considerable range of methods for planning and developing IS. In a book which I co-authored with Trevor Wood-Harper (1998) we described the manner in which these many methods can be considered as a whole (see Figure 6). But there are many others you can consult.

tending to a people focus

tending to reductionist

tending to systemic

tending to a technology focus

JSD SSADM

ETHICS SSM

Multiview

YSM KADS

RAD

STRADIS OOA

Information engineering Business

Process Re-engineering

ISAC

ETHICS = Effective Technical and Human Implementation of Computer-based Systems ISAC = Information Systems work and Analysis of Change

JSD = Jackson Systems Development

KADS = Euro name for an expert system IS development method

OOA = Object Orientated Analysis

RAD = Rapid Application Development

SSADM = Structured Systems Analysis and Design Method

SSM = Soft Systems Method

STRADIS = Structured Analysis, Design and Implementation of Information Systems

YSM = Yourdon Systems Method

Figure 6 A graphical classification of IS methods based on the two axes of systemic to reductionist and people centred to technology centred (Bell and Wood-Harper, p. 229)

1 Approaches to managing Information System projects 51

The range of methods included in Figure 6 is representative of the main requirements of IS projects. IS have to deal with technical issues of data, measurement and precise software and hardware operation. For these needs the ‘hard’ approaches to the left of the diagram would seem to be most appropriate (e.g. Structured Systems Analysis and Design Method – SSADM or Object Oriented Analysis – OOA) although this tends to impose certain characteristics (see Box 11 below). But IS also need to be responsive to the dynamics of organizational change and the difficulties that are generated by office politics and personality clashes. In such contexts where these ‘soft’ features predominate, the approaches in the top right quadrant would be best (e.g. soft systems method). There has been a tendency in recent years to bring together many of the elements of soft and hard methods in multiple or ‘eclectic’ approaches. This is represented in this diagram by the Multiview approach. Multiview contains both hard and soft tools and techniques and places equal emphasis on the technology and data on the one hand and people and organizational culture on the other.

Lastly, when a specific method has been selected then the tools and techniques which are used within the overall method also need to be selected – this is the lowest level activity to be considered in the planning process/hierarchy. Such tools and techniques include:

^ diagramming types such as entity modelling and data flow diagrams;

^ a wide range of planning and design elements such as project management tools (e.g. Gantt and Pert charts), database management systems (e.g. SQL – structured query language), and project costing tools (e.g. CBA – cost benefit analysis).

Any IS project will be made up of a wide range of these tools and techniques and their application should result in a developed, scheduled plan for an IS which then needs to be purchased or built with another range of tools such as Fourth generation languages, Object Oriented Programming or Computer Aided Software Engineering (CASE). As with approaches, methodologies and methods I will only mention or introduce tools and techniques which are necessary to work through the case study effectively.

Box 11 Characteristics of hard methods used in IS projects

The main characteristics of all hard methods used in IS contexts are:

1 They all assume that there is a clearly identifiable existing system in some state or other. To discover this is essential to the process of systems analysis and design. No major problem is presented by this task; it is simply a matter of investigation and documentation.

2 There can be a clear and agreed statement of the objective of systems analysis and design. Generally, this is established in conjunction with the owners of the system. It is the role of the systems analysts and programmers to provide the IS on time and within budget.

3 It is assumed that the end result of the process of analysis will be a design that will incorporate a technological system. In other words the problem – that is, the disparity between the existing system and the desired system – is seen to be soluble by technical means. In most cases this means a computer is part of the solution to the problem.

52 Block 2 Part 2 Using the hard systems method for managing Information Systems on the Taurus project

4 Just as it is clearly possible to objectively describe the existing system, it is possible to determine if the designed system, once implemented, meets the objectives set for it. Thus there is a measure of performance.

5 The process of analysis and design needs to be carried out by experts. This follows from the general assumption that the solution to the problem will be technical. The client/expert dichotomy is essential to hard methods.

In summary, it can be said that where we are now and where we want to go can be clearly established. The problem facing the analyst is how to get there.

The solution is in terms of a linear progression from the current state to the desired state through several stages. Four distinct phases can be identified (reminiscent of the learning cycle):

(a) investigating the existing system: information gathering, problem identification, feasibility study;

(b) analysis of the existing system and the provision of a solution to the problem by designing a new system on paper;

(c) implementing the solution;

(d) evaluating its effectiveness.

Although hard methods apply to computer systems analysis and design, their scope is much larger. They are similar to a general engineering approach to problem solving. The assumptions and overall strategy is similar whether one is designing a transport network, building a bridge, running a project to put someone on the moon, or designing a computer system.

(Adapted from T843 Management Information Systems, Block 5)

1.1 Criticisms of hard systems thinking and practice

Trenchant criticisms of the philosophy and application of hard systems thinking were first made by the American sociologists Ida Hoos (1976) and Robert Lilienfeld (1978) and by Peter Checkland (1981) in the UK; they have been echoed by many others since e.g. Avison and Fitzgerald (1995).

In the IS past the traditional and formal approach to analysis and design was the Systems Development Life Cycle (SDLC) developed by numerous authors but possibly best noted are Daniels and Yeates (1971) and Lee (1979).

The SDLC methodology consisted of the following steps:

^ feasibility study;

^ systems investigation;

^ systems analysis;

^ systems design;

^ implementation;

^ review and maintenance.

This can be readily seen as a form of the ‘hard’ approach.

Avison and Fitzgerald (1995, pp. 30–31) criticize it on a number of counts which might be seen as being good for the critique of most formal and hard approaches:

^ failure to meet the needs of management;

^ unambitious systems design;

^ instability;

^ inflexibility;

1 Approaches to managing Information System projects 53

^ user dissatisfaction;

^ problems with documentation;

^ lack of control;

^ incomplete systems;

^ application backlog;

^ maintenance overload;

^ problems with the ‘ideal’ approach.

The main objections to hard systems thinking may be summarized as follows:

1 The hard methods are based on an engineering perspective which does not have universal application to all types of problem. In particular Peter Checkland has distinguished between:

(a) hard structured problems, which can be stated explicitly in a language which implies that a theory concerning their solution is available;

(b) soft unstructured problems, manifest in a feeling of unease, which cannot be stated explicitly without appearing to oversimplify the situation.

2 Hard systems methods emphasize a scientific approach to problem solving rather than intuition or experience. A high premium is placed on logic and rationality. Philosophically they assume a realist view – the world is out there independent of us; all that has to be done is to discover it and alter it to meet our needs. They assume that there is no difficulty in defining the existing and desired states of the system. When this assumption fails, they provide no help in further analysis.

3 The core of hard systems thinking is mathematical, and this:

(a) limits the problems which can be addressed using these techniques. Indeed it leads to analysts trying to fit the ‘problem’ to their favoured techniques such as linear programming, queueing theory, Monte Carlo simulation etc. rather than adapting the method and techniques to the situation;

(b) limits consideration to those elements in a problem which can be manipulated using quantitative techniques. Similarly there is an implicit assumption that quantitative information equals objectivity, whereas qualitative information equals subjectivity. Failing to appreciate that the requirement to provide quantitative information where none is accurately known often leads to unjustified assumptions being made;

(c) leads to assumptions that somehow mathematical techniques could help understand and balance all equations: human, social, economic and political within an organization. They do not pay attention to the social or organizational aspects of the situation.

4 The emphasis is always on linear problem solving. There is a problem, it is solved, the next problem arises, it is solved and so on. This leads to a reactive approach to management as opposed to an ongoing developmental approach which stresses proactive attitudes.

5 There is a dichotomy between the client and the expert which can act as a barrier. They may not share the same language, coming from different backgrounds. The expert is seen, or wants to be seen, as outside the situation looking in objectively. However, once involved the

54 Block 2 Part 2 Using the hard systems method for managing Information Systems on the Taurus project

analyst interacts within the system and brings his or her own set of experiences, knowledge, prejudices and background to bear on the situation.

6 Attempts to use hard systems analysis as an aid to public policy decision-making have failed, or even made matters worse.

These comments on hard approaches are not meant to be damning or put you off using them in the right context. Rather, they illustrate the need for caution before using a hard method. Criticisms of hard methods on the basis that they have been applied to the wrong type of problem by the wrong type of practitioner can only be answered by training more sophisticated systems practitioners, which is the aim of T306. Just as some researchers tend to see the world through the distorting lenses of their favourite modelling technique, some analysts tend to favour either a hard or a soft method and therefore to see only the hard or the soft elements in a problem or decision. On top of this, the widespread characterization of methods into hard or soft dichotomy is itself a thinking trap that can blinker the actions of all involved in a situation. It is therefore important to be aware of both the situation and yourself and others within it.

Nevertheless we are faced by the claim in Part 1 that over 60% of IS ‘fail’ to meet the specified requirements, sometimes spectacularly. It may be implied from the above discussion that hard methods, which have predominated in IS planning and development, have significantly contributed to these failures. My next task is to show how a hard method can be used sensitively, in a sophisticated and enlightened way, before looking at a soft method.

We will explore how a specific, complex example of an IS project can be analysed using both hard and soft systems methods. In terms of the juggler you met in Block 1, I want to engage with elements of the way in which you and I can experience an actual IS through a case study. It is my intention to use systems theory and practice to understand the complexity people seem to experience in an IS project, in particular a failed IS project.

Throughout the next two parts, which use two different systems methods to examine the case study, it is very important to keep in mind the following:

^ The methods described in Parts 2 and 3 are not only used for the IS domain – they are designed to deal with understanding complex issues in any domain. Remember the brief history of each from Block 1.

^ You need to consider the use of these methods with awareness of their strengths and weaknesses, to learn from your experience of them and be able to adapt them to particular contexts. In this block we are dealing with methods, but later blocks will pick up more on their use as methodologies. However, if a method is applied and learned from – for example making use of a learning cycle to reflect upon the method in question and develop it in the light of practice – then some would argue that the method has become a methodology.

^ You should think of areas from your own experience where the methods described in Parts 2 and 3 could be applied for managing complexity by tackling the activities and using the Learning Album specifically for this purpose.

^ You should begin thinking whether you wish to use one of these methods as part of your course project. You may also want to make contact with your colleagues on the T306 computer conference and

1 Approaches to managing Information System projects 55

swap notes and learning about these methods and the topics they could be applied to. Such conversations might throw up potential project choices for yourself (involving IS or not).

The rest of Part 2 is devoted to introducing the main case study (the London Stock Exchange Taurus IS project), describing the HS-method (as devised by the Open University), providing an analysis of the Taurus project using the HS-method, and then reviewing how useful such a method has been.

It is also important that the objectives of Part 1 are not forgotten at this point. In Part 1 the learning cycle was described and applied to IS in general. In Part 2 the learning cycle is also applied – or more properly, the use of the HS-method is explained in terms of the learning cycle. So I can restate what follows as a learning cycle approach to:

^ experiencing the Taurus project second hand (being);

^ reflecting upon the HS-method (engaging);

^ knowing what happened in the Taurus case study using the HS-method (contextualizing);

^ reviewing how the HS-method could have been used differently (managing).

2 Stage 1 of the systemic learning cycle: being systemically aware of the Taurus project

Having reiterated the structure and main themes of Part 2 I am now going to introduce the case study which you are going to be working with throughout the remainder of the block: the London Stock Exchange’s Taurus project.

ACTIVITY 20

Understanding the stock market

Before going any further take a little time to consider your understanding of financial markets, stock exchanges or the London Stock Exchange in particular. Set out any major questions which you might need answering before you could successfully engage with materials in this subject area, such as:

‘What is a stock market?’

‘What type of information is involved?’

‘Who uses a stock market and why?’

Do not forget these questions. Answering them is important. Otherwise you will probably not make much headway in understanding the case study until they are answered. The glossary in Appendix A contains definitions of some of the specialized stock market terms used.

In selecting a case study for T306 I had to consider a range of issues and requirements. From my perspective the study would need to:

^ be well discussed and documented with a range of opinion to draw upon;

^ be described by stakeholders and actors as exhibiting complexity;

^ contain numerous examples of IS concepts, practice and outcomes;

Learning Album

56 Block 2 Part 2 Using the hard systems method for managing Information Systems on the Taurus project

^ exemplify systemic failure which might have been avoided if greater learning and systems thinking had occurred.

The Taurus project is worthy of study in my view because it was very widely reported on at the time in both the computer press and mainstream newspapers in the UK and Europe. It began as a great success and then became labelled as a terrible failure. It is also seen by many of those involved at the time as being a victim of its own complexity. This complexity may have been experienced in terms of:

^ the range of information products which the IS was supposed to deal with as provided by the wide range of stakeholders involved in the project;

^ the various forms of technology (both hardware and software) of which the IS was comprised;

^ the range of potential and actual consumers or customers of the data created;

^ the range of actors or stakeholders working within the project itself, each having a range of expectations and perceptions of the project.

Furthermore, Taurus was a project which followed on from IS developments which were generally seen as having been successful. In 1979 the first computerized IS for the London Stock Exchange – Talisman – had been effectively implemented while in 1986 the City had coped with ‘Big Bang’ – an automated trading system that put all dealer trading onto computer and largely swept away the existing paper-based approach. Surely the City could now take the next step and move into completely paper-free transactions throughout? As it happens 1986 was also the date when the Taurus project was initiated. But I do not want to start prejudicing you with too much of my assessment of the context at this stage. It is very important for you to approach the following information and develop your own ideas about it. The reasons for this will become apparent when you review the consultants’ reports in this and the next part of the block.

2.1 The Taurus project: sources of information

To enable you to experience the case study I am making use of two separate textual information sources which you will find in Audio notes 1 The Taurus case study and two tracks on

^ First, I have taken a chronology of the Taurus project from Helga Drummond’s account of Taurus ‘Escalation in Decision Making’ (1998). This provides you with the overall dates, times and problems of the project but needs to be read concurrently with the other resources. I have included some quotes about Taurus, before and after the collapse of the project, from those involved.

^ Next, I have provided a typical headline from the computer press just before the failure. This provides some idea of the impact of the event and the way in which it was considered at a popular level.

^ containing two tracks. of the Taurus project and lasts about 28 minutes. It is a compilation of the Taurus story as told by Peter Day of the BBC and includes BBC clips and inserts from Professor Helga Drummond and David Bicknell. is a 33 minute roundtable discussion about Taurus and the wider implications of such projects.

1

Audio notes 1

2 Stage 1 of the systemic learning cycle: being systemically aware of the Taurus project 57

CDthe CD.

CDFinally, there is a The first track is a history

The second track

The discussion is chaired by Peter Day and there are contributions from Peter Rawlins, the then Chief Executive Officer of the Stock Exchange, Helga Drummond and David Bicknell.

2.2 Studying the Taurus project case study materials

By reading and listening to these various materials you will be exposed to two main perceptions of the project as a whole from Helga Drummond and David Bicknell and several minor ones. These multiple perspectives of the project should provide you with a richness of interpretation and learning – of course they may also provide you with a challenge in terms of understanding exactly what lies behind the viewpoints. Again the Learning Album is important in this regard. Keep a track of your impressions of the various perspectives and assess where each perspective is coming from, what might lie behind the words? Be on your guard against accepting viewpoints which are partial and represent only one stakeholder’s view of the context.

The various accounts take time to read or listen to and then to think about – give yourself plenty time to do this. The chronology can be skimmed and then used as a ‘factual’ reference point. The newspaper article can be quickly read. It will take at least 60 minutes to listen to

as in the car or on a personal stereo in order to pick up further insights. So you will need to set aside at least an hour to do the reading and another hour for the SAQs and Activities. You may want to devise

one particular route below that exposes you to each of the sources of information in turn with reflective periods in between.

When actually working through all elements of the Taurus case study materials pay particular attention to:

^ answering the SAQs within the commentary below – these will help you to make sense of the case study;

^ using your Learning Album for taking notes in whatever form you feel comfortable with;

^ identifying the main structures and processes involved in the study using systems diagrams.

Now read the Taurus chronology in Audio notes 1.

Remember the chronology as presented here sets out the overview of the events of Taurus from the initial streamlining of the financial procedures in the City, through to Taurus being abandoned. Any chronology provides us with a set of interrelated items or facts which hold together – cause seeming to lead inevitably to effect. Of course at any time in the development of this chronology those involved would have little idea of the web or story they were involved in – unlike us they were not able to look around the corner of history to see where it was all going.

When you have read the chronology attempt the following SAQ.

Record your impressions and reactions to the case

study in your Learning Album

58 Block 2 Part 2 Using the hard systems method for managing Information Systems on the Taurus project

the CD, but this can also be listened to at other times, such

your own strategy for studying this material but I have set out

of

SAQ 16

In reading the account, what do you feel were the five most significant events which come together to lead to the failure of Taurus? On what criteria do you assess these five to be most significant?

Set out the five as the main themes in an appropriate diagram, then add at least another five themes – less important elements – which are relevant to the eventual end-point.

What is the nature of the relationship between the various elements?

study. Note down in your Learning Album any insights these give you into the Taurus project. Make use of systems diagrams to record and clarify your understanding. Read the Computer Weekly article – ‘City IT managers slam latest Taurus hold-up’ – in Audio notes 1.

This article is from 1993 and was written a few months before the Taurus project was finally wound up. As you read it and keeping in mind what you already know, consider how the major actors in the drama were feeling as they tried to keep the project on track. Note this down in your Learning Album, together with any further insights on the Taurus project that you gain from this reading. The article provides another, journalistic, perspective to the story.

Once you have finished making notes in your Learning Album, take another break before carrying on.

One reflection I have on these sources of information is the number of times words like ‘system’, ‘complexity’ and ‘manage’ arise in the accounts but without any indication of the context in which they are being used.

The following SAQs are intended to help you relate the story in the case study materials to some of the elements of IS discussed in Part 1. I want you to link the material you have read here to the ideas in Part 1 of Block 2 and also to the ideas on being, engaging, contextualizing and managing covered in Block 1.

SAQ 17

Given your reading of the Taurus project – which of the six IT epochs set out in Part 1 of Block 2 do you think it most closely corresponds to? What does the epoch you have selected indicate in terms of the way in which Taurus consultants engaged with the project and contextualized their thinking?

SAQ 18

Do you feel that the way technologists and managers approached the Taurus project was systemic or systematic? What does your answer indicate about the way in which Taurus was managed?

At this early stage in your experience of the Taurus project you have probably been mainly using notes and diagrams, but there are many tools and techniques which can help make sense of complex situations. One common technique for considering projects of all shapes and sizes is the SWOT analysis – meaning Strengths, Weaknesses, Opportunities and Threats. (Another variation is known as SWOC, with C standing for Challenges.) The analysis is usually set out as a matrix as shown in Table 1.

Learning Album

2 Stage 1 of the systemic learning cycle: being systemically aware of the Taurus project 59

Listen to the dealing with the Taurus casewhole of CD 1,

Table 1 SWOT analysis

Strengths. These are the things which are evident now and which make you feel that the project is ‘do’able

Weaknesses. Again these are relevant now and relate to the current problems of the project

Opportunities. These are the potential activities which could help make the project a success

Threats. These are the opposites of the opportunities – those things which could go horribly wrong unless looked after carefully

A SWOT can be developed in stages as follows:

1 Consider the perspective which you are bringing to the context. This is important – different people will draw different SWOTs of the same context but related to their own view and understandings. Be clear about your perspective.

2 Fill in the strengths and weaknesses elements. These refer to the elements which are evident at the time of the analysis. What are the strong and positive elements evident within the context being described and what are the weaknesses. Sometimes a strength can also be a weakness – e.g. some argue that the UK politician Margaret Thatcher was a very powerful personality and this was a great asset in her dealings with domestic and foreign policy concerns. Others argue that this strength of personality was a great weakness in that she was not able to develop potentially powerful alliances with other politicians. A powerful personality in a project team can be both a strength and a weakness.

3 When you have set out the strengths and weaknesses – consider the opportunities and threats. These are future conditions that might arise from the current position and are often guesses of what might happen. For example an opportunity arising from the establishment of a small business might be to expand and develop new branches in nearby locations. A threat might be to be so successful that the business is bought out by a competitor.

As with any technique there is variation in the way it can be applied. SWOT analyses are common in organizational management and all too often they are used in an uncreative or systematic manner without covering all aspects of a situation. Used creatively within a systemic framework then they do offer one way to systematically take different perspectives about an issue. So try to remember this as you use them in T306.

SAQ 19

Given your second-hand experiences of the Taurus project through the material provided, undertake a SWOT analysis of the project as it might have appeared to you at the project’s inception in 1986.

SAQ 20

Now undertake another SWOT analysis of the project – but this time as though the SWOT analysis were undertaken in 1993 after the project has finally been cancelled.

60 Block 2 Part 2 Using the hard systems method for managing Information Systems on the Taurus project

SAQ 21

Is there anything surprising about the S and O elements of your SWOT analysis for 1993?

SAQ 22

Is there anything to indicate how the problems which effectively killed the project in 1993 might have been identified and dealt with by a SWOT done in 1986?

3 Stage 2 of the systemic learning cycle: engaging with the Taurus project through the hard systems method

So far you have been asked to start making sense of the Taurus project in as broad a way as possible through techniques used in a systemic manner (diagrams and SWOT analyses). To further reflect upon the Taurus project in systems terms I am going to make use of a systematic framework or step-by-step procedure that encourages you to think systemically – the HS-method. Part 3 will repeat this exercise using another systematic framework that encourages systemic thinking and practice – the soft systems method. Both these methods can be used in a wide range of contexts, circumstances and ways. In this part and Part 3 you will be able to review two consultant’s approaches to analysing the Taurus project using these systems methods. These retrospective analyses of the Taurus project are intended to provide you with a learning exercise in applying a systems method to a context which is already well described and the outcome known so that you can apply it to a situation of your own. The challenge to the practitioner here (and in Part 3) is to show how things might have been better if a systems method had been applied from the outset. A challenge to you is to learn about these particular systems methods and decide whether, when and how they can be usefully applied to a wider range of situations.

In Section 1 various methods involved in the development of IS were mentioned. These methods were seen as extending from the hard to the soft, from those which were largely quantitative and formal to those which are largely qualitative and informal. In this section I am not going to be working with any specific hard method regularly used in IS projects but with the HS-method as developed by the Systems Discipline at the Open University (see Block 1 Part 3). This HS-method represents the essential elements of all hard methods and might be thought of as symbolic or representational of what might be contained within any specific hard method but with the added emphasis on systemic thinking and practice. In my experience the HS-method is of great value in planning and evaluating a formal and quantitative format for a project context. Unlike SSADM and other IS methods, it can be used in a wide range of hard project planning contexts other than IS and although it does not contain any specific tools and techniques for IS modelling it does allow a planner to make provision for these tools and techniques to be applied at a later date. In this sense it might be considered as operating at a higher level than standard hard IS methods, encompassing and including them. That is why this HS-method can sometimes be described as a hard systems methodology (remember Figure 5).

3 Stage 2 of the systemic learning cycle: engaging with the Taurus project through the hard systems method 61

What follows is an adapted version of the HS-method as first presented by my colleagues John Hughes, Joyce Tait and Sheila Stone some years ago in T301 (1984) with one or two interspersed comments from myself. It may seem theoretical and in need of further development but, as with learning to drive a car, you need to learn the basics before moving on to more sophisticated use later on. You also need to appreciate its various stages before grounding that theory in the practice expressed in Trevor Livesey’s analysis of Taurus using the HS-method.

3.1 Overview of the hard systems method

Leave yourself a couple of hours to read about the HS-method.

Figure 7 gives a paraphrased version of the HS-method, in plain English, to illustrate the underlying logic of the stages and their relationships, which are described briefly next. There are different types of activity involved in the HS-method. The actual analysis stages are shown in ovals while the rectangular boxes represent actions to be taken before and after the analysis. Before you start an analysis someone has realized that there is a problem to be solved or opportunity to be exploited which cannot be dealt with quickly or simply. (As an aside, already you should have noticed how the HS-method uses the problem/opportunity metaphor rather than just talking about a situation perceived as complex). The problem or opportunity is complex and components appear to be interconnected in

decision maker

1

2

3

4

5

6

what is the problem or opportunity?

where are you now?

where would you like to be and what stops you?

how will you know when you have arrived?

how could you get there?

how can you tell the outcomes?

what are the outcomes?

problem/ opportunity

7

choose the best route

8

OK, go ahead

‘real-world’ action

reflection intellectual activity

number of stage1

Figure 7 An activity sequence diagram of the HS-method with the stages paraphrased

62 Block 2 Part 2 Using the hard systems method for managing Information Systems on the Taurus project

some way. This problem or opportunity then needs to be properly understood to ensure, as far as possible, whether the initial perception was really the problem, or opportunity, or a symptom of some deeper problem or opportunity. For instance if you tell the doctor that you have a high temperature, he does not treat that as your problem but rather as a symptom of your illness. The doctor has to ask more questions to find out what the real problem is. Even when this is done there is always a possibility that at some later stage this diagnosis will be proved wrong and you will have to go back to this stage of identifying the ‘real’ problem. Having decided that the problem or opportunity is well enough defined (you might assess this by seeing if it is possible to express it clearly to a third party) the analysis can begin.

ACTIVITY 21

Making the HS-method your own.

Take a good look at Figure 7. As you go through the method it is a good idea to have a blank version of the HS-method cycle in your Learning Album so that you can paraphrase ideas for your project in it – step-by-step. This is a good way to make the HS-method your own and also a good way to develop your own version of how you use the method to compare with that of Trevor Livesey later in Part 2. If you have not developed your ideas about your project to a point where you can set them out using the HS-method you might choose a ‘simple’ problem like rearranging the garage simply to give yourself some practice at this method. I will develop this idea further in the next activity.

Let us now quickly run through the different stages. The HS-method can be well understood using the metaphor of taking a journey.

Stage 1: it’s not much use thinking about where you want to go unless you are pretty clear about where you are to begin with. I expect you will have seen street maps in cities which proclaim in large red letters ‘You are here’, and that’s what this first stage is all about.

You can then decide where you would like to go to (Stage 2) and having done this, you will be able to think up ways of knowing when you have arrived. For example, even if you have never been to London before, you are probably aware of some famous landmarks or other features, which would enable you to decide whether you are in London, New York or Paris. However, in using the HS-method it is also important to be able to tell whether, and when, you are nearly there, and how you do this (Stage 4) will depend on the route you have chosen to take (Stage 3), hence the more complicated interactions between Stages 2, 3 and 4 in Figure 7.

Before spending time, effort and probably money to get somewhere, it would be prudent to try to make sure that it’s the kind of place you really want to go to (Stages 5 and 6) and only then should you actually make the decision to go (Stages 7 and 8).

For the sake of simplicity, an important aspect of the HS-method has been missed out of Figure 7. In addition to the last arrow of the circle, there could be arrows from each of the other stages indicating a need to refer back (frequently) to the decision maker(s). There is also the possibility of referring back from any stage to a previous stage. For instance, when considering how you would like to get to where you want to go, you may find that it cannot be done (perhaps you hate flying so there is the constraint that you must be able to get to the place by boat and train) and

Learning Album

3 Stage 2 of the systemic learning cycle: engaging with the Taurus project through the hard systems method 63

then you would have to stay put or think of somewhere else to go. Maybe, on more detailed investigation of whether it is going to be all that you expected when you arrive, you would discover that it is not really your kind of place after all. Perhaps you may still want to go there, but it will be more expensive than you expected, so you have to take the train instead of flying. This process of reassessing earlier stages of the approach is known as iteration, but if I included all the possibilities for this in Figure 7, it would look more like a spider’s web than a logical process. You should be familiar with this idea of reassessing earlier stages from the learning cycle.

Now that you are familiar with the stages in plain English the HS-method is described in systems terms in Figure 8 (overleaf). The numbering sequence shows the order in which the stages should be completed, but the possibility of iteration is always there, as I have described already. Remember that if you do iterate back you must then redo all the following stages in their given order.

An important feature of the method concerns the role of the ‘client set’ – the person, or group of people, for whom the work is undertaken. The client and consultant roles may be fused into one when a manager or decision-maker undertakes to solve his or her own problems, without outside help.

Historically, most hard systems work has been done by consultants working on behalf of clients. The client has a problem or opportunity that they don’t know how to tackle, so they call in an expert in problem- solving (the systems analyst) to tell them what to do. This expert may be another member of the organization or someone external to it. While there is nothing wrong with this, it is also perfectly reasonable for any decision makers to use the method for themselves to help to come to a decision, design a system, evaluate an opportunity or solve a problem. The HS- method, as taught here, attempts to demystify hard systems thinking and to reduce the traditional emphasis on the role of experts.

Remember that the client set should play an active role throughout any project, having an input to each stage in Figure 8. Where a consultant is being hired it would be a mistake for all concerned if the client were to merely outline the problem at the start and then leave the consultant to get on with it.

When you have identified the initial problem or opportunity and a ‘client set’ there needs to be discussion about opportunity or problem perception before the HS-method as outlined in Figure 8, is begun. In the strict sense this is not part of the method, however unless you have done your ‘homework’ properly on how you and your client perceive the opportunity or problem, the use of the HS-method can be doomed to failure. Although it is often regarded (correctly) as the client’s responsibility to define the problem, some guidance from the consultant can often be useful to both. It also provides a broader perspective of the problem or opportunity. This need to understand the opportunity or problem involved is not peculiar to the HS-method. Nor if you are your own client can you assume you already know the answers; it is worth standing back and studying your own perception of the problem or opportunity.

64 Block 2 Part 2 Using the hard systems method for managing Information Systems on the Taurus project

ACTIVITY 22

This might be a good time to link your reading of the HS-method here to Trevor’s use of it in the following section. There are two ways you can tackle this Activity, either

^ make notes as you study the text in sequence on the HS-method (the theory), Trevor’s use of it and then your own; or

^ read one part of the theory first (e.g. stage 1) and then read how that part of the theory was applied in practice by Trevor and then note how you would apply it to your project (such as rearranging the garage).

However you should still also read both through in their entirety.

The way I do this type of exercise of comparing sections is to use a three column matrix. Divide a sheet of paper into three columns. Column 1 will contain the stages of the HS-method, column 2 will contain Trevor’s use of HS-method for the Taurus project and column 3 will contain the ideas you have on the context for your project.

‘real-world’ action

reflection intellectual activity

number of stage1

formulating measures of performance identification of

objectives and constraints

1

2

3

4

5

6

system description

evaluation

generation of routes to objectives

modelling

problem/ opportunity perception

problem/ opportunity

decision maker

choice of route(s) to objectives

implementation

7 8

Figure 8 An activity sequence diagram of the HS-method in systems terms

Learning Album

3 Stage 2 of the systemic learning cycle: engaging with the Taurus project through the hard systems method 65

Stages of HS-method (Section 3.2)

Trevor Livesey’s use of each HS-method (Section 4.2)

My project use of HS-method (e.g. rearranging the garage)

Where are you now?

Where would you like to be?

How will you know when you have arrived?

How could you get there?

How can you tell the outcomes?

What are the outcomes?

Choose the best route

In the first column put (in your own words) how you interpret each section of the description of the HS-method. You might focus on each of the eight headings from Figure 7 ‘HS-method paraphrased’ which has been included in the matrix by way of example. Following this then read the way Trevor ‘did’ each element of the HS-method and note down the main features of Trevor’s use of each of the elements in column 2. Finally, in column 3 makes notes on how you might apply the HS-method yourself to your project. If you have not got that far then use the ‘project’ I have already mentioned in Activity 21 – rearranging the materials and equipment you keep in your garage. This is usually a major project in my household! There is:

^ a problem perception (I cannot get my car in!);

^ ways of describing the problem;

^ numerous objectives and constraints (‘OK – to make room the bicycles have to go into the garden!’);

^ measures of seeing if I am getting to where I want to be;

^ modelling (maps of the new garage layout?); and

^ the potential to evaluate the outcomes.

This three column overview of your understanding of the HS-method can also be paraphrased onto the blank HS-method cycle which I encouraged you to draw in Activity 21. If you do use your own project in this activity then it will probably not be an IS project but the HS-method is adaptable to a wide range of contexts.

3.2 The stages in the hard systems method

Having looked at the HS-method in overview I will now describe each stage in more detail.

Getting started: opportunity or problem perception (what really is the problem or opportunity?)

There are two areas in opportunity or problem perception which are important: awareness and commitment. Here it is not just your personal awareness and commitment that is of concern but also the client set’s awareness and commitment. You need to understand what has made the client aware of the opportunity or problem. Where there are several clients involved, it is important at this stage to find out if the awareness has come from different causes or not, and whether these can be explained clearly or are a vague feeling of unease. When studying awareness, it is sometimes possible to realize that the initial problem or opportunity is only a

66 Block 2 Part 2 Using the hard systems method for managing Information Systems on the Taurus project

symptom of something much deeper which needs to be identified and taken as the problem or opportunity. Again in the case of commitment you need not only to ask yourself why you are doing this, but also why the client wants you to do this. This can help you make a choice of what to study in order to suit the needs of the client. At the end of this stage you should be able to decide whether it is sensible for you to go on to use the HS-method or not.

Stage 1: System description (where are you now?)

The aim of the first stage of the HS-method is to identify and describe the opportunity or problem to be solved, and the existing situation, its environment and its behaviour, all of which have to be taken into account.

While each stage is dependent upon the successful completion of the previous stages, it is the first stage of a project, more than any other, which determines the shape of the project as a whole. Mistakes made here often prove the most costly and result in the most time lost. For these reasons, it is important, right at the start of the project, to be aware of possible ramifications and implications of any definition of the problem or opportunity, so as to avoid prejudging the issue at this early point in your understanding of it. This means that, as well as defining and agreeing the problem or opportunity in the preliminary stage, it is important to construct the system which you envisage playing a part and its system’s environment. (Remember the system is a construction of our minds, it is not ‘out there’.) Gaining an understanding of the world views (or Weltanschauungen) of participants and organizations involved in any project is also crucial as well as clarifying your own views.

Stage 2: Identification of objectives and constraints (where would you like to get to and what stops you?)

In order to focus your effort you need to make explicit the decision- makers’ objectives in relation to the problem or opportunity, and the constraints under which they must operate. Following the HS-method forces you to examine and articulate these objectives and constraints, which is valuable for several reasons:

^ It forces decision-makers to clarify what they hope to achieve.

^ The need to agree on objectives can bring into the open disagreements among decision makers involved in the problem or opportunity which may otherwise only emerge at a later stage in the project. (If everyone agrees on the objectives too readily then that may also be a sign of difficulties ahead!)

^ The process of defining and elaborating objectives helps to maintain commitment to the project.

^ It lays the foundation for subsequent activities, since once the objectives and constraints are defined it is possible to ask what we need to do to achieve or avoid them.

Quantitative (quantifiable) and qualitative (non-quantifiable) objectives and constraints should be included where relevant. Quantifiable objectives and constraints will lead on naturally to the modelling exercise; non- quantifiable ones will set the political and value-laden boundaries on the final decision.

3 Stage 2 of the systemic learning cycle: engaging with the Taurus project through the hard systems method 67

Stage 3: Generation of routes to objectives (how could you get there?)

This is the most imaginative and free-thinking stage of the method. Here you are concerned with the different ways in which the defined objectives could be achieved. Whether the project is an aid to decision making or a systems engineering one, a large number of options should be put forward for consideration. After the initial creative generation of a whole range of potential routes to achieve the objectives, this must be narrowed down to produce a set of the most feasible options (which takes account of the constraints identified in the previous stage) for detailed consideration in the next stages of the method. The small subset taken on for further analysis should be chosen with the objectives and constraints defined in the previous stage in mind.

Stage 4: Formulating measures of performance (how will you know when you have arrived?)

The HS-method emphasizes the need to have a measurable means of assessing the effectiveness of any potential solution, decision, or design in achieving the desired objectives. For example, cost is often taken as one of the measures of performance used. At this stage therefore you need to decide on the measures you are going to use to determine which system or policy option comes closest to meeting your objectives. This means that the measures must be derived from the objectives and that there is nearly always more than one measure used to judge effectiveness. For instance if you decide to buy a car and your objectives are both value for money, and the need to get to places as fast as is allowable, the measures of performance will be cost, engine size, and acceleration. Measures of performance should be agreed with the client. If the measures are not agreed you will not be able to communicate your results effectively to them, in a language which they and those associated with them understand.

As I mentioned earlier in the discussion of Figure 7, it is sometimes important to be able to tell whether, or when, you have nearly reached your objectives. Put into systems terms this means that organizations sometimes go in for what they call ‘satisficing’ (this term is explained later on in the paragraph!) rather than optimizing strategies, in striving for their objectives. The ideal strategy is one which allows each measure of performance to be either maximized (as in the case of acceleration) or minimized (as in the case of cost). Unfortunately there is a relationship between these two measures of performance: while you are maximizing the acceleration you are also increasing cost – not minimizing it. To find the ‘best route’ to your objectives you need to optimize your measures, that is try to find the car which can be considered as giving the best possible acceleration without driving up the cost too much. It takes time and careful analysis to find the optimal route in a complex situation. Also, often even this best route or combination of routes to objectives is much more likely to bump up against some serious constraints than something which, while not being optimal, is at least satisfactory from the organization’s point of view. One of the constraints is the time and cost allowed to do the analysis. Finding a satisfactory route could take only a fraction of the time and cost of finding the optimal route. Taking this satisfactory route is satisficing.

68 Block 2 Part 2 Using the hard systems method for managing Information Systems on the Taurus project

Stage 5: Modelling (how can you tell the outcomes?)

Once the subset of routes to objectives has been selected for further consideration it is possible to construct, modify or adapt a model which can be used to test each route’s likely outcomes, in terms of the measures of performance. It may be helpful to remind you of the key features of modelling as covered by the modelling pack.

A model, in its broadest sense, is any set of organized assumptions about a particular aspect of the world and the way it works. In a sense, modelling is a normal human activity which governs every conscious action we take. Since our brains can only cope with so much information at any one time, we are forced to select from, and simplify, the total amount of information available to us through our senses. Thus, the way we go about our everyday business is dependent on the way we perceive the world before us, through a continuous process of constructing and discarding mental images or models. For instance, when I am driving my car and approaching a roundabout, I have to make many almost instantaneous decisions based on my appraisal of the situation around me and my prediction of what is about to happen. To do this I have to focus my attention on what I think is relevant, such as the speed and position of my car and the speeds and positions of other cars nearby, but I do not worry whether the grass on the roundabout has been cut recently (unless it interferes with my view of the oncoming traffic) or whether an aeroplane is flying overhead. Whether I navigate the roundabout successfully or not will depend on my skill in selecting the information to construct a model of the scene facing me, the decisions I make as a result of using that model and the consequences of those decisions. The point I want to make is that there is nothing special or mystical about modelling. The model created to help you to negotiate the roundabout was done quickly and based on experience; the modelling we are going to do here is done more slowly and based not so much on experience but on more careful thought. All models do essentially the same kind of thing, namely present a simplified construct of some aspect of the world which happens to be of interest to someone at a particular time. In order to cope with more complex problems than negotiating a roundabout we need to translate our mental models into a more elaborate and permanent form via words, drawings, diagrams, maps, equations, physical models, etc. In this way we can build up much more complex models than we can cope with in our heads; we can modify these models, examine them, test them and use them to make decisions in a more deliberate way than when instant decisions are needed.

Advances in technology over the past fifty years or so have provided the means of obtaining and communicating incredible amounts of ‘raw’ data about the world. This, in turn, has revolutionized the process of decision making because much of this ‘raw’ data is now processed into an understandable quantitative form. This quantitative information is generated by mathematical models, which in turn can be used in other mathematical models in which relationships are expressed in symbolic form. Models of this kind are extraordinarily powerful and flexible, because their characteristics can be altered at the stroke of a pen or, more often these days, by an entry into a computer and a range of experiments can be conducted on them to an extent which is not possible with any other kind of model. However, there always seems to be a price to pay for progress. Because of the availability of a vast array of mathematical techniques, and of computers to do the ‘number crunching’, it is often very tempting to model only those aspects of a complex problem or opportunity

T553

3 Stage 2 of the systemic learning cycle: engaging with the Taurus project through the hard systems method 69

which are quantifiable, or to reduce complex problems to a quantifiable form. The modelling stage of the HS-method inevitably concentrates on these mathematical aspects of modelling but you should not lose sight of the unquantifiable objectives and constraints identified in Stage 2 or more qualitative types of models. Models, then, are used to predict the behaviour of the system of interest when following particular routes to objectives.

Stage 6: Evaluation (what are the likely outcomes?)

The process of evaluation, using the model you have constructed, involves assessment of the likely outcomes of taking the various routes to the objectives in terms of the measures of performance. A particularly important part of this process is the testing of the model itself to make sure that it does mimic the behaviour of the real world, at least in important respects, and that you are aware of its deficiencies. Each route should be evaluated (where possible) against all the measures.

Stage 7: Choice of route(s) to objectives (choose the best)

You might imagine that, after all that has gone before, the selection of the best route or routes to objectives would be a fairly automatic process. Not so, alas, because this is the point where your unquantifiable objectives and constraints come into the picture again. The analyst may find that suggestions which seemed simple in the light of a computer model do in fact lead to a lot of discussion before the ‘best’ strategy for solving a problem or grasping an opportunity is worked out.

It is also rare to find that one route is best on all objectives. The client is responsible for the final decision.

Stage 8: Implementation (OK, go ahead)

In Figure 8 ‘problem/opportunity’, the ‘decision maker’, ‘problem/ opportunity perception’ and ‘implementation’ are shown inside boxes indicating that they exist in the real world while the other stages of the method are in ovals to represent the fact that they are thought-processes rather than being action-oriented. Implementation, then, is action-oriented and the detailed work necessary to get your strategy adopted or to set up the system you have designed can now go ahead.

Before working through the SAQs below, take a little time to consider what the HS-method means to you. Do not be concerned if your honest answer is ‘not a lot’. It may well be that methods like the HS-method are quite new to you. If you have looked ahead at Trevor’s use of the method then you should have some idea of what it can bring to an analysis. You may also like to take a look at the completed version of HS-method (that you did for Activity 22) in your Learning Album. This will not be perfect but will represent your first go and this is the basis for improvement. It might be a good idea to jot down your current thinking in your Learning Album for comparison with your ideas later in the block.

SAQ 23

Compare and contrast, by use of a cycle diagram, the HS-method as set out here and the overall ideas about hard methods as described in the previous material and in Section 1.1 of this part. Are they both describing the same idea of a hard method?

70 Block 2 Part 2 Using the hard systems method for managing Information Systems on the Taurus project

SAQ 24

HS-method is valuable in many situations but as has been argued earlier it also has weaknesses. I would like you to explore HS-method now by means of a SWOT analysis that sets out the main features of the HS-method as it might be applied to a project which you are interested in.

There is a great deal of information about the HS-method to take in here. The process of absorbing the details relating to it can best be accomplished by seeing the method in action. In the process of applying the method in the next section you will see how:

^ the various elements come together;

^ each element can be applied in a specific case;

^ each element supports and relates to the details of the study in question.

What follows are:

^ the terms of reference provided to a consultant in order to make an investigation of the context;

^ some details about the consultant;

^ the report of the consultant.

As you consider the report produced by the consultant, consider the HS-method as a learning cycle in itself. Figure 9 provides one view of the HS-method as a learning cycle.

experience actions in the world by the

decision maker experience again

model or experiment with the developed

model compare different routes to

objectives to discover the optimum route

identify and abstract - identify

objectives and constraints, consider route to objectives, measures of performance

reflection - problem perception, system

description

Figure 9 An activity sequence diagram of the HS-method as a learning cycle

3 Stage 2 of the systemic learning cycle: engaging with the Taurus project through the hard systems method 71

4 Stage 3 of the systemic learning cycle: contextualizing your approach to the Taurus project through a consultant’s use of the hard systems method

In order to make this part of the investigation into the Taurus project a life-like simulation I have set out the following consultancy exercise for Trevor Livesey. The client (assumed by Trevor to be the London Stock Exchange) is employing him to undertake the analysis – possibly as a reflective, learning exercise – to find out what went wrong and learn how to avoid such messes in the future.

I shall provide you with the terms of reference which were given to the consultant and then the consultant’s report itself.

4.1 Consultant’s terms of reference

You will be provided with the following information:

^ The chronology of Taurus.

^ A newspaper article about the Taurus failure.

(The consultant also had access to further sources of information.)

Your task is to write a HS-method analysis relating to Taurus. What follows are the terms of reference for the task.

The purpose of applying the HS-method to the Taurus project is to show how systems tools can be used to make complex situations more understandable. I expect you to come up with different ideas and different ways of looking at the project. The main question for you to answer is this:

What went wrong in systems terms in this complex context and how might the HS-method have been applied to avoid the problem?

In particular I am expecting that you will undertake a retrospective analysis of the project based on the materials provided, using the HS- method sensitively to:

^ identify the problem;

^ describe the problem in systems terms;

^ develop a model which might have avoided the problem.

There now follows Trevor’s report based on these terms of reference. It should take you 30–45 minutes to read through the report. When reading it please keep in mind the suggestions for using your Learning Album in Activities 21 and 22.

Before reading Trevor’s report you may like to know a little about him in his own words.

After a variety of occupations, I worked for a Housing Corporation for 21 years. From an organization and methods background I went on to manage the development of computer systems for their IBM mainframe computer. I worked in a partnership team with a consultancy to develop a 10-year computing strategy and then became IT Strategy Development Manager. I retired in 1996. Over some of that time I wanted to learn more and in 1991 I graduated with an Open University Honours degree that included systems courses. I was then able to obtain an appointment as a

Trevor writes ...

72 Block 2 Part 2 Using the hard systems method for managing Information Systems on the Taurus project

part-time Tutor for the Open University, and I have tutored T301 Complexity Management and Change, T247 Working with Systems, T171 You, Your Computer and the Net as well as the Systems Summer School and doing some work for the Open University Business School. I am a devoted believer in the power of systems thinking and the usefulness of systems methods and methodologies.

4.2 Consultant’s report on the Taurus project by Trevor Livesey

Introduction

This analysis of the Taurus case study is made in retrospect but is otherwise an outline of how it might have been approached in 1986. Most of the case study material is about what went wrong so there is not very much to go on. In addition, the London Stock Exchange was about to embark on a potentially very large and costly exercise. Any analysis of this sort would have needed significant time and resources to develop a convincing, well documented and justified Systems study. This analysis should, therefore be regarded as a high-level exercise to demonstrate, in outline, how the HS-method might have been applied.

Problem/opportunity

The scenario is located in the City of London in the mid-1980s. It is a time of massive and far reaching change as well as burgeoning competition from European and the Far Eastern money markets. There is a perceived need to modernize procedures, cut costs and create a streamlined, accountable set of financial institutions and services.

The client

The client is the London Stock Exchange. Its origins go back to the coffee houses of 17th century London where those who wished to invest or raise money bought and sold shares in joint stock companies. It was constituted by Deed of Settlement in 1802 and carried on business for the benefit of its proprietors, the individual members of the Stock Exchange. In 1986, the Exchange became a private limited company, prompting the change from what was a members’ association to a non-profit making company. Member firms became shareholders of the Exchange, with each firm holding a single vote. Membership of the London Stock Exchange ranges from the largest investment banks in the world to small local firms. Its members work in environments spanning a wide range of business interests.

In line with these changes, the Stock Exchange has adopted a major support role for the whole of the City financial community and recently developed the successful TALISMAN computer system. The Stock Exchange now sees the opportunity to extend this support. The Stock Exchange favours further computerization and considers that modernizing the equities trading procedures is currently the most important. This is likely to be a large, complex operation and the current consensus is to simplify this by buying-in ready-made systems and adapting them. However, there are dissenting voices about whether this is the next priority and if it is, how to go about it. The Stock Exchange has, therefore, commissioned this consultancy report to make recommendations on what to do next and how to go about it.

4 Stage 3 of the systemic learning cycle: contextualizing your approach to the Taurus project 73

The consultancy is committed to carrying out a study using well regarded and tried-and-tested systems methods to make justified recommendations in the best interests of our client and the City of London financial community. The consultancy will be taking account of the client’s assumption which is the belief that the integrity and good name of the London Stock Exchange makes it pre-eminent in the world and that it has a role to provide quality support to its members and the financial community.

System description

The currently known information is summarized in a spray diagram (Figure 10). This is an assembly of information based on mind associations, not technically correct relationships. It provides an overview of facts and aspects in a loosely structured way.

It would put the scenario in the context of the London Stock Exchange’s brief better, if the reasons why it sees the need to expand its support for securities trading were to be clarified. This question is explored in a multiple cause diagram (Figure 11 see page 76). From this it can be seen that there are many and varied reasons all culminating in the desire of the Exchange to expand its support. This diagram also illustrates the benefits which the Exchange sees would flow from pursuing this policy.

Taking the understanding created by the two diagrams it seems evident that everything of note is related in some way to the trading in stocks and shares in the City of London. A systems description is therefore conceptualized as ‘a system to trade stocks and shares in the City of London’. This system encapsulates, in a structural way, the various systems (or sub-systems depending on what level they are being considered) which make up a system of interest which is relevant to the analysis (see Figure 12 on page 77).

Identification of objectives and constraints

Taking the system description and applying the understanding of the scenario together with a working knowledge of how organizations like the Stock Exchange think and act, an objectives hierarchy can be drawn up (Figure 13 see page 78). This has as its mission a representation of the Weltanschauung of the Council of the Stock Exchange. The goals below this represent those things which the Exchange is seeking to do in the context of the scenario. It may well have many other goals, both internal and external, but these are not relevant for the current brief. Below the goals is a series of objectives which represent what the Exchange sees that it needs to do in order to achieve each associated goal. Again, only those objectives which are currently relevant are incorporated.

The analysis continues by evaluating each of the objectives (Table 2) with a view to selecting (in this case) just the most appropriate and potentially fruitful one to pursue (Table 3 see page 79).

74 Block 2 Part 2 Using the hard systems method for managing Information Systems on the Taurus project

ru les

cer tif

ica tes

transactions

quoting

deals

market making co

mm iss

ion s

settlements trad ing p

roce sses

share trading sto cks

fix ed

in te

res t s

to ck

s

gilts

equities sh are

s

UK eq

uit ies

Exch ang

e Co unci

l m em

ber s

high st reet ba

nks

management

banks merchant banks

int ern

al p olit

ics

Inst ituti

ons City of London governmenthistory

big changes

au di

to rs

com petition

watchdogs

Europe

pre ss

te le

vi si

on

Far East

trading procedures

sem i-com

puterized

bro ad

bus ine

sse s

pa pe

r- ba

se d

con ven

tio ns

so ftw

are ho

us es

technical press computing indus try su

pplier sco

ns ul

ta nt

s Talismanst

aff sy

st em

s

computingregulation

inf orm

at ion

su pp

or t

se rv

ic es

in su

ra nc

e

inv es

to rs

priv ate

institutions

company clie

nts

re gi

st ra

rs m

id dl

em en

trading services

couriers

firms job ber

s

emp ires

stock broke rs

dealers

overs eas e

quiti es

origins in 17th century

broad membership

private lim ited com

pany 19

8 6

London Stock Exchange

Figure 10 Spray diagram of the London Stock Exchange scenario in 1986

4 Stage 3 of the systemic learning cycle: contextualizing your approach to the Taurus project 75

Heasman Committee recommends streamlining

review of procedures

urgency for change

existing weaknesses

evident

expansion of trading values

impending deregulation

commercial imperatives for action need to modernize

securities trading

TradeNet being developed

restrictive practices threat

cost savings needed to compete

archaic systems

good track record

well regarded institution success of Talisman

Stock Exchange to expand support for securities trading

existing experienced computer staff

Stock Exchange wants to extend

power base

increased income

increased world regard increased wealth

for Stock Exchange members

increased influence in the City increased status of

Council members

increased ability to support other

activities

Wilson Report on functioning of the City published

Figure 11 Multiple cause diagram of the reasons why the Stock Exchange sees an opportunity to expand its support for trading companies

76 Block 2 Part 2 Using the hard systems method for managing Information Systems on the Taurus project

a system to trade stocks and shares in the City of London

Stock Exchange

management

Exchange Council

internal politics

members

support services

specialists

information regulation

computing

systems staff

Talisman

trading processes

commissions rules

deals

share trading

transactions quoting

settlements

certificates

market making

computing industry

software houses

technical press

consultants suppliers

firms

conventions

procedures

institutions

City of London

watchdogs press television

government auditors

Far East competition

Hong Kong Singapore

activities control

Bank of England

Restrictive Practices

Court deregulation

Department of Trade and Industry

Director General of Fair Trading

trading procedures

paper- based

administrative

semi- computerized

trading services

shares

overseas equities

UK equities

empires clients

middlemen

registrars dealers

jobbers couriers stocks

gilts fixed interest

stocks

stock brokers

investors

banks merchant

banks high street banks

insurance

private

company institutions

Figure 12 Systems map of a system to trade stocks and shares in the City of London

4 Stage 3 of the systemic learning cycle: contextualizing your approach to the Taurus project 77

Table 2 Evaluation of objectives

Objective Evaluation

support for equity trading good potential but will be more feasible after implementation of support for settlement

support for equity settlement significant contribution to goal above and mission

capable of being modelled using monetary measures which are appropriate for client

applicable data available from similar projects

good fit with client’s current aspirations

provide information for market makers heavy investment in hardware unlikely to be supported by City firms

value of information to firms difficult to quantify

provide information for the media unlikely to generate significant revenue

value of information to the media difficult to quantify

support regulation of users good contribution to goal above but goal unlikely to make major contribution to mission at this time difficult to model

support regulation of trading companies good contribution to goal above but legal framework likely to change in the near future

difficult to quantify

Table 3 Choice of objective

Objective Justification

support for equity settlement the front runner on all aspects likely to be heavily supported by clientset systemically appropriate

mission

goals

objectives

make The Stock Exchange pre-eminent in support for City of London financial businesses

provide efficient support for trading

companies

provide comprehensive

information systems

provide effective support for regulatory functions

provide support

for equities trading

provide support

for equities settlement

provide information

for market makers

provide information

for the media

support regulation of users

support regulation of

trading companies

Figure 13 Objectives hierarchy of The Stock Exchange’s support role

Consultant’s comments

The objectives hierarchy above is drawn from the perspective of the Stock

Exchange but is formulated by the consultancy based

on the documents available. The evaluation in

Table 2 represents the considered opinions of the

consultancy based on a wide ranging overview of

the system of interest and its environment in systemic rather than practical terms.

The choice of objective in Table 3 is made by the

consultancy but support for it would be sought from

the clients before taking it forwards. This is a highly reductionist step in order

to make the analysis workable; other objectives

might be developed in subsequent iterations.

78 Block 2 Part 2 Using the hard systems method for managing Information Systems on the Taurus project

Constraints

Constraints are identified for the chosen objective which represent the most significant aspects with which any recommendations must comply to meet either client specifics or environmental circumstances.

The most important seem to be:

^ ability of City firms to fund their consequential costs;

^ operate within legal and procedural framework;

^ be ready in 2 years.

Measures of performance

In order to forecast the likely outcome of adopting any particular course of action based on the chosen objective, key quantifiable and practical variables are identified. They must be capable of being used as output variables from any model or models constructed in the next stage and be appropriate for evaluating, in a quantitative way, recommendations for change (Table 4).

Table 4 Measures of performance

Measure Justification

Net present value in £M It is feasible to obtain or extrapolate the data from similar completed projects and use in a financial model

Time to complete in years It is feasible to obtain or extrapolate the data from similar completed projects and use in a time/activity model

Risk of project failing % Can be modelled using complexity/ uncertainty factors deduced from research analysis

Routes to objective

Routes to objectives which represent ideas for how the chosen objective might be achieved are now generated. This is a process often involving visualization, creativity and ingenuity, particularly when considering a problem to be solved. In this case, the requirement is to take up an opportunity and the number and scope of possibilities is limited. There are only a few feasible ways, common to such situations and well known, which are worth considering.

Generation of routes to objective:

^ develop computer system in-house with existing staff;

^ adapt an off-the-shelf package;

^ appoint software house to build bespoke computer system;

^ open tender for three systems integrators to build competitive prototypes and winning tenderer to build pilot and phased implementation;

^ select leading consultancy firm to undertake the whole project;

^ simplify and rationalize manual systems and re-evaluate need for computerization on completion;

^ do nothing until the new regulatory and procedural frameworks are in place.

T553

Consultant’s comments

These means are chosen for their systemic characteristics so as to provide a convincing basis for analysis.

4 Stage 3 of the systemic learning cycle: contextualizing your approach to the Taurus project 79

The above list now needs to be whittled down to those which are likely to be fruitful to model and acceptable to the client. Initially this is done by identifying advantages and disadvantages based on expert knowledge and characteristics gleaned from practical experience (Table 5).

Table 5 Evaluation of routes to objective

Route Advantages Disadvantages

Develop computer system in-house with existing staff

resources already in place

early start possible

reservoir of knowledge of the workings of the City

the accepted norm for large specialist projects

likely to be fast start

may need to recruit more staff

little project management experience of such a potentially large project

City firms may not be co- operative

appropriate expertise for acquiring/installing hardware may not be present

Adapt an off-the-shelf package

flying start on base system

likely to meet timescale

likely to be the cheapest

capacity for success should be ascertainable early in project

appropriate packages likely to be US origin with need for Anglicization

may be inflexible to change

very expensive to make changes (that is how they make their profit!)

low experience of the City and its firms

steep learning curve for supplier staff

unclear who will supply the hardware and how it will be installed

may have no suitable project management experience

Appoint software house to build bespoke computer system

likely to be cheap if a fixed price can be negotiated

third party bears software risk

slow start to project

extensive (computer) systems analysis may be needed

unclear who will supply the hardware and how it will be installed

unlikely to meet timescale

client bears hardware risk

client locked-in soon after start

Consultant’s comments

The evaluation of routes is carried out by the

consultancy based on experience and expertise

gleaned from wide ranging sources. Whilst individual

statements may be challengeable it is the

overall ‘picture’ of each route which is important

80 Block 2 Part 2 Using the hard systems method for managing Information Systems on the Taurus project

Open tender for three systems integrators to build competitive prototypes and winning tenderer to build pilot and phased implementation

third party bears software and hardware risk

integrator fully responsible for ‘making it work’

final tenderer selected on real evidence of ability

step-by-step method allows client to review project at break points

unlikely to meet timescale

operationally complex

needs active support from user community

integrators will offer what they have ‘on the shelf’ not necessarily ‘best for purpose’

Select leading consultancy firm to undertake the whole project

offloads all responsibility critically dependent on ability of consultants to deliver

consultants still have to decide what development method to adopt

Simplify and rationalize manual systems and re-evaluate need for computerization on completion

likely to be comparatively cheap

does not fit in with client’s Weltanschauung

leaves the door open for individual firms to start building their own disparate computer systems

likely to be resisted by traditional culture of the City

Do nothing until the new regulatory and procedural frameworks are in place

ultra safe option indeterminate timescale

does not fit in with client’s Weltanschauung

Choice of routes to objective

Based on the identified advantages and disadvantages, an opinion can be formed as to those which are worth pursuing further and likely to lead to fruitful results (Table 6).

Table 6 Routes to objectives

Route Decision Justification

Develop computer system in-house with existing staff

include makes best use of existing knowledge and expertise

Adapt an off-the-shelf package include simple, fast method

Appoint software house to build bespoke computer system

reject too many uncertainties

Open tender for three systems integrators to build competitive Prototypes and winning tenderer to build Pilot and phased Implementation

include best chance of quality product

Select leading consultancy firm to undertake the whole project

reject critically dependent of ability of consultancy

Simplify and rationalize manual systems and re-evaluate need for computerization on completion

reject not going to be supported by client

Do nothing until the new regulatory and procedural frameworks are in place

reject not going to be supported by client

4 Stage 3 of the systemic learning cycle: contextualizing your approach to the Taurus project 81

Having reached a short list of routes to our chosen objective, each needs to be modelled to provide output data in the format of the chosen measures of performance. This will enable each to be compared on the same basis.

Model construction

Time to complete in years

Large one-off projects, especially in the computing industry, involve complex sequences of interdependent activities some of which can proceed concurrently and others of which are consecutive or overlapping because they cannot start before a previous one has completed or reached an identified stage. Critical path analysis (CPA) is a modelling tool which is used to forecast the incidence and timing of these activities, sequences and dependencies.

^ The input is a series of identified human activities and events built up from knowledge of the requirements of the project and known ways to achieve them.

^ The process uses expert knowledge, previous experience, technical considerations and pragmatism to forecast how long each activity will take, taking account of available resources and the dependencies of activities upon one another.

^ The output is a series of time points for activity starts, finishes and events.

^ The main assumptions are that the requirements of the project will not change significantly during its lifetime and that technological advances will not render the specification obsolete.

This output can be expressed in a number of diagrammatic forms, one of which is a Gantt chart. This plots start and finish times on a horizontal axis and a series of activities on a vertical axis. Activities are grouped hierarchically and the diagram can be presented at any level of detail. The simplified high-level Gantt chart used here (Figure 14, see p.84) identifies key activities and milestones within the project and plots their likely time- scales. It also provides information on the timing of costs and savings for use in the next model. Estimating time-scales before carrying out the investigation and analysis is notoriously difficult and the results are, at best, indicative rather than predictive. However, being based on actual time-scales for similar actual projects, they have a degree of credulity. In addition, as in this case, when used to make comparisons, the projected differences are likely to be reasonably sound.

Net present value in £M

Net present value represents the notional value of monies coming into or flowing out of a project over a period of time. This can be modelled using the well established Net Present Value (NPV) cash flow financial model.

^ The input is a series of forecast money flows under various budget headings including both capital and revenue items. Flow out is based on the forecast costs of all the activities making up the project. Flow in is based on the projected savings resulting from implementation of the project. The timing and extent of these variables can be derived from the previous models.

^ The processing is divided into time bands (in this case years) and consists of an aggregate of the inflow and outflow of money each year.

T553

Consultant’s comments

These assumptions are necessary in order to take

the project forward. However, by articualting

them specifically provision is made for the justification

of a review during implementation if they

become no longer viable.

82 Block 2 Part 2 Using the hard systems method for managing Information Systems on the Taurus project

The yearly figures are discounted to allow for the value of money used or available during the life-time of the project using a forecast interest rate.

^ The output is the discounted cash flow for the final year which represents the NPV of the project as a whole.

^ The main assumptions are that interest rates will remain stable and inflation will not invalidate the financial estimates.

Costs tend to be underestimated and savings overestimated by the responsible management but, as long as this is taken into account, it remains one of the best financial indicators.

Risk of project failing

This model is more subjective than the other two. Nevertheless, research into similar projects (particularly those which have failed) has enabled a correlation to be formulated between aspects of complexity and uncertainty on the one hand and likelihood of project failure on the other.

^ The input is a series of key aspects of the project where their complexity or uncertainty may have an adverse effect on the success of the project.

^ The processing is to apply a notional percentage risk of project failure for each aspect based on empirical data and aggregate them for the project.

^ The output is a single percentage estimated risk of project failure.

^ The main assumptions are that the scale and complexity of the project will not change significantly over its lifetime.

The limitation of the model in this application is that only a small number of factors are examined whereas, in practice, a multitude of interrelated factors may be at work. This approach has been researched and refined significantly since 1986 and current models can be applied, not only at the start, but during progress to help to spot projects which are heading for disaster.

Modelling

There follows the three modelling approaches to the three routes to objectives. First the time lines for development of the three routes to objectives is set out in Figure 14.

The second analysis involves the development of net present values for the three routes (Table 7, see p.85). The base line figures have been estimated.

The third analysis sets out the risk analysis for the three routes (Table 8, see page 86).

Consultant’s comments

These assumptions are necessary in order to take the project forward. However, by articualting them specifically provision is made for the justification of a review during implementation if they become no longer viable.

Consultant’s comments

These assumptions are necessary in order to take the project forward. However, by articualting them specifically provision is made for the justification of a review during implementation if they become no longer viable.

4 Stage 3 of the systemic learning cycle: contextualizing your approach to the Taurus project 83

2. Adapt an off-the-shelf package

3. Open tender for three systems integrators to build competitive prototypes and winning tenderer to build pilot and phased implementation

1. Develop computer system in-house with existing staff activity 1986 1987 1988 1989

systems analysis system development system testing user testing hardware selection hardware installation training implementation project review

activity 1986 1987 1988 1989 systems analysis system development system testing user testing hardware selection hardware installation training implementation project review

activity 1986 1987 1988 1989

user testing

training implementation project review

open tender 3-integrator prototype select winning integrator

accept pilot

pilot

Figure 14 Time-line model of routes to objectives

Consultant’s comment

Notes these tables of time-lines are presented at a high level but many sub-activities lie beneath. Whilst many of the timescales might be challenged, the time to complete the project is the significant output here.

84 Block 2 Part 2 Using the hard systems method for managing Information Systems on the Taurus project

Table 7 Net Present Value model of routes to objectives

(a) Develop computer system in-house with existing staff

Total £M 1986 1987 1988 1989 1990 1991 1992

Software costs

–£0.10 –£0.10

Hardware costs

–£5.00 £0.00 –£3.00 –£2.00

Development costs

–£10.00 –£6.00 –£3.00 –£1.00

Overhead costs

–£0.60 –£0.20 –£0.20 –£0.20

Integration costs

£0.00 £0.00 £0.00 £0.00

Total costs –£10.60 –£6.20 –£3.20 –£1.20 £0.00 £0.00 £0.00 £0.00

Cost savings to the City

£105.00 £0.00 £5.00 £50.00 £50.00

Value of job savings to the City

£612.00 £0.00 £1.00 £600.00 £10.00 £1.00

Total savings £267.00 £0.00 £0.00 £6.00 £200.00 £60.00 £1.00 £0.00

Net £256.40 –£6.20 –£3.20 £4.80 £200.00 £60.00 £1.00 £0.00

Net Present Value at 5%

£183.80

(b) Adapt an off-the-shelf package

Total £M 1986 1987 1988 1989 1990 1991 1992

Software costs

–£5.00 –£5.00

Hardware costs

–£5.00 £0.00 –£3.00 –£2.00

Development costs

–£5.50 –£5.00 –£0.50

Overhead costs

–£0.60 –£0.20 –£0.20 –£0.20

Integration costs

£0.00 £0.00 £0.00 £0.00

Total costs –£6.10 –£5.20 –£0.70 –£0.20 £0.00 £0.00 £0.00 £0.00

Cost savings to the City

£105.00 £0.00 £5.00 £50.00 £50.00

Value of job savings to the City

£612.00 £0.00 £1.00 £600.00 £10.00 £1.00

Total savings £267.00 £0.00 £6.00 £200.00 £60.00 £1.00 £0.00 £0.00

Net £260.90 –£5.20 £5.30 £199.80 £60.00 £1.00 £0.00 £0.00

Net Present Value at 5%

£203.12

Consultant’s comment

There is no need to examine the figures in detail. In any case, many more tables of figures lie behind each one and the credibility of the tables cannot be judged in isolation. The NPV (emboldened in the tables) is the significant output of this modelling.

4 Stage 3 of the systemic learning cycle: contextualizing your approach to the Taurus project 85

(c) Open tender for three systems integrators to build competitive prototypes and winning tenderer to build pilot and phased implementation

Total £M 1986 1987 1988 1989 1990 1991 1992

Software costs

£0.00 £0.00

Hardware costs

£0.00 £0.00 £0.00 £0.00

Development costs

£0.00 £0.00 £0.00

Overhead costs

–£0.60 –£0.20 –£0.20 –£0.20

Integration costs

–£10.00 –£1.00 –£4.00 –£5.00

Total costs –£10.60 –£1.20 –£4.20 –£5.20 £0.00 £0.00 £0.00 £0.00

Cost savings to the City

£105.00 £0.00 £5.00 £50.00 £50.00

Value of job savings to the City

£612.00 £0.00 £1.00 £600.00 £10.00 £1.00

Total savings £267.00 £0.00 £0.00 £0.00 £6.00 £200.00 £60.00 £1.00

Net £256.40 –£1.20 –£4.20 –£5.20 £6.00 £200.00 £60.00 £1.00

Net Present Value at 5%

£170.08

Table 8 Risk/complexity factors model of routes to objectives

1. Develop computer system in-house with existing staff

2. Adapt an off-the-shelf package

3. Open tender for three systems integrators to build competitive prototypes and winning tenderer to build pilot and phased implementation

% likelihood of failure

Complexity Analysis 20 60 10

Development 10 35 10

Implementation 30 25 5

Uncertainty Time-scale 30 35 20

Costs 80 90 30

Savings 20 20 20

Feasibility 10 40 15

Average 29 44 16

Evaluation

The output from the three models is summarized in an evaluation matrix to make the results easy to compare (Table 9).

Consultant’s comments

As for the NPV models, many other figures and personal judgements lie behind each item. The ‘average’ figures at the

bottom of the table are the significant output of this

modelling.

86 Block 2 Part 2 Using the hard systems method for managing Information Systems on the Taurus project

Table 9 Evaluation matrix

Time to complete in years

Net present value in £M

Risk of project failing in %

Develop computer system in-house with existing staff

3 183 29

Adapt an off-the-shelf package

2 203 44

Open tender for three systems integrators to build competitive prototypes and winning tenderer to build pilot and phased implementation

3 170 16

Conclusions

There is no clear-cut outcome from the evaluation.

On time to complete, the off-the-shelf option scores well based on a rapid use of existing software. The in-house option is expected to take longer because of the normal need to conduct an extensive systems analysis exercise. The open tender option still needs systems analysis but this can be spread over the prototype and pilot phases obviating the need to complete it before starting development. On the other hand the phased approach will take longer overall.

On Net Present Value, the off-the-shelf option is best which reflects the fact that a ready-made solution should be simple and quick. Next is the in- house option which is the normal (1986) way to develop systems and capitalizes on track record knowledge of the workings of the City. Lowest (but not by much) is the open tender option where the step-by-step approach extends the timescale and so generates savings later.

On risk of failure, the open tender option scores very well because it will be possible to review and make changes if necessary at the breakpoints on completion of the prototype and pilot phases. In addition, large systems integrators would be expected to tender and they would have an extensive reservoir of expertise and resources available to them. The in-house option is seen to be riskier as it may be limited by the abilities of the existing staff to cope with a large and complex project. The off-the-shelf option is significantly riskier due to several adverse factors taken into account. Experience suggests that off-the-shelf packages are rarely suitable for a very specialist application such as the equities settlement procedures and extensive customization will be required. This will be expensive, time- consuming and error-prone. Changes to meet particular user requirements will also be difficult and costly to incorporate. Another major risk factor is that suitable ready-written packages are likely to be only available from the USA and written to comply with American regulations and procedures (as well as dollars and cents!). This could entail cost, time and difficulty penalties.

Recommendation

The consultant believes that the over-riding factor in making a recommendation is the high profile of this development and the need to preserve the good name of the London Stock Exchange and the City of

Consultant’s comments

This table takes the significant outputs of the three modelling exercises and places them in juxtaposition to facilitate their evaluation.

All the conclusions are qualified by the assumptions set out earlier. If any of these assumptions change significantly at anytime, a project review and iteration of the systemic analysis may be warranted.

4 Stage 3 of the systemic learning cycle: contextualizing your approach to the Taurus project 87

London. With this being paramount, the least risky option is, on balance, the best. The consultant, therefore, recommends that the open tender for three systems integrators to build competitive prototypes and winning tenderer to build pilot and phased implementation be adopted. Whilst this option is projected to exceed the desired time-scale, this should be a small price to pay for the knowledge that a low risk option with flexibility and breakpoints is going to be superior in the long run.

5 Stage 4 of the systemic learning cycle: managing the complexity of the Taurus project with the hard systems method

Having considered how you might use HS-method in your project (Activity 21) and read Trevor’s report on Taurus, I now want you to think about the stages Trevor went through to understand the complexity he was confronted by – and the techniques he used in the process.

ACTIVITY 23

Understanding Trevor’s approach.

Can you organize Trevor’s approach in terms of a hierarchy network? His method is obvious but what is the overall approach he has adopted and what tools and techniques has he made use of? Do you think the combination works? What is the reason for your thinking?

Is the HS-method stage by stage description in column 1 of your comparison matrix exemplified by Trevor’s work? Does your own attempt in column 3 make sense – can you see how each stage is represented as a separate stage in columns 2 and 3? Or do the stages run together?

Thinking back to the juggler in Block 1, can you apply the metaphor to Trevor? Can you identify with him being a practitioner? How do you think he felt about engaging with this material as a consultant? Has he produced an outcome that you feel develops your learning of Taurus? Are there areas that you feel he has not dealt with? Note down your reactions to these questions.

In the next section I will consider how Trevor has applied the HS-method and how relevant it is to the Taurus project. Before that, try answering the following SAQs.

SAQ 25

Show how the HS-method as applied to the Taurus project conforms to the learning cycle set out in Figure 9. How do the steps correspond to the structure and processes set out there?

SAQ 26

What features of the HS-method predispose it to be used systemically rather than systematically?

SAQ 27

Suggest at least two traps a practitioner could fall into which would make use of the HS-method non-systemic.

Learning Album

88 Block 2 Part 2 Using the hard systems method for managing Information Systems on the Taurus project

SAQ 28

Keeping in mind the specific requirements and tendencies of the HS- method, describe two contexts (these maybe IS or not) in which the HS-method way of exploring a problem would be of specific value.

SAQ 29

From your own experience describe a problem context in which the use of the HS-method would be useful. Set this out in terms of the HS-method cycle.

6 Conclusions on the use of the hard systems method for the Taurus project

Finally I want to review Trevor’s application of the HS-method to the Taurus project. I will set out some of my own reflections and conclude with some questions which you might like to consider as you develop your own course project.

First, Trevor set about his analysis of Taurus as a do-able exercise despite the apparent complexity – maybe this indicates his confidence as a long- time practitioner and teacher of the HS-method but his approach seemed to me to be overwhelmingly confident and sensitive to both the qualitative and quantitative dimensions. From my perspective as a reader of the analysis I felt that the context was made understandable in non- contentious terms by use of the systems diagrams and then developed into a process to be accomplished – very much a strength of the HS-method. Although Trevor had to be creative with some of the quantitative figures and data available to him, he fully demonstrated the application of the HS-method to the Taurus project.

Second, Trevor began his analysis by roundly indicating that his use of the HS-method is a ‘high-level’ exercise in outline. This is true – he takes a major overview of the material and of course is focusing on the opinions of the authors who we have included in the case study material. In reading the report it seemed to me that Trevor was aware that he was being asked to use HS-method in a slightly unusual manner (as a means to undertake a retrospective analysis). He seems to have focused on the elements of Taurus which would fit the analysis and not necessarily the elements of the original problem which might have needed analysis. He went into the elements where he felt his analysis would work. This is only to be expected and it is a good point to keep in mind – consultants and external experts will always give you their view through their own perspective. In this case I had tied Trevor by the terms of reference into the HS-method and he had to apply it. This did mean that he was looking for areas (and expecting there to be areas?) where the analysis would work well. Nevertheless, I found the analysis really useful in developing an understanding of one development of Taurus which could be undertaken.

Third, Trevor has demonstrated that the HS-method can be used to develop a logical, sequential and systematic argument for the development of an IS project according to an agreed mode of operation. This seems to me to be conclusive. It is borne out by his selection of routes to objectives and his analysis of the means. However I did feel that he has gone through

6 Conclusions on the use of the hard systems method for the Taurus project 89

the analysis in a rather linear fashion without much evidence of the extensive iteration that would result in an analysis done at the time and involving several consultations with the client.

Questions to ask in future of any context where you are thinking of using the HS-method, and especially your course project, include:

^ Where would you start with your analysis?

^ Would you use a more detached approach like Trevor had to or would you be actively involved in the situation?

^ Will your chosen approach and method be welcomed by the stakeholders (do they want to learn or do they want a fix from an outsider)?

^ Are you sure that the HS-method will be relevant to the chosen situation?

^ Could you show that the HS-method had advantages over alternative methods?

The HS-method is but one systems method and Trevor’s report represents but one analysis of an IS project. I will now build upon this analysis and look at the Taurus project again but this time through a soft systems lens in Part 3.

7 Summary In Block 2 Part 2 a range of HS-methods for planning and managing IS projects were noted, and their tendency to be systematic and focus on the technology rather than systemic and focus on the needs of the people involved. A specific IS, the London Stock Exchange’s Taurus project, has been introduced through original materials and the views of a number of stakeholders and authors presented. The HS-method has been described as one means to systemically analyse the complex situation described in this original material. A consultant has applied the HS-method to the Taurus project. His approach has been reviewed and considered in terms of its systemic quality. Throughout you have been encouraged to develop your own use of the HS-method as well as a critical appraisal of both the method and its application.

90 Block 2 Part 2 Using the hard systems method for managing Information Systems on the Taurus project

Part 3 Using the soft systems method for managing Information Systems on the Taurus project

1 The need to consider soft issues in Information System projects

Following the exploration and review of the HS-method presented in Part 2, we now move on and introduce the soft systems method (SS- method) as both a systemic and systematic form of inquiry. We then apply the SS-method to our main IS case study – the Taurus project. As with the HS-method in Part 2 there is also the opportunity to review a consultant’s use of the SS-method. Finally you will be able to reflect systemically upon use of the soft systems method through following the learning cycle.

The SS-method has been used widely over the years since it was first fully explained as a means to investigate messy situations in a book written in 1981 by one of its main progenitors – Professor Peter Checkland of Lancaster University. However, the action research programme that led to its development (and subsequent refinement as you will find out in later blocks) began some years earlier with the formation of a Department for Systems Engineering at Lancaster. Peter Checkland, in a talk he gave to the Open University Systems Society in 1996, explained the circumstances through which he came to recognize the need for a ‘softer’ approach to systems:

... Gwiylm Jenkins, the statistician who founded this department, always read the word ‘engineering’ in the broad sense of the word. You can engineer a meeting with someone, you can engineer a list of hostages, and it was that broad sense of the word engineering that Gwiylm intended to drive the work. When I was recruited into that department the research task, which was suggested to me, sounded a good idea. That research task was to find out, in action research in real situations, whether the methods of hard systems engineering, the methods you would use to optimize the output from a petrol-chemical complex, could simply be transferred into the human situations which managers try to cope with. That is what we set out to do in the action research programme.

... we will take Hard Systems Engineering as our approach. We will try to use it in management problem situations, and we will see what happens. What happened was that the methodology came apart in our hands. We found ourselves unable to use it, we found ourselves making a complete hash of it. But we tried to pick ourselves up and learn from what was happening to us and we found ourselves re-defining the systems engineering that we had started from and the re-definition was sufficiently radical that the approach came to be called something different, namely Soft Systems Methodology.

... I’ll describe very briefly the kind of experiences we were having when we tried to use systems engineering in management problem situations, and failed to do it. One of the first experiences I had at Lancaster came about when David Farrah, who was a director of

Simon writes ...

1 The need to consider soft issues in Information System projects 91

the British Aircraft Corporation, said to us: ‘the Concorde project is a mess’. Everybody knew that because it was a big issue in the newspapers at the time and successive British governments in the 1970s were very serious about cancelling it all. In which case the French said they would sue them for more millions than it would cost to carry on with it, and so on. David Farrah said: ‘We are in a real mess here. Just come into the project with your systems engineering approach and see what useful advice you can give to us’.

Dave Thomas, the chap I was working with on this, was a 34 year old engineer who had been working in Canada, as I remember, doing a Masters course as a way of getting back into employment on this side of the Atlantic. Dave Thomas and I went to Filton and found that what was happening at that stage in Concorde was that the French had got aircraft 001 in Toulouse and the Brits had got 002 in Filton in Bristol. These were the pre-production aircraft which hadn’t flown yet. But in the big shed in which they were building it at Filton, it looked like a complete aircraft. It was years late, it had already cost millions more than anticipated and so on.

Dave Thomas and I thought this was pretty straightforward. Thinking like systems engineers we said: what is the system of concern? It is the creation of this aircraft. What are its objectives? The objectives of that system is to create that aircraft within a certain time, at a certain cost, meeting a particular detailed technical specification under at least a couple of constraints: one that it doesn’t damage the environment unacceptably, and secondly that it has to get the air worthiness certificate from the Civil Aviation Authority or else the public won’t be allowed to fly in it. So we thought we could quite explicitly define objectives of the Concorde project in those terms and we sketched out what we would have to do in some rudimentary models if that was the system that you were wishing to operate in the real world.

It took us some time to appreciate that we just couldn’t get anywhere with those kind of models. We couldn’t engage the attention of the engineers actually involved with the Concorde project with that sort of model. It was after the first few weeks down at Filton when we came to realise the real major significance of the fact that this was the Anglo-French Concorde project and was created at a time when De Gaulle was President of France and of the British entry into the Common Market; and one of the motivations behind the project from the British side was to try and convince the French that perfidious Albion could be reasonable partners in a major technological enterprise which was going to prevent the Americans being the world leaders in at least one advanced technology. The politics of the Concorde project were an integral part of it. You couldn’t separate those out and just think about it as an engineering project because the politics affected everything that was going on in the project.

We realized how difficult it is to formulate objectives in human situations. In the technically defined problems for which systems engineering was developed then of course objective defining is part of the game; and if your job is to optimize this output then you can very precisely define the objectives in that plant. In any human situation this is a very difficult thing to do.

92 Block 2 Part 3 Using the soft systems method for managing Information Systems on the Taurus project

It was in order to address the failings of hard systems method to tackle situations such as that found in the Concorde project that Peter Checkland began to develop a method that encompassed the ‘soft’ perspective.

Today the SS-method is widely applied by a vast number of practitioners in a wide range of disciplines across the world. For example, I know of practitioners applying it to the health service in the UK, agricultural monitoring and evaluation projects in South Africa, change management issues in Nigeria and Information Systems development projects in the People’s Republic of China.

1.1 The reasoning behind soft systems thinking and practice

Before we look in detail at the SS-method you need to understand some of the underlying ideas which permeate soft systems thinking. The anecdote in Box 12 helps to illustrate some of these points.

Box 12 The grasshopper ‘problem’

A plague of variegated grasshoppers menaced the land in North Africa. Over a period of time all was laid waste. Cash crops were devastated as, locust like, the plague spread across the countryside eating everything.

The problem was clear – but how should the international community deal with it? The answer was to send in experts. The Food and Agriculture Organization of the United Nations (FAO) was called upon to send in a team of experts to analyse and solve the problem. What sort of experts does a situation of this type call for? Grasshopper eradication experts was the answer assumed by the international community. A team was picked and sent. It contained people who understood grasshoppers, people who understood pesticides, people who understood the effect of pesticides upon grasshoppers, people who understood the effect of pesticides and grasshopper upon crops. There were a lot of experts. One non-essential person was included – an anthropologist. Why? Did this person understand grasshoppers or pesticides or crops? No, but anthropologists do understand how to talk to people and this was an issue which was seen as having some incidental relevance and importance to the core business of the team.

The team arrived and got on with its job. This consisted of assessing the ways in which the maximum number of grasshoppers can be killed in the shortest time and the least cost. While the true experts get on with the job the anthropologist talked to the local people.

The scientists came up with a variety of scientific means to eradicate the problem for a certain cost and in a certain time; the anthropologist found that the ‘mess’ was not the mess first thought. Variegated grasshoppers are a delicacy of some considerable value and a rich source of protein. Whilst it is true they take feeding to gain maturity, the cost of devastation to the crops is small in comparison with the value of the abundant food supply which they subsequently represent.

First, soft systems thinking does not assume that problems are out there in the world in a real sense. Working from a soft perspective there are no objectively given problems. This does not mean that the world is not full of difficult and complex issues which need to be managed but it is important to realize that different people may see different problems in the same situation and come to different conclusions as to their nature. It is, perhaps, misleading to talk of the context as though it were objectively agreed upon and accepted by all parties and stakeholders. Rather it is more appropriate with soft systems thinking to describe those involved in messy contexts as problem owners – this makes a clear relationship

Simon writes ...

1 The need to consider soft issues in Information System projects 93

between the context and those who are experiencing it. A context is a combination of the external world together with the way that it seems to the observer or the participants. Different people may not only see the same situation as problematic in different ways but some may not see any problem at all in the given context (see for example the anthropologist’s view on the grasshopper ‘problem’ in Box 12).

Second, soft systems thinking assumes that problems are much less structured, and much messier than some users and advocates of reductionist science would accept. For example in the grasshopper ‘problem’ the anthropologist looks outside the boundary to the problem set by the technical experts – and finds a ‘mess’ different to that originally perceived. Indeed a key feature of many situations is that they are unbounded, unclear, and uncertain and that the observer may be unsure if there is a ‘problem’ except for those within the situation believing something is ‘not right’. This is why the term ‘problem context’ or ‘problem situation’ – rather than just problem – is used to describe what confronts the analyst.

A third consideration to keep in mind is that just as problem definition is a construct of our own creation, so are ‘solutions’ (as was evident in the variegated grasshopper case set out in the box above). A group of people may agree on the nature of a given problem, yet disagree (violently in some cases) as to what constitutes a solution. The aim is to move from the present state of affairs to a desired state of affairs when no one has a map to work from.

Fourth, it is important that the situation is investigated and analysed before any decision on the desirability of a specific form of solution or remedial activity is taken. In the box above, the solution (i.e. eradicate grasshoppers with pesticides) was arrived at before the situation was fully investigated. In this sense the role of the systems analyst (the title usually ascribed to the person attempting to understand the nature of a systemic problem) can be viewed, at least initially, as much more akin to a therapist than a technical expert. The analyst encourages participants or stakeholders in the existing context to examine their own perceptions of the context and its interconnections with others. Such a review will include an analysis of objectives, the role of the client within the context and the role of other stakeholders. The SS-method is concerned with what is meant by a problem and what action (new or pre-planned) would mean to those engaged in the context. This is a learning process and can be mapped on to the learning cycle.

ACTIVITY 24

Think of an occasion in your own experience (home or work) where your perception of the problem being presented was very different from the perceptions of other people in the context. For example, in Part 2 I asked you to develop your own understanding of the HS-method by applying it to a project such as re-arranging the garage. This might have led to you modelling a new garage layout by use of a map. However, other family members may not have thought the garage needed rearranging. Rather, their perception was that things were either fine as they were (‘Why do you want to put a car in there for goodness sake?’) or miss the point (‘This is all just junk – we need to burn the lot’).

Learning Album

94 Block 2 Part 3 Using the soft systems method for managing Information Systems on the Taurus project

When you have thought of an experience like this consider how the problem was resolved. Did an agreed view arise? Did someone arbitrate? Was the view of an external person taken? Did this view help? Do these kinds of occasions end up with people reacting negatively to each other and denying the value of other each others views?

Keep this activity in mind as you work through Part 3.

Having set out four fundamental distinctions between hard and soft systems thinking I will now describe the SS-method itself followed by a report from a second consultant – John Robson – using the SS-method to make a different analysis of the Taurus project. As with Part 2 where both the theory and application of the HS-method were explored in terms of the learning cycle, I will follow a learning cycle approach to:

^ reviewing the Taurus case study;

^ reflecting upon the SS-method;

^ knowing what happened in the Taurus case study using the SS-method.

^ reviewing how the SS-method could have been used differently in other situations.

2 Stage 1 of the systemic learning cycle: being systemically aware of the Taurus project

Go back to the notes and diagrams you made on the case study material in Part 2. Look at them again paying particular attention to:

^ the processes in which the decision making evolved in the development of the eventual failure;

^ identifying the main informal, and unexpected actors within the context, think about how certain personalities took decisions which affected the outcome of the study;

^ identifying the main qualitative and unexpected processes involved in the project;

^ the perspectives of the various actors involved.

ACTIVITY 25

What were the main qualitative and unexpected processes you identified?

What were the main qualitative and unexpected processes you identified and can you describe them in systems diagramming terms? For example, could you develop a spray diagram of the soft, informal and messy elements of the Taurus project. Is gender an issue? (Helga Drummond implies this on the tape.) What about the potential role of a big boss/leader?

3 Stage 2 of the systemic learning cycle: engaging with the Taurus project through the soft systems method

As with Part 2, I will first provide an overview and description of the SS- method and then the consultant’s report on the Taurus project using the SS-method. Unlike the various hard methods there is a single soft method, although three versions or expressions of it have been developed over the years by Peter Checkland and his colleagues (Checkland, 1981; Checkland and Scholes, 1990; Checkland and Holwell, 1998). There follows a brief description of the main features of the first version that arose out of

Learning Album

2 Stage 1 of the systemic learning cycle: being systemically aware of the Taurus project 95

several hundred case studies conducted on a consultancy basis in various business and other organizational settings. The description set out below is taken and adapted from that originally developed in the Open University by my colleague John Naughton in 1984 and based upon Peter Checkland’s 1981 book. This version is often referred to as the Mode 1, or seven stage, version.

I have focused on what I regard as the basic essentials of the method here. But you will return to later versions of the SS-method in later blocks and be able to use it for your project if you chose to.

The SS-method is a systemic approach to problem solving because it makes serious use of systems concepts but it can be applied systematically as it can be seen as comprising a number of stages. These stages are outlined below in Figure 15 (Checkland 1981, p. 163). In essence, the SS- method is a process of inquiry with a number of distinct stages, passage through which is usually iterative rather than linear (a concept you should be familiar with from the learning cycle).

ACTIVITY 26

What do you think SS-method is about?

Before reading John Naughton’s account of the seven stage SS-method, set out four or five ideas or expectations which you have of the method from what you have already read.

Real world

Systems thinking

1. The problem situation:

unstructured

2. The problem situation: expressed

6. Feasible, desirable changes

7. Action to improve

the problem situation

Root definitions of relevant systems

3.

4. Conceptual

models

5. Comparison of

4. with 2.

4a. Formal system

concept 4b.

Other systems thinking

Figure 15 An activity sequence diagram of the SS-method to problem solving

soft systems method (SS-method)

Learning Album

96 Block 2 Part 3 Using the soft systems method for managing Information Systems on the Taurus project

Once you have done that, as you work through the rest of this section, undertake a similar three column matrix activity to that which I suggested in Part 2 – to compare this description of the SS-method with the use of it by the consultant and your own use of it:

Elements of SS-method (Section 3.2)

John Robson’s use of each element (Section 4.2)

My project use of SS-method (e.g. rearranging the garage)

The problem situation unstructured

Rich pictures, issues and primary tasks

Relevant systems and their root definitions

Conceptual models (CM)

Comparison of CM with rich picture

Debate of stakeholders

Implementation of agreed changes

3.1 Overview of the soft systems method

Don’t worry if you don’t understand all of the terminology in this overview. The meanings of the terms are explained in the detailed account of the method in Section 3.2. The soft systems terms are italicized where they first appear so it is clear which these terms are.

Stage 1 of an inquiry begins, not with a ‘problem’ as such, but with a ‘mess’, or with an organizational setting in which someone thinks problems may reside. This can often be something rather general and vague, such as ‘We don’t have a mechanism for deciding what sort of products we should be making in five years’ time: can you help?’; or ‘There’s something wrong with morale in the sales department’. And even if the analyst is initially faced with what appears to be a clearly identified problem (like, for example, the statement ‘Our warehouse is too small for our present scale of operations: we want to decide where to build a new one’), the analyst will usually want to do some further exploration of the company setting before being committed to the view of the situation implied by the initial statement. The basic idea is that every problem exists in a context, and that context may be perceived differently by different people.

The first task, therefore, is to assemble a representation or picture of this situation which is rich in both quantitative or factual, and qualitative and subjective information (i.e. a rich picture). The analyst will try to portray the situation without imposing an a priori analytical framework upon it. In particular, the temptation to see the situation as a particular ‘problem type’ will be resisted.

Having assembled a rich picture of the situation (stage 2), the analyst then reflects upon it. In doing this, however, the analyst will not look for specific ‘problems’ for which particular ‘solutions’ can be proposed. Instead, the analyst seeks general patterns or aspects (sometimes called ‘issues’) which express or encapsulate characteristics of the situation. This

John writes ...

3 Stage 2 of the systemic learning cycle: engaging with the Taurus project through the soft systems method 97

leads to stage 3 and a search for systemic ways of viewing the situation – ways which are articulated by naming hypothetical systems, known as relevant systems in the terminology of the method.

The point of naming such systems is to try to find some potentially fruitful way of viewing the problem situation by thinking up some notional systems which might bear on significant aspects of it. Different relevant systems may be based on different Weltanschauungen (world-views). For example, if the problem situation was an English pub, two possible relevant systems might be: a system for initiating adolescents into the adult culture, and a drink-providing system. The first provides a rather unexpected view of the situation, while the second is rather obvious.

Many other systems might also be ‘relevant’ to this particular case. The criteria of relevance are, of course, ultimately subjective, and the skill of choosing systems which yield fruitful analyses is an important element in the craft knowledge of the business.

The identification of relevant systems is a crucial stage in the inquiry, because it forces the analyst to choose to view the situation in a particular way. There is, however, nothing to prevent them taking several different views, and working through the subsequent stages of the method with each. The remaining stages are, in fact, basically designed to trace the logical consequences of taking the particular view encapsulated by the adopted relevant system. This is achieved by fleshing out the initial notion of the system (first (stage 3) by describing it precisely in words (in a root definition) and then (stage 4) by deriving an activity model (called a conceptual model) which contains all the essential activities which the notional system would logically have to perform. (This model is a representation of an activity-system, that is a system whose elements are activities.) This abstract model is then, in stage 5, compared with what is perceived to exist in the actual problem situation. In carrying out each of the stages it will usually be necessary to iterate: for example, having obtained the root definition you may decide that it is necessary to amend your relevant system, and then to re-define the amended version. In that sense, the process of inquiry is one of continual learning rather than a series of cut-and-dried stages.

The comparison stage will, in general, throw up discrepancies between the real-world situation and the abstract model of stage 4. The outcome of the comparison stage thus generates two kinds of outcome: first, a reassessment of one’s views of the problem setting, and in turn perhaps some different ideas for relevant systems; and secondly, what might be called an agenda of possible changes which, in stage 6, is debated with the people who are involved in the problem situation. The purpose of the debate is to identify changes which are agreed by the participants to be both feasible and desirable. Any changes which survive this process of scrutiny are then carried forward to the final stage for implementation (stage 7).

This method appears rather complicated at first sight, and experience suggests that many people are initially thrown by its circular structure and rather idiosyncratic terminology. But if one penetrates beneath this surface, the underlying logical structure of the method is really quite simple.

What happens is this: the analyst looks at a complex situation and tries to represent it in all its complexity without jumping to conclusions about what ‘type’ of situation it is or about what is ‘the problem’. Then the

98 Block 2 Part 3 Using the soft systems method for managing Information Systems on the Taurus project

analyst makes a conjecture that ‘it would be helpful to view this situation in terms of a ... (relevant system)’. This system may be an issue-based or primary-task one; whatever it is, its purpose is to provide an abstract idea which, though derived from the problem situation, is also detached from it in some way.

This notional system is then refined, until the analyst has something fairly detailed which can be compared with the perceived reality of the situation. This is done by building up a model of what the system would logically have to do if it were to be the system the analyst has defined. Thus if the English pub had been conceptualized as an adolescent-initiating system, the analyst would have to build up a model of what a system for initiating adolescents into the adult culture would, logically, have to do. Comparing this model with the actual pub situation would then yield some ideas of how effective the English pub is as an initiation system, together with an agenda of possible changes for further debate.

The point of developing a fairly detailed, logically derived model is that it forces the analyst to trace the logical consequences of their chosen way of viewing the situation. These consequences are then discussed with the people involved, and they, rather than the analyst, are the ones who decide whether the changes suggested by the earlier analysis are worth implementing. If (as sometimes happens) those involved do not think that any of the suggested changes are both feasible and desirable, then this is effectively tantamount to saying that they do not agree that the relevant system which generated them is, in fact, ‘relevant’ – in which case the analyst will have to go back and choose a different system. The analysis process is then repeated again.

Although Figure 15 represents the method as a sequence of stages, progress through them is likely to be heavily iterative. Thus, formulation of a root definition may lead to second thoughts about the relevant system on which it is based, in which case the analyst may have to go back and reconsider the system.

Similarly, initial attempts to construct a conceptual model (stage 4) may highlight problems with the root definition (which in turn may reflect a central ambiguity in the relevant system), in which case it may be necessary to return to stage 3. And so on; each stage is, in a sense, a test of the usefulness of the ones that have gone before.

3.2 The stages in the soft systems method

This section takes you through each stage of the method in some detail.

Warming up

Before embarking on a particular inquiry, there are two points which you must get absolutely clear.

The first concerns your role. The SS-method evolved in a management consultancy environment, and draws much of its legitimacy from its record of practical application. But it is different from some other approaches to consultancy in one important respect, namely that the soft systems analyst does not see himself as an ‘expert’ in particular problem types. The analyst is not, in that sense, like an accountant or a simulation modeller – a professional whom one would call in if one had an accounting or a modelling problem. The soft analyst will, in general, know little about the

3 Stage 2 of the systemic learning cycle: engaging with the Taurus project through the soft systems method 99

detailed nature of the activities and tasks of the organizations which seek help. What the analyst does know about is how to assist people to think rigorously about their difficulties, to see them in different lights, and, the analyst hopes, to come to views about them which will make beneficial change possible. The analyst is, in that sense, some kind of catalyst, or change agent, or therapist. For example, relationship counsellors will not issue detailed guidelines to couples who seek advice. Instead they encourage both parties to express and explore their perceptions of the situation. In a similar way the soft systems analyst will seek to bring out and build upon the perceptions of the people they are trying to help.

This has lots of implications, most of which we will encounter later. But perhaps the most important one is that, as a soft systems analyst, you are not detached from the problem situation in the way that, say, an accounting consultant would be. On the contrary, once you decide to get involved, you become part of the problem situation, for once the analysis gets under way, the inquiry process itself will start to affect the situation. This means also that you should try to be explicit about your goals and objectives, and about the reasons why you have chosen to become involved.

The second thing you should try to clarify is the distinction between three other roles relating to those members of the organization with which you are dealing. These roles are: the client, the problem-solver, and the problem owner.

In a hard systems analysis, these roles usually present few problems. The client of the study is usually (or can be taken to be) the problem owner, and the analyst is the problem solver. But experience with soft systems analysis suggests that it is important to separate these roles in the following way:

The client is the person who causes the study to happen in the first place. Without the client there would be no systems study.

The problem solver is the person who hopes to do something about the situation which is perceived to be problematical. This could be the client, but need not necessarily be. Given the general therapeutic orientation of the soft systems approach, the problem solver is unlikely to be the analyst. (Think of the relationship counsellor again.)

The problem owner could be a variety of different people in the situation. In many soft systems studies one should, at some stage, experiment by allocating this role to a number of different people (or groups). For example, in studying an industrial company, it may be illuminating to experiment by regarding (successively) managers, workers, customers, suppliers and shareholders as the problem owners. Doing so will often yield usefully different perspectives on the problem situation.

Having sorted out these roles in your own mind – at least in a preliminary way – you are now ready to move to stage 1 of the method – what is called ‘the problem situation unstructured’.

Stage 1: The problem situation unstructured

Note the use of words – ‘problem situation’ rather than ‘problem’; ‘unstructured’ to indicate that you are going to look at this situation in as open a way as possible, without trying to precast it in a particular mode. What you are trying to avoid, in other words, are statements like: ‘Ah yes,

problem situation

100 Block 2 Part 3 Using the soft systems method for managing Information Systems on the Taurus project

here we have a queuing problem’; or ‘This is clearly a personnel and recruitment problem’. Indeed, at this stage you are trying to avoid thinking in terms of a or the problem at all.

There are several good reasons for this forbearance on your part. In the first place, when you first encounter the situation it may not be at all obvious what is problematic about it. Secondly, even if it is clearly problematic, what you are dealing with may be a mess – a system of interrelated problems. And thirdly – and perhaps most importantly – the people involved in the situation will inevitably have different views about it, views which lead them to advocate their own candidates for the role of ‘the problem’. As a soft systems analyst, you are obliged to take this very seriously indeed, for you are operating on the premise that differences in perceptions may be a determining feature of the situation.

It is easy to say all this, but very difficult to put it into practice in a real study. The reason is that ignorance and uncertainty are very unpleasant feelings to have. Any real world problem situation will appear immensely complicated at first sight. You will feel intimidated by its complexity, and will long for some way of simplifying it – some way of imposing order on the chaos. You will feel threatened and inadequate, anxious about how you can demonstrate your competence, about how you can demonstrate that you are ‘on top of’ the situation. But resist the temptation. Stick with the approach.

In this stage, you will also need to make some practical and administrative arrangements. Much of the next stage, for example, will entail information gathering, and much of that information will come from conversations with people. You will therefore need to negotiate access beforehand to the people to whom you may wish to talk, and also perhaps to sites, locations, offices or plants which you wish to visit. You may require a quiet office or work-station, and access to telephone, fax, e-mail etc. Likewise, you will have to decide how to record the information you obtain from conversations. Will you make notes, or not? Record the conversation, or not? (Recording the conversation makes some people nervous and uncommunicative.) And so on. Most of these administrative matters require little more than common sense to sort out, but they will not sort themselves out. They require planning and action on your part. I know of a study where stage 2 was seriously hampered because nobody had bothered to inform the trade unions on-site that a soft systems study was being mounted, and that this would require the analyst to observe activity on the shop-floor of one of the organization’s factories.

Stage 2: Rich pictures, issues and primary tasks

The method is concerned with getting from finding out about a problem situation to taking action to improve it (if the finding-out process has led to the conclusion that action can be taken), and the idea is to get from finding out to action by doing some systems thinking about the situation. To get started on this you need some efficient, economical and illuminating way of summarizing or representing the situation in all its complexity – a rich picture as introduced in Block 1 and used in this block to illustrate the FTS case study.

As you know the next thing to do is to sit back and reflect upon your picture. You now have to ask yourself: what does it mean? You may have to put some distance between yourself and the picture-building process, if only because it is always difficult to analyse critically something that you

3 Stage 2 of the systemic learning cycle: engaging with the Taurus project through the soft systems method 101

have just finished. So it may help to put the picture on one side for a day or two. Alternatively, it may be helpful to explain your picture to a friend or colleague – someone who has not been involved in its construction. Whatever tactic you choose, its purpose is to help you to stand back a little and examine the significance of the picture of the situation that you have drawn.

One way is to scrutinize the rich picture looking for two important aspects of the situation. The first of these are primary tasks. These are the tasks which the organization in question was created to perform, or the tasks which an enterprise must perform if it is to survive. Thus, in a study of the Management Services Department of a large manufacturing company, the primary task of the department was identified as:

Being very knowledgeable about the managing of a business system in a turbulent environment in order to be able to provide appropriate intellectual services to support the management process.

Searching for primary tasks is thus a way of posing (and answering) the question: what is really central to this problem setting?

The second aspect of the situation worth looking at involves issues. These are the topics or matters which are of concern, or which are the subject of dispute: the (often unstated) question-marks hanging over the situation. In the case of the Management Services Department mentioned above, for example, an important issue concerning the legitimacy of the department itself was identified. Because it was not a direct wealth generator within the company, the department had continuously to justify its existence by demonstrating that the cost of its efforts was less than the alleged benefits which flowed from them. Formulating the issue in this way helped the analysts to come to grips with an important, but latent, factor in the department’s situation.

Having searched for, and hopefully identified, the primary tasks and/or issues in the problem situation, you have reached the end of stage 2 of the method. Before moving on to the next stage, however, you should look back at the diagram (Figure 15) which summarizes the approach. On that you will see that you are now poised to cross the dotted line which runs across it separating the ‘real world’ from the ‘abstract world’ of systems thinking.

Stage 3: Relevant systems and their root definitions

Having represented the situation pictorially, and reflected upon it at some length, the next thing to do is to try and think up a systemic way of viewing it. You do this by imagining and naming what in the jargon of the method is called a relevant system. This is a system which is, in some way, relevant to the problem situation in the sense that it will yield insight into the situation when it (the system) is described more fully.

Now I know that sounds a bit circular. The reason it does is because the concept of a relevant system is rather subtle. That does not mean it is vague – just that it is difficult to express succinctly in words. Fortunately, however, it is easy to exemplify, so let us approach it that way.

To continue an example we discussed earlier, suppose your problem situation were a stereotypical ‘traditional’ English pub. Your rich picture shows:

primary task

issues

relevant systems

102 Block 2 Part 3 Using the soft systems method for managing Information Systems on the Taurus project

^ the clientele are predominately adult, male sports fans;

^ the pub operates under a tight framework of legal restrictions;

^ children are politely but firmly excluded if they come in; and the landlord on occasion refuses to serve some young people on the grounds that they are under age.

What kind of relevant systems might you name in relation to this situation? Well, an obvious one is a drink-provision system. Another is an adult recreational system. Another is a neighbourhood social system. Yet another is a controlled sales-outlet for brewery and distillery products. These are all examples of relevant systems, but they are not very startling. Suppose however, that you reflect on your picture of the pub situation a little more and come up with the idea of the pub as an adulthood- affirming system. This captures the idea that one of the reasons why pubs are important in British culture stems from the fact that, by law, they must exclude minors – a fact which intensely annoys many young people – and, incidentally, enhances the status of drinking alcohol in successive generations of teenagers. This may not, in the end, be a very useful relevant system, but at least it is an unusual way of looking at the situation.

The pub example is a hypothetical one: let us take a look at some relevant systems drawn from real-life studies. In one such study, conducted in a large publishing firm producing a range of consumer magazines, three different relevant systems were considered in the course of the analysis.

The first, described by its author as ‘rather flat-footed,’ was: a system to publish, print and sell, as a commercially lucrative activity, a single consumer magazine. This was, of course, rather different to what actually went on in the company, which was to publish, print and sell a large number of magazines, and the notion behind the relevant system was to see whether regarding it as a one-magazine process would yield any ideas about its problems.

The second relevant system was rather wider in its scope: a system to decide whether to publish one magazine rather than another. Clearly, this kind of assessment and appraisal activity went on within the organization, but perhaps not in such an explicit way. Again, the idea behind the relevant system was to see if naming it (and developing, in subsequent stages) would yield some insight into its problems.

A third (historic) relevant system was much more off-beat: a system to bring about communication between the two dominant cultures within the organization – those of the print workers on the one hand, and the journalists and other editorial staff on the other. What this relevant system tried to get at was that the norms, expectations, values and working conditions of these two groups of staff were very different; much of the trouble within the British newspaper and magazine industry at that time (in the early 1980s) stemmed from this divide between them.

A more current example could be: a system to bring about communication between two dominant cultures within the organization (between professional and clerical staff). Again the norms, expectations, values and working conditions of these two groups can be very different, and many of the problems that can adversely affect the work of both stem from the lack of understanding and between the two groups.

3 Stage 2 of the systemic learning cycle: engaging with the Taurus project through the soft systems method 103

The first question that many newcomers to this approach ask when they encounter the concept of a relevant system is: ‘relevant to what?’. The answer is: relevant to the process of improving the problem situation. You may not find that very illuminating, on the grounds that you will not know whether a particular system was ‘relevant’ until you have gone through the analysis and seen whether the problem situation was, in fact, improved as a result. I sympathize with that view, but the difficulties in practice with the concept are less than you would imagine from just talking about it in the abstract. For all you can do anyway at this stage of the analysis is to conjecture that a particular way of looking at the situation in systemic terms will turn out to be useful in the end. You may turn out to be wrong, but you have to start somewhere, and it has been my experience that people usually recognize a really insightful relevant system the minute it is named simply because of the unexpected perspective it provides.

But even if you can never be absolutely sure that your chosen system is ‘relevant’, you can usually be sure when it is not. For you can declare it irrelevant if, having gone through your analysis and held a debate with the people involved in the situation, they reject the ideas for change suggested by the analysis. What such a rejection implies is that the actors in the situation did not regard your system as relevant – in which case you have to go back and choose another, hopefully ‘relevant’, system and go through the process again.

I am sure that this sounds like a risky prospect, because it implies that you could do a great deal of work only to have your analysis rejected as irrelevant at the closing stages. Actually, it never seems quite so risky in practice, because if you use this method rigorously you will rarely become so detached from the perceptions and likely responses of the people whose problems you are studying as to put yourself completely out on a limb. Nevertheless, a sensible insurance policy to adopt is that of taking not one, but several, relevant systems and developing them in parallel.

Doing this will not involve doubling or trebling the amount of work involved, because the biggest task in the whole process – the gathering of the information required for the rich picture – has already been done, and the picture will be common to all the relevant systems you choose to explore.

Another question that is sometimes asked is why does it have to be a relevant system. This is because the notion of system has connotations of purposefulness, organized structure, on-goingness, control – and it is these attributes which the approach seeks to utilize in later stages.

What kind of system is a relevant system? Is it concrete or abstract, designed or natural? It is, in fact, what is called a Human Activity System – a system whose elements are human activities. A relevant system, however, is not a system to ‘solve’ the problems inherent in the situation from which it stems. Nor is it a system which anyone is ever going to design and implement in the real world. Its function is simply to provide an alternative way of viewing the problem situation which, when developed further in succeeding stages of the methodology, will provide the analyst with a sharp comparison between it and what is observed to go on in the real world situation. A relevant system, in that sense, is an entirely abstract idea. No one – neither the analyst nor anyone else – is ever going to build it.

104 Block 2 Part 3 Using the soft systems method for managing Information Systems on the Taurus project

However you arrive at them, it must be conceded that relevant systems are still rather vague and general ideas. To make use of them, they must be refined and developed – sharpened up – to the point where they can really shed some comparative light on the problem situation.

Root definitions

The first step on the road towards a properly developed relevant system is to describe it as precisely as possible in words. You do this by formulating what is called a root definition.

Although this is a technical term for a technique within the method, its meaning in fact is quite close to what you might deduce from everyday usage. ‘Root’, in this context, means essential or fundamental; ‘definition’ means precise description. So a root definition is a precise verbal description of the essences of the processes implied by the relevant system. Thus a root definition of a library might describe it as ‘an information services provision system’, or ‘a system to meet the needs of accredited users for information services’. Or, to take an example drawn from life, a study of the role of a community centre in a Northern English city came up with the following definition of one relevant system:

An institution encouraging and helping community action aimed at development of the community’s own resources.

What this definition expresses is that the essence of the system is encouraging and helping; these are the fundamental processes implied by this particular system, and the root definition tries to capture and express them in as economical and pithy a way as possible.

Though root definitions should be pithy, they cannot always be short and sweet. Here is an example of a much more extended definition, this time from a study of the Social Services Department of local government (in this case a County Council):

A department to employ social workers and associated staff to build and maintain residential and other treatment facilities and to control and develop the use of these resources, so that those social and physical needs of the deprived sections of the community which Government statute determines or allows, to the extent to which the County Council, as guided by its professional advisers, decides is appropriate, are met within the annual capital and revenue constraints imposed by the Government and the Council.

Personally, I think this particular definition is too long and involved. It suggests, in fact, that its authors have spent more time reading pamphlets from the Government department responsible for Social Services than is good for their prose! And they assumed that a root definition has to be achieved in a single sentence (it does not, though many are). It does, however, attempt to spell out in a precise way what the authors thought their system was. It is a system to employ certain people to build and maintain certain facilities and to control and develop the use of these resources in such a way as to meet certain obligations within certain constraints. It may be long winded, but it is at least clear about what the essence of the system is.

How do you formulate root definitions? The only way, I am afraid, is by old fashioned trial and error. You look at your relevant system (which should, anyway, contain the essence of the system you have in mind) and try to describe it as fully and as concisely as possible. Since these two aims

root definitions

3 Stage 2 of the systemic learning cycle: engaging with the Taurus project through the soft systems method 105

(conciseness and full description) are to some extent in conflict, this means that you will have to wrestle with different levels of detail, and with different ways of expressing things. The way to do it is simply to write something down and then try to improve it in successive versions until you have something which describes the relevant system you have adopted. If you can discuss the definition with other people, so much the better. In this business, two heads are always better than one.

CATWOE checklist

A more difficult question to answer is: ‘How do I know whether my root definition is complete?’ There is no absolute criterion, but over the years a set of guidelines have emerged which are often useful. These are expressed in the form of a mnemonic, CATWOE. The letters stand for various aspects of the definition which you should check.

C stands for ‘customers of the system’. This is potentially confusing, since it does not mean customers in the ordinary commercial sense. In this context, ‘customers’ means those who are on the receiving end of whatever it is that the system does. Who are its victims, or beneficiaries?

A stands for ‘actors’, meaning who (not individuals necessarily but types of people) would actually carry out the activities envisaged in the notional system being defined. Would a particular activity require professionally qualified people to carry it out, for example? Or could anyone do it?

T stands for ‘transformation process’ – what the system does to its input(s) in order to transform them into output(s). This is the most important single feature of the definition, and the one which is most frequently fudged by beginners.

W stands for our old friend, Weltanschauung or world view. Using this criterion forces you to ask whether your definition specifies (or needs to specify) the Weltanschauung which makes your system ‘relevant’. Using the W part of CATWOE forces you to be more explicit about the worldview which guides your chosen way of viewing the problem situation.

O stands for ‘owner(s)’ – who have sufficient power over the system to cause it to cease to exist.

E stands for ‘environmental constraints’. Asking about E in your definition means asking ‘what constraints does the system take as given?’ Thus, if you were studying a library, and there were no E-constraints, you would be free to couch your relevant system in terms of ‘an information processing’ system or an ‘information services provision’ system (of which a library is just one real-world manifestation – a database would be another). But if your study is being conducted in a context, which deems it essential that a library must continue to exist, then this would become an E-constraint on the root definition.

How to use CATWOE

Some people think that the way to use CATWOE is to work through each element, and add the missing bits to the root definition as you go. Our experience, however, is that this can lead to definitions which are rather cumbersome and legalistic. The real justification for CATWOE – and the source of its power – is that it forces you to ask searching questions about the definition you have drafted. It requires you to ask: ‘Does my definition include C (or A or T or W or O or E), and if not, should it?’ In the case of T, the answer should always be yes, but for the others the answer may

CATWOE

T552

You should read carefully the section on input-output

diagrams.

106 Block 2 Part 3 Using the soft systems method for managing Information Systems on the Taurus project

be ‘no’. Even if it is you should ask the question all the same. Then, at least, if you leave something out, you will do so consciously and deliberately rather than inadvertently.

Stage 4: Conceptual models

You have now reached the point where your relevant system has been defined, as precisely and concisely as possible, in verbal terms. In other words, you have now stated what your system is. But that still is not detailed enough for comparison with what exists in the problem situation, so you need to take the elaboration of the system one stage further: you have to describe not just what the system is, but also what it does. This is done by building an activity model of the system – a model of the activities or processes which, logically, must go on if the system is to be the one described in the root definition.

The model you build for this purpose is called a conceptual model.

When you think about it, the term ‘conceptual model’ may seem tautological, in the sense that any abstract model will, by definition, be a conceptual one. I think the term was chosen to hammer home two vital points. The first is that the model is indeed a purely abstract one. It is not a picture of some real-world system; nor is it a system which someone is going to try to build in the future. The second point is that the model is derived from the root definition using only the rules of deductive logic. It is an attempt to trace (in activity terms) the logical consequences of picking the system which you have designated as being ‘relevant’.

Guidelines for building conceptual models

1 The model is a model of a human activity system. Its elements are therefore activities, and will be represented on paper as verbs. The modelling language available to you for constructing the model is therefore all the verbs in the vernacular in which you are working. (For most of us, that will be English. But it could be any other language the analyst speaks fluently.) So the first thing to do is to scrutinize the root definition carefully and write down the list of verbs which you think are implied by it. Thus if your root definition described ‘a system to transform raw material into finished product’, that implies – logically – at least two activities: ‘obtain raw materials’ and ‘transform into finished product’.

2 Having got your list of verbs, arrange (or rearrange) them into a logically coherent order. In the above case, for example, the activity ‘obtain’ would logically have to precede the activity ‘transform’.

3 You ought to aim to have a complete account of the system in a smallish number of main activities – somewhere between 6 and 12 is what I would aim at. (For beginners, the guideline is: the fewer the better.)

4 Having arranged your main activities into a logical sequence, next examine each in turn, asking whether it logically implies its own set of subsidiary of back-up activities. If the answer is yes, write these down as verbs, and arrange them in logical order around their front-line activities. Thus, the main activity ‘obtain raw materials’ might imply secondary activities like ‘specify quality and delivery requirements’, ‘identify suppliers’, etc.

conceptual model

T552

You should read carefully the section on conceptual models in T552.

3 Stage 2 of the systemic learning cycle: engaging with the Taurus project through the soft systems method 107

5 Your model will now have clusters of primary and secondary activities. Scrutinize the clusters carefully to see whether some have functional points in common. For example, if you have activities involving, say, monitoring and target-setting, then it may be reasonable to group them together as a control sub-system. Other sub-systems may also suggest themselves.

6 In building your model, you are not allowed to introduce any ‘real world’ considerations into it. You are required only to deduce what is logically implied by the root definition – and nothing else. Thus you are not allowed, for example, to put the names of real world departments or entities into the model. Because the process of model building is supposed to be a purely logical one, it could notionally be carried out by a chimpanzee trained in the processes of formal logic. Ignoring the considerations of the real world is, however, easier said than done, and there is a noticeable tendency for conceptual modelling to slip back into the construction of models of systems known to exist ‘out there’.

The requirement that one avoids real-world considerations may seem perverse, but there are two good reasons for it, both of them concerned with keeping the conceptual model as detached from the problem situation as possible. The first is that when one makes the transition from stage 2 to stage 3, one crosses into the abstract world of systems thinking. The point of doing that is to develop – using systems ideas – an alternative view of the problem situation which can be compared with it in due course. This alternative view is embodied in the conceptual model, and if it is to remain genuinely detached from the actual situation, then it should be as untainted as possible by the considerations which apply in that situation.

The second reason for excluding the real world relates to the distinction between what one might call ‘whats’ and ‘hows’. The model is constructed in terms of ‘whats’ – activities specifying what, logically, must go on in the system you have defined. But the model should not be concerned with, or specific about, how these logically required activities should be carried out; that is a matter for discussion much later in the process, if at all. ‘Whats’ are general and belong to the world of abstractions. ‘Hows’ are specific, real-world ways of carrying out ‘whats’. Thus a digital computer is a ‘how’ in relation to the ‘what’ called ‘information processing’.

7 The logical nature of the relationship between root definition and conceptual model means that it makes sense to think about definitions and models as linked pairs. Since all the stages of the method (including this one) are iterative in any case, what you will probably find yourself doing is going back to revise the definition as you struggle with the construction of the model. There is nothing necessarily wrong with this, so long as you make sure that the model and its definition are a logically defensible pairing, and that you are not simplifying your root definition simply because of the difficulties of constructing a complex conceptual model.

Stage 5: Comparison of conceptual model with rich picture

With this stage of the method, you cross back over the gap which divides the top and bottom halves of Figure 15. What that means in practice is that you are leaving the abstract world of systems thinking, and bringing

108 Block 2 Part 3 Using the soft systems method for managing Information Systems on the Taurus project

your (now highly developed) relevant system back into the real world. The comparison stage involves overlaying, as it were, your abstract model on the problem situation as you have represented it, and drawing some inferences from the comparison between the two.

What do you expect to find by doing this? Well, in general terms, you expect to find some similarities and a lot of apparent differences. To illustrate this, let us take an example. Suppose the problem situation was in a library, and that the relevant system you adopted was ‘an information-services provision system’. This you would then have developed, via a root definition and a conceptual model, into a model which would embody a detailed picture of what an information-services provision system would logically have to do. You then compare this with your rich picture of the library, and what do you find?

As I said, you find some (perhaps many) similarities. You find that some of the processes which you decide must, logically, go on, do in fact go on in the real world situation. And that is not surprising, for most librarians appreciate that they are in the information business. But you may also find that there are significant differences between the model and the real situation. You may, for example, find that some of the activities which your model deems essential do not, in fact, go on in the library. There may be a very good reason why they do not – shortage of money, perhaps, or of staff, or of space; the staff may be poorly trained, unenlightened, or downright incompetent. Whatever the reason for the omission, the significant thing is that your comparison has highlighted it. And it prompts you to note that certain activities do not happen, and to ask whether they should. It is not for you to answer that question, by the way – that is for other people, and another stage in the inquiry process (see stage 6, later). But it gives you an item on an agenda of possible changes that you will take forward with you to the next stage.

How to carry out the comparison stage

People do it in various ways, but they all seem to adopt strategies which differ essentially only in being more or less structured.

The least structured, most intuitive, way of doing it is to go away from the problem situation with the conceptual model and the rich picture, shut yourself up for a day and think about the implications of the conceptual model and the rich picture together. Ask yourself questions like: how does the real world operate, and how does the model operate? Where are the two different, and why? And so on.

The following are some more structured ways of doing the comparison:

1 Take the model and its structure and activities and use it to define a set of questions which you specifically answer from the real world situation. Here is an activity in the model: does it happen in the real world? If so, who does it, and why? What is the history of it in the real situation? Why is it done the way it is? Is there a particular reason for doing it this way? In other words, you use the conceptual model as a way of arriving at a set of questions which you then try to answer on the basis of your knowledge of the real world situation.

2 Another way is to imagine the conceptual model operating and look at something that would happen according to the sequence of activities in the model, and then compare that with how those activities (or their closest counterparts) would – or have – happened in the real situation.

3 Stage 2 of the systemic learning cycle: engaging with the Taurus project through the soft systems method 109

In a study in an aircraft company, for example, the conceptual model was of a system for carrying out the task of designing and producing a particular new type of aircraft. The comparison stage was done by taking a small part of the aircraft structure – actually the engine air- intake – and looking at how the model would have caused this to be designed and produced. The analysts then looked in detail at how the intake had been designed and produced in practice.

3 Probably the most structured way to conduct the comparison stage is to construct, from the rich picture, a model of the real world situation which is structured – as closely as the situation will allow – in an analogous way to the conceptual model. If this can be done successfully, one winds up with two models which, if drawn on transparent sheets, can then be overlaid on one another. This method, however, will only work for situations which are already fairly well- structured, and is probably best left for those.

However you choose to do it, it is vital to remember that the purpose of the comparison stage is to set up a debate with actors in the problem situation. For that you will need an agenda, so the final output of this stage is the production – on overhead transparencies, flip charts, blackboards or ordinary sheets of paper – of such a document on the general lines of Figure 16.

Activity in conceptual model

Present in RW

situation? Comments Includeon

agenda?

No

YesNo

coordination

Parts of the activity already done,

but no

Done by sub-librarian

on a monthly basis

Yes

A1

A2

etc. etc. etc. etc.

Figure 16 Drawing up an agenda at the end of stage 5

Before proceeding to stage 6, it is important to be clear about what is and is not admissible as part of the agenda of possible changes. The agenda is really a series of topics for discussion. The items on it should always be couched in general terms of ‘whats’ – what activities are missing, or problematical, or questionable, or whatever? – and never in terms of specific ‘hows’. Thus the agenda could include a statement like ‘some systematic way of centrally processing order information seems to be necessary’, but never statements like ‘you need a computer’. The reason for this is that a computer is just one possible ‘how’ for achieving the ‘what’ which your comparison has highlighted. There may be other, non- computerized, ways of doing the same thing, and focusing on specific ‘hows’ is the first step on the slippery slope towards recommending particular technical fixes.

110 Block 2 Part 3 Using the soft systems method for managing Information Systems on the Taurus project

Finally, it is worth observing that, as in each preceding stage of the approach, the comparison stage may cause you to change some of your earlier views. It often happens, for example, that the first thing the comparison highlights is a specific area of ignorance about the problem situation – in which case you might need to go back and fill in the blind spots on your rich picture. It can also happen that doing the comparison causes you to rethink your views of the situation, perhaps even to the extent of causing you to change your relevant systems (and everything else that needs to be changed as a result).

Stage 6: Debate with stakeholders involved in the situation

Those involved include those in the roles of client, problem-owner(s) and problem-solver(s), and probably other stakeholders as well. The purpose of this stage is to conduct a structured discussion with the actors about the ideas that are now starting to emerge from the analysis. The device used to structure the debate is the agenda. In the discussion, you will be putting to the other participants some ideas about possible changes in the problem situation and trying to identify those ideas which are agreed by the actors to be both systemically desirable and culturally feasible.

Both criteria are important, and only changes that satisfy both should be considered for implementation. Systemic desirability simply means that any change to be implemented must make sense in systems terms: it must not violate, contradict, or run counter to the systems thinking that has gone into the formulation of the root definition and the construction of the conceptual model. Cultural feasibility asks whether a particular change is feasible for the particular set of actors involved. They, after all, are the ones who have lived through the situation, and who are to some extent responsible for it; they are also the people who will have to implement any changes that emerge. They constitute a particular culture, and the time constants of cultural change are such that some changes are feasible while others are not realistic propositions. Since the object of soft systems analysis is to bring about change – action to improve the situation – you therefore have to be sure that it is achievable within the particular local or organizational culture.

But if we insist that any changes to be implemented must be judged both desirable and feasible, that raises the awful possibility that sometimes no proposed change will get through this double filter. What then? What do you do if the actors do not agree that any of the ideas that have emerged are feasible and desirable? Given the general ethos of the approach you have to accept this verdict, for it is the actors who are the ultimate arbiters of these things. Remember that you are working within a framework, which assumes that if stakeholders are not persuaded by a case, then they will not co-operate with or facilitate changes based on it. In some cases, they may even sabotage any changes that are attempted.

But even if the outcome of stage 6 is a failure to agree on any changes that is not necessarily a disaster. In any event, there are a number of possible conclusions that one could draw from such an outcome. The collective judgement that no changes are feasible and desirable might, in some circumstances, be a wise one. This thought may not be very congenial to you, especially if you have sweated over an agenda of what you regard as potentially useful changes. But you should be willing to entertain the idea that, in some circumstances, it may be wiser to do nothing than to take action for the sake of it.

3 Stage 2 of the systemic learning cycle: engaging with the Taurus project through the soft systems method 111

Otherwise, the conclusion to be drawn from the failure to agree on changes is that the stakeholders involved in the situation do not regard your relevant system as being really ‘relevant’. In which case, it is back to square one and a new relevant system – unless, that is, you have followed the advice given earlier, and developed a number of relevant systems in parallel. If you have, in fact, taken out this insurance policy, then you will have your payoff now.

But even having to go back to the rich picture is not the disaster that you might think, because although the process of soft analysis described here must seem a rather long and complicated one, in practice the distribution of time between the various stages is quite uneven. In most studies, for example, the vast bulk of the analyst’s time is taken up at the initial stages – negotiating access, discussing the terms of reference, familiarizing oneself with the organizational structure and culture, and gathering information for the rich picture. Once that has been achieved, however, progress round the loop can be quite quick. One analyst told me that on a study lasting several months, the systems thinking (i.e. stages 3 and 4) was completed one morning in the time between coffee and lunch! That was obviously a special case, but it makes the point that this methodology need not be a cumbersome or time-consuming tool, especially in the hands of someone with experience.

Stage 7: Implementation of agreed changes

In this form, the method gives very little explicit advice on implementation. There is, however, some justification for this, for the simple reason that it is virtually impossible to carry out a soft systems study without dealing with the problems of implementation at every stage. Indeed, the whole thrust of the approach is based on the idea that changes will not happen unless those directly involved with them are persuaded of their merits. This is, in my view, one of the advantages of the approach. But it is also, and at the same time, one of its potential weaknesses, for it is based on a rationalist model of human behaviour. That is to say, it assumes that people are invariably rational, that they are amenable to argument and persuasion, that they are moved by evidence. Quite what the soft approach has to say about situations where these assumptions do not hold is not clear. Perhaps its supporters would say that the reasons for people’s unreasonable behaviour could themselves become the subject for a soft systems study?

Whatever the ultimate limitations of the rationalist model, there are still enough situations where it applies to a greater or lesser extent to keep analysts busy for a decade or two. So it is perhaps worth briefly running through the various types of changes which could come up for implementation at the end of a soft systems study.

The types of change that come immediately to mind are the following:

1 Changes in structures – these may be changes in organizational groupings, departments, reporting structures, lines of command, lines of functional responsibility, or even physical layout.

2 Changes in procedures – alterations in the dynamic elements in the situation (the processes or activities which go on within it). Changes of this type really just amount to different ways of doing things.

3 Changes in policy – in the goals and strategies of the human activity system(s) being investigated.

4 Changes in attitude.

112 Block 2 Part 3 Using the soft systems method for managing Information Systems on the Taurus project

Types 1 to 4 are relatively easy to implement, provided that those involved are in agreement about their desirability and feasibility. They may, of course, give rise to unintended consequences – implementation may itself give rise to new problems and a new problem situation, but that is inevitable whenever one intervenes in a complex system. One of the merits of this approach, and of its emphasis on ‘rich picturing’ of the situation in the early stages, is that one is less likely to overlook the interactions or interconnections which may give rise to unintended consequences of implementation.

Changes in attitude, however, are a rather different kettle of fish. Indeed, many people would regard it as being both foolish and sinister to set out to implement changes in attitudes. Some would even go so far as to say that people’s attitudes change only as the result of their experiences. In that sense, it may be misleading to talk about attitudinal changes as the object of the implementation stage of the methodology. A more realistic way of thinking about the subject would be to regard the whole process of soft systems analysis as one in which people are encouraged to share their perceptions of problem situations and to explore ideas about potential changes to which they might feel some personal commitment. The methodology thus offers people an opportunity to have different experiences of their situations, and perhaps also to change their attitudes as a result. But any change which does ensue will be a by-product of the whole process rather than the outcome of stage 7.

3.3 Criticisms of the soft systems method

ACTIVITY 27

Comparing your thoughts (before and after)

Now compare your thoughts about the SS-method set out in Activity 26 and consider them again. Is the SS-method more or less or very different from what you were expecting?

Continue with this comparison as you read through the analysis undertaken by John Robson. Then make notes on your own approach to the SS-method in your example (either your project or rearranging the garage).

In John Robson’s use of the SS-method do you feel that the stages are clearly represented? Do they run together or are they very different from each other? Consider your own example and note any points which remain unclear or which you feel are particularly interesting.

The main criticism levelled at the seven stage approach of the SS-method is directed at its lack of comprehensiveness, particularly at the later stages of the analysis and design process. This has led critics to argue that it is not a method that takes the analyst through a complete project life cycle. The idea of a project life cycle is not one that fits well with the approach of the SS-method. It is certainly undeniable that the method is strongest at the early stages of problem identification and analysis. At the very least, it explores possibilities for organizational learning and progress in problem situations that are neglected by hard approaches. The method from this viewpoint is regarded by some more as a front-end approach to carry out the necessary problem analysis before the technical analysis which would imply a computerized system.

Simon writes ...

Learning Album

3 Stage 2 of the systemic learning cycle: engaging with the Taurus project through the soft systems method 113

Two other criticisms are more related to how the SS-method is applied rather than the underlying structure and rationale of the method (also noting that this is but one exposition of the earliest version).

1 Although the role of the analyst is set out more forcefully than for the HS-method, there can be an implicit assumption (by the analyst, the person who commissioned the analysis, or the stakeholders) that the analyst is a neutral facilitator and not an integral part of the situation.

2 In practice some users of the SS-method have acted little differently to the straight external analyst role most often seen in hard methods while others have immersed themselves in the situation and worked extremely closely with all the participants.

Such diversity of application is also seen in the degree to which the SS-method is, again implicitly, a rational or systematic approach that allows soft emotional factors to be taken into account, rather than an intuitive approach that depends mostly on the skills of the practitioner (‘analyst’) for its successful use. Following the seven stages prescriptively is the basis for the systematic use of the SS-method. The intutive analyst uses the approach more freely and this is the type of approach we call Mode 2 SS-method (such that the method is transformed into a methodology) and which Blocks 4 and 5 allude to.

As noted earlier, John Naughton’s step-by-step explanation of the seven- stage SS-method is thorough and detailed and is the one applied in this block. But remember that there are other versions and flavours to the SS-method. On one hand there exist a number of more heavily proceduralized versions of the SS-method – possibly one of the best examples of this was produced by the UK Governments IT agency the CCTA (1993). At the other end of the spectrum are the continuing works of Peter Checkland and others which advocate a more liberal application of the method, moving away from the seven stage model and applying SS- method in a manner which is less prone to be mechanistic (e.g. the applied version of the method set out by Checkland and Scholes in their 1990 book). As Peter Checkland himself has said:

Most users, inevitably, start with a step-by-step version of the approach; but once it becomes familiar, and experience with it accumulates, the user can begin to take it as given and can use it more flexibly. Eventually it becomes thoroughly internalized – it becomes an adopted ‘way of thinking’ which does not itself have to be thought about at all – and then, ironically, it becomes more useful than ever! Describing this ‘experienced’ use of ss-method is not easy, simply because once it is absorbed as a way of thinking it tends to become ‘invisible’, like our knowledge of the ‘rules’ for riding a bicycle or for swimming. But features of it can be recovered by introspection.

(Checkland and Holwell, 1998, p. 163)

SAQ 30

Why do you think Peter Checkland talked about the Soft Systems Methodology in his talk to the OU Systems Society while I have talked about the soft systems method in this block?

114 Block 2 Part 3 Using the soft systems method for managing Information Systems on the Taurus project

SAQ 31

Summarize the ideas underlying soft systems thinking.

SAQ 32

Make use of a SWOT analysis to analyse the potential strengths and weaknesses (as you see them) of the SS-method for analysing a project.

As with the HS-method the process of absorbing the details of the SS- method will be helped by seeing the method in action. By reading the consultant’s report you will see how:

^ the stages of the SS-method come together;

^ each element can be applied to make Taurus more understandable;

^ each element supports and relates to the details of the study in question.

And as before, you are provided with:

^ the terms of reference provided to a consultant in order to make an effective investigation of the context;

^ the report of the consultant himself.

As you consider the report produced by the consultant, consider the soft systems method as a learning cycle in itself (see Figure 17).

Experiences a problem in the world

Experience again

Model or experiment with the conceptual model

Reflection – problem unstructured and structured in the

rich picture

Identify and abstract – issues and tasks – the root definition

Figure 17 An activity sequence diagram of SS-method as a learning cycle

Audio notes 1

Before you study this section any further this is a good point at which to reread the additional materials on the Taurus case study included in Audio notes 1 if you need to refresh your memory.

3 Stage 2 of the systemic learning cycle: engaging with the Taurus project through the soft systems method 115

4 Stage 3 of the systemic learning cycle: contextualizing your approach to the Taurus project through a consultant’s use of the soft systems method

In the same way as I asked a consultant to explore Taurus by making use of an hard systems analysis in Part 2, and in order to make this investigation into the IS project more understandable, I have provided you with the terms of reference which were given to the consultant and then the consultant’s report itself.

As in Part 2 it may help first to understand a little of John Robson’s background.

I took a first degree in Chemistry but subsequently added an OU degree mainly in Maths and Social Science and a part time Cert.Ed. in Post 16 Education. Afterwards I took a year out, generously funded by my employers, Bedfordshire County Council, to study systems at Lancaster University under the expert guidance of Peter Checkland and Brian Wilson.

My working career began in the IS area and I have worked for a wide range of employers including private and nationalized industries, financial services and local government. I started lecturing full-time in 1971, adding tutoring for the OU in 1978. I now lecture freelance, mainly for customers in the City of London, and continue my OU involvement by tutoring on courses in Systems, the MBA Technology Management and the OU Business School programmes for IBM.

4.1 Consultant’s terms of reference

You will be provided with the following information:

^ The chronology of Taurus.

^ A newspaper article about the Taurus failure.

(The consultant also had access to further sources of information.)

Your task is to write a SS-method analysis relating to Taurus. What follows are the terms of reference for the task.

The purpose of the SS-method application to the Taurus case study here is to show how systems tools can be used to make complex situations more understandable. I expect you to come up with different ideas and different ways of looking at the project. The main question for you to answer is this:

What went wrong in systems terms in this complex context and how might the SS-method have been applied to avoid the problem?

I am expecting that you will undertake a systemic analysis of the materials.

Your task will be an exercise in hindsight to use SS-method to:

^ identify the problem;

^ describe the problem in systems terms;

^ develop a model using SS-method which would have avoided the problem.

John writes ...

116 Block 2 Part 3 Using the soft systems method for managing Information Systems on the Taurus project

There now follows the soft systems analysis, which these terms of reference resulted in. It should take you 30–45 minutes to read this report thoroughly. John has quite a lot of experience in working on Financial IS and he tends to use some specific terms which you may not be familiar with. His definitions of these terms have been included in the glossary in Appendix A.

4.2 Consultant’s report on the Taurus project by John Robson

Stock Exchange Development 1979–93. A soft systems review

The soft systems method is essentially an investigation and design method. In strictly orthodox terms, it should be used during a process, and is not a review tool. However what I am trying to do here is to consider what effects a soft systems analysis might have had in the lead up to and execution of the Taurus project. I am trying not to allow the benefits of retrospective analysis to influence this too highly, but this is inevitably a privileged way to do an analysis. SS-method explicitly acknowledges the influence of the analyst on the project and vice versa, yet I am working from the privileged position of an essentially uninvolved observer writing after the event. Having noted that I am trying to produce a realistic analysis as it might have happened at the time rather than an idealistic retrospective assessment.

SS-method and Information Systems

SS-method is a systems method, not a method aimed at IS/IT development. It is concerned with overall form of systems rather than concentrating on the IS element. The output of SS-method is essentially some ideas on improving important aspects of functionality in real operations. To translate this into IS one needs to consider how functionality is provided or enhanced by information system provision. What I am producing here is a relatively straightforward pass through SS- method, with some consideration of possible IS conclusions.

The operational nature of the SS-method

SS-method gives effective guidelines that might be expected to bring about improvements in a problem situation. It offers a high probability of improving things, but has no test of optimality. However good the conclusions are which are reached, it is highly likely that more work could still produce improvements. With a method of this type the possibility of improvement often occurs during the process itself, and this leads to considerable amounts of iteration. Also stages of the method are overlapped rather than sequential. The practitioner often thinks through one stage in the light of what is needed in the next, maybe at the same time still building and refining previous stages. It is to be hoped that the focus of enquiry moves forward, (although an explicit iteration reflects a move backwards to concentrate on prior steps), and that the project moves over a period of time to produce a series of actions that are seen to bring about practical improvement. If I tried to reflect these processes here the product would be unworkable with. Here I am following the stages sequentially, as my main aim is to illustrate the form of the method.

Stage 1: The problem situation unstructured

This stage consists of looking at the general situation and noting its content. The stage should be non critical and non-interpretative. You are

4 Stage 3 of the systemic learning cycle: contextualizing your approach to the Taurus project 117

essentially noting anything and everything. A team should be able to work on this quite easily as anything recorded is in principle testable. (If there is a difference of opinion in the team it can be resolved by going back and checking.) In this case the stage consists of the information in the articles which have been provided plus additions from my own knowledge of the City. (I worked at the Stock Exchange – in the Directorate for Information Systems and Settlement – in 1973 maintaining the pre Talisman systems and still do a considerable amount of work in the City.) This material is assembled for stage 2.

Stage 2: Problem situation expressed

This stage consists of assembling the information available to see how it fits together. Thus a picture of the overall setting is built up. This is summarized graphically in a ‘rich picture’ (see Figure 18). This stage is very much overlapped with stage 1. Whilst clearly I must know information before it can be assembled together, the assembly is usually done as I go along. As information comes to hand it is added to the rich picture. The following notes expand the rich picture content:

1 The Stock Exchange had a long running settlement system known as ‘TALISMAN’. This had been produced as a re-engineered and

T+10 T+5 T+1 T?

anti com pet itive

1%-2% fixed commission

Broker Jobber ICL IBM Reengineering of previous settlement systems

(6)

wealthy/ profitable (money to burn) but feeling competition (fires getting smaller) EUROPE

Promise of removal on move to paperless settlement

(5)

Stamp duty

(4)

Commission scale withdrawn

(1) Talisman

updated

BA NG

increas ed pre

ssure

of mod ificatio

ns Order Book

S.E.T.S.

move to order

driven trading

(no ma rket

maker)

(2) on screen real time trading

Rolling settlement

Getting faster

Government action via

Iron lady privatises utilities

Mountain of small shareholders

(3) increased numbers of transactions

Slo w

Paper mountain.

Uncleared tickets.

BANK

owns

Registrars maintain register

delays in registrations/ issue of certification

A.B.500 X Y 1200

cash settlement delays

pres sure

for removal of

mar ket

mak er (jobber) effective monopoly

DTI, Bank of England

etc.

(elect ronic)

increased competition

competition from CWE (Paris/Frankfurt)

may increaseliquidity/volumes

Court

Fe

Figure 18 John Robson’s rich picture of the Taurus context

118 Block 2 Part 3 Using the soft systems method for managing Information Systems on the Taurus project

extended version of previous systems. One of the key differences from previous settlement systems was a move away from ICL 1900 hardware to largely IBM 370 equipment. This had meant a total rewrite of software as the earlier systems were written in 1900 PLAN low level language which was specific to ICL machines. Although eventually TALISMAN was highly regarded, memories of its development seem to be somewhat rose tinted. Like many information systems it came in very late and over budget.

2 Many developments occurred both during the development of TALISMAN and subsequently. The system had been much amended, and some failures had occurred, although these were usually not attributed to the core settlement systems.

3 The volume of transactions (due in a large part to privatizations of public sector utilities like water and gas and demutualizations of building societies) was pushing both Stock Exchange and members’ systems to (and beyond) their limits.

4 Share transfer was becoming increasingly competitive and increasingly international. The Stock Exchange was market leader in the UK, not a monopoly. Although moves within the European Union towards ‘Europeanization’ of stock markets has maybe proceeded more slowly than many might have predicted, it has been perceived as a threat since the early sixties.

5 The government had indicated that it would abolish stamp duty on stock transfers if an electronic trading system was introduced. As this tax was 1% of turnover (paid by purchasers of stock), this was a substantial incentive to develop such a system.

City institutions in general, and the stock-broking community in particular have always been very profitable. It has not really mattered too much if costs occasionally escalated as profitability could stand it. Things were maybe getting tighter from the late 1960s onwards. There was no longer a bottomless pit of resource, but this was still a very rich industry. In the early 1970s it was becoming more obvious that ‘even if there was money to burn, the fires were getting smaller’.

At the end of this stage the information available has been assembled and we are in a position to consider what the problems are.

The following themes might be noted:

1 inability to execute transfers and settle payments on time;

2 need to comply with Department of Trade and Industry requirements;

3 pressures from institutions at home and abroad to change methods of dealing;

4 pressures from government and small shareholders for simple and cheap share-dealing services;

5 demand for shorter settlement times;

6 globalization;

7 government incentives to automate stock transfers.

Stage 3: Root definition of relevant system

The system taken forward for development was ‘a system for electronic transfer and settlement of shares of Companies listed on the Stock Exchange’.

4 Stage 3 of the systemic learning cycle: contextualizing your approach to the Taurus project 119

Several things might be noted here. The Stock Exchange had international aspirations throughout this period. It was primarily concerned here with equities (i.e. ordinary shares of companies, rather than government debt which was already traded for immediate settlement on other systems). The shares listed in London are primarily those of large UK based companies, but also include very large foreign corporations whose shares may be listed in London, often in addition to their home country. The Exchange did not choose to pursue globalization aggressively. For example, shares in listed UK companies traded in the USA are held in the form of ADR’s (American Depository Receipts) and this isolates the markets to a large extent. (Some of the criticisms that Taurus tried to do everything are unfair. It could have been much more ambitious than it was.)

This system addresses aspects of themes 1, 3, 4, 5, 7 and potentially supports theme 2. Whilst the Exchange claimed to be driven by the spectre of international competition, there is little evidence of this. International stock trading was, and remains, complex and expensive. City Institutions may be able to trade and hold foreign securities but most individuals are still now effectively restricted to shares with a London listing. Theme 6 was largely ignored, although there remains the awareness that this could be a potential competitive threat.

If the relevant system is developed to a full root definition (i.e. to include relevant CATWOE elements) it becomes:

‘A Stock Exchange system for electronic transfer and settlement of listed equity securities traded by stockbrokers (on behalf of their clients), which complies with requirements of UK government agencies.’

A CATWOE check gives:

Customer Stockbrokers. The broker remains the direct customer. It might be noted that the traditional approach to share trading is being maintained. This is very much as might be expected as the exchange is owned and controlled by its member firms.

Actors Not specified. They are not very important to this system which is electronic and largely automatic. The brokers interface directly on to the system, but as they fortunately have an interest as customers they can be largely relied upon to support it.

Transformation ‘electronic transfer and settlement of listed equity securities’

Weltanschauung Use of technology to increase efficiency and speed, and lower cost of share dealing

Owner Stock Exchange

Environmental constraints

‘requirements of UK government agencies’

One comment I would immediately make is that this system concentrates on the transfer process. The Taurus system was often discussed as being about ‘dematerialization’ of securities. I will return to this as it is a rather odd focus and one that led to many problems.

I also want to comment on the idea of ownership. The owner is the person or group who causes a particular system to be of interest. This does not imply legal ownership in the real world.

Stage 4: Conceptual model

See Figure 19.

120 Block 2 Part 3 Using the soft systems method for managing Information Systems on the Taurus project

1. Obtain price information

2. Advise clients

on prices

4. Receive purchase

orders for equities

5. Agree equity

trades

6. Make or collect

payments 7.

Register ownership

3. Receive sale orders for equities

Figure 19 John Robson’s conceptual model of the Taurus project

Note that the conceptual model is derived exclusively from the root definition, without any reference back to the real situation. This is still in the domain of systems thinking. As I have developed it here, the conceptual model represents a more detailed expansion of the root definition.

Stage 5: Comparison of Stage 4 with Stage 2

This stage consists of comparing the activities in the conceptual model, with what actually exists in the real situation (Table 10). Note that the numbering of the activities in the conceptual model (Figure 19) is purely to identify them.

One rather odd feature of the Taurus project was its emphasis on dematerialization – that is to say the move from physical certificates to computerized share register. Yet, equities were already almost universally dematerialized. Whilst the transfer process still used certificates, the definitive evidence of title was the share register. The share certificate was prima-facie evidence of ownership only. Most securities had changed from bearer form (where the certificate was proof of ownership) to registered form (where the register was proof of ownership – and the certificate was only evidence of an entry in the share register) around the beginning of the twentieth century. With the advent of computer based information systems, companies’ share registers had been moved to computer based form. Registrars’ systems were already capable of paying dividends automatically, and could handle a wide range of procedures such as mergers and demergers, take-overs, etc. There seemed to be general satisfaction with such systems, although as observed above there could be delays in registration (which could have been due to brokers/market makers as well as registrars). Most companies appeared to be happy with the maintenance of their share registers. Problems were rare and when they did occur were related to volume of transactions.

4 Stage 3 of the systemic learning cycle: contextualizing your approach to the Taurus project 121

Table 10 A comparison table of the conceptual model with the situation

Blob in CM Is it in situation? Comment Carry forward?

1 Obtain price information

2 Advise clients on prices information

Obtain price information and advise clients on prices

This was well-provided post the computerization of the London Stock Exchange known as ‘big- bang’ (and was effective even before that). On-screen real time information was readily available. However there was a complication on the horizon. The existing price information was provided by individuals and organizations known as ‘market makers’ who traded on their own account, but there was a proposed move to ‘order book’ trading where buyers and sellers were matched (and there was no intermediate trader).

Existing procedures very effective. Subject to minor updating for new procedures. (The delays in public systems (20–30 minutes) are imposed by the Stock Exchange. The Stock Exchange uses its intellectual property rights to limit real time information to subscribers to its own price information services. Thus prices on CEEFAX are artificially delayed.)

No. Procedures and requirements already well known and fulfilled. There is a need to ensure that price information is available following any changes to ‘Agree equity trades’, but this is essentially a technical interface problem associated with this activity.

3 Receive sale orders for equities and

4 Receive purchase orders for equities

Again this seemed to work well. It did however depend upon trust as orders were accepted by brokers without receiving cash or shares until settlement was due. Practice was changing and the traditional ways of doing business were not being offered other than to large established customers. More and more brokers were insisting upon clients lodging certificates with them prior to trading or depositing enough cash with them to cover their committed positions. Complexity, variety of service and forms of dealing were increasing. Volume could be overwhelming, and it is not unusual for a broker to suspend taking on new clients. The processes were well understood, but there was maybe a reluctance to handle small trades. (Small in stockbroker language means up to £100,000 so it includes most personal trading.) The real money in this lucrative business has always been in institutional rather than personal trading. Institutions were well served, although charged high prices. Individuals were less well served. Increasing numbers of companies took it upon themselves to arrange cheap, no-frills dealing services for small shareholders. Although they offered this as a service for small shareholders, it was often motivated by a hope that the size (and hence cost of maintaining) of their share register would be reduced if small shareholders sold their shares.

The activities were well enough carried out, but changes would be needed to avoid volume related problems, and to interface electronically with a much revamped ‘Agree equity trades’ activity.

Yes. This had implications for the systems used by brokers. The Stock Exchange had a well developed committee structure within which changes and requirements could be debated and agreed. This was useful in providing communication channels, but had some problems that could be envisaged in this type of structure. The committee structure was rather cumbersome, and the people actually attending any given committee varied. Committees exercising decision making powers could (and did) change their decisions partly based on who turned up on a given day.

122 Block 2 Part 3 Using the soft systems method for managing Information Systems on the Taurus project

Blob in CM Is it in situation? Comment Carry forward?

5 Agree equity trades

Here there were some difficulties although most of the time the process worked well. When prices were moving quickly, market makers would protect their position in three ways. First they might increase spreads (that is the difference between selling and buying prices) which could make trading unattractive. Secondly they might restrict the size of deals that they would accept at the screen quoted price. Thirdly phone lines could be unplugged and no trading done at all. Whilst these tactics only occurred exceptionally, it could, in the worst case, mean that clients could not deal when prices were moving quickly, and there were concerns that larger than programmed losses were being taken.

The planned moves to rolling settlement and order book trading (see the glossary to explain these two terms) were something new.

Development was thus necessary to provide for the planned new ways of working.

Many requirements for change were needed here. As well as dematerialization many other changes to the trading process were being required. This is where the core developments were needed. It would have been easier to develop if operational requirements could have been changed once and for all simultaneously with implementing the new electronic trading system. Desirable as this might have been it would have been very difficult to schedule. The alternative was to develop an information system which could support a range of trading methods.

This would be much more complex as the requirements were conceptually very different, not just minor technicalities.

Yes. This activity is absolutely fundamental. Usefully it is also a direct Stock Exchange activity. Care does however need to be taken to ensure that the interface with order, settlement systems (i.e. blobs 3/4/6/7) is satisfactorily agreed and designed. It should be noted that current activities corresponding to 3/4/6 involve brokers systems, and if these are not provided by the Stock Exchange centrally, brokers will need to develop their own systems or revise current systems to support the new interface requirements.

6 Make or collect payments

This was creaking under the volume of existing transactions. There has always been some late payment. The financial advantage to be gained from late payment always clouds the evidence in relation to whether systems are adequate. After privatizations, brokers’ back office work was being swamped by mounds of paperwork. Something had to be done to streamline this work.

Some increases in efficiency were needed here, particularly if settlement was to be speeded up (the time between trade and payment reduced).

Yes although it might be hoped that once the interface specification had been agreed brokers could develop their own information systems to support this activity.

7 Register ownership

Registrars sometimes responded slowly. With faster transfer of equities this began to compound problems. Certificates were not being delivered for settlement because they had not been issued from the previous transaction. This was further complicating back office settlement work. With shorter settlement periods the problems increased. With the old fixed account system (see glossary), dealings within the account did not need registration (although there could be dividend payments and other rights for the broker to sort out). With rolling settlement (see glossary), virtually every trade had to be registered. This increased the registrars work load, and increased the above problems.

Already well developed. Registrars used their own information systems, but all major listed companies were supported by computer based share registers. Any new system developed would have to interface on to these, but the systems already in place were otherwise satisfactory in most respects.

Yes, but only the interface needs development. (One of the surprising thing about the TAURUS project is that its designers chose to redevelop this almost from scratch; see also comments in Stage 6).

4 Stage 3 of the systemic learning cycle: contextualizing your approach to the Taurus project 123

Although the register was itself the primary document, share certificates were used to authenticate transfers, and were produced when shares were acquired by a new owner. Although I have suggested that the register was already in electronic form, the procedures for transfer of shares were still very much document based. It should be noted however that most register based functions other than transfer of ownership were computer based, and registrars already had considerable expertise and well-developed computer based systems.

Stage 6: Debate on systemically desirable and/or culturally feasible changes

The comparison stage shows that the primary gaps in providing an electronic system for share ownership were in the transfer and settlement activities. This might have led to a concentration on these areas. Not only were they key items in the system of interest to the Stock Exchange but they were also areas under its direct influence. There would be a need for brokers to develop their systems to match the interface requirements of the central system, but as the Stock Exchange was owned by its member firms the issues could be easily resolved in its well (maybe over-) developed committee structure. Indeed this seemed to be borne out in practice. Not only was this area under direct Stock Exchange control, it represented its core business. Maybe if it had ‘stuck to the knitting’ a successful project could have emerged. Surprisingly, the Taurus project encompassed maintenance of share registers. Not only did this put the Stock Exchange into direct competition with established registrars, but it was a largely unnecessary foray into an area where the Stock Exchange itself had little experience. Neither did this appear to be a particularly profitable activity. In recent years the number of firms involved in registration has tended to decline, partly through mergers, but also through firms shedding the business. It might have been much more constructive to develop a system that interfaced on to the existing systems of the registrars rather than try to take over their business. (Subsequently the modest follow-on project to Taurus called CREST took this approach.)

Stage 7: Action to solve the problem or improve the situation

The Stock Exchange went ahead with a new computer based system to produce from scratch new procedures to cover all areas of the conceptual model, regardless of whether redevelopment was necessary. The project was more like a green field development, than an incremental improvement. This was also against a background of shifting environmental demands.

A less ambitious approach that concentrated on trading and settlement might have had more chance of success, as would a system designed for a simplified settlement system. The modest claimed success of CREST maybe can be taken to justify this approach, but CREST is in many other ways much less ambitious than Taurus. Taurus if it had ever come into being would have been a much more comprehensive IS than CREST. Whilst CREST has streamlined some processes for the large players, it has done little if anything to solve the problems of volume. Small transaction trading remains largely certificated and continues to generate large amounts of paper based clerical processing.

124 Block 2 Part 3 Using the soft systems method for managing Information Systems on the Taurus project

Conclusions

From this soft analysis my main conclusion is that the Stock Exchange might have been better advised to concentrate on developing electronic systems for trading and settlement, and to interface these on to the existing registration systems. It should however be noted that this conclusion comes essentially from my choice of root definition (which in the real situation I would have negotiated and agreed with the problem owner as a basis for proceeding).

The approach taken by the Stock Exchange was arguably sensible from other perspectives. For example, Stock Exchange member firms dominated the trading and settlement activity already. After big-bang, international bankers had entered the markets of the traditional players, but had largely done so by take-over of existing firms. Old traditions often continued. Registration, in contrast, had long been the domain of subsidiaries of large banks. There was possibly competitive advantage to be gained for the Stock Exchange if these players could be squeezed out. Control of registration could potentially have made difficulties for rivals to provide stock trading facilities. Institutions were already trading shares directly between themselves, rather than via the market provided by the Stock Exchange. The Stock Exchange and its member firms were very aware of competition.

There is also an information system crisis in the City. There are many old and much patched software/IT combinations. These combinations have the advantage of being well proven over time, but they are often poorly documented and there may be few, if any, people remaining who understand them. Much of UK cheque clearing is still executed by programs written in IBM Assembler code in the period 1965–1970. Maybe part of the driving force of Taurus was an attempt to replace ageing software.

In my suggestion that there may have been a better chance of success if Taurus had been a more limited project, I am assuming that the problems on the project were essentially conceptual in origin. This is inevitable from taking the soft systems approach as it concentrates on needs, rather than implementation. It is quite possible that the failure of Taurus was also due in part to implementation problems as well as conceptual ones. An analysis using SS-method would be less likely to highlight this. The Stock Exchange has always used contractors to develop its systems, and the accounts you have read demonstrate the multiplicity of sources from which these came. This approach seems to come from a Stock Exchange reluctance to have many permanent employees, particularly on development projects. The Stock Exchange had relatively little in-house expertise in project development. It was also in individual contractors’ interests to prolong the project. Just as staff were made redundant by their agencies when the project finally collapsed, if the project had terminated because it was complete the effect would have been similar. The successful completion of TALISMAN had been accompanied by the shedding of considerable numbers of agency employed analysts and programmers. There were some similarities between the loss of control of the Taurus project and problems in the development of TALISMAN, but it seems that lessons were not learned.

The subsequent implementation of CREST has shown that a more limited system can work, but CREST falls well short of dealing reasonably fully with the issues I have identified. CREST works for large clients, but small

4 Stage 3 of the systemic learning cycle: contextualizing your approach to the Taurus project 125

shareholders are essentially excluded and effectively forced to hold their shares in certificated form. This could lead to increasing difficulty in share ownership by individuals, which continues to decline.

Overall then my conclusions are that the Stock Exchange should have restricted its development to trading and settlement. If this had happened something much better than CREST might then have been developed. It may not have had the flexibility of Taurus as proposed, but might have been more realistically deliverable.

5 Stage 4 of the systemic learning cycle: managing the complexity of the Taurus project through the soft systems method

Having read John’s report on Taurus you will notice that he has brought a lot of his own experience into the analysis. He obviously has a deep understanding of the prior system (TALISMAN) and the eventually adopted system (CREST). This is a good point to emphasize that systems analyses of contexts like Taurus are personal and specific inquiries where the author of the approach should always be aware of their own place in the situation. John brings a lot to this analysis which is specific to him. In order to unpack this a little it will be of use to consider the report in terms of a conceptual model. Opposite in Figure 20, I have set out my view of the conceptual model of John’s activities from my perspective. You will notice that an early theme running through the analysis is the use of and reference to new material and the adoption of SS-method in a manner which John had not applied before.

Other points which I draw out from John’s analysis are as follows:

^ He has focused on trying to understand the original project as a process and without a concept of explicit blame. You do not find in the analysis any reference to fault or error, rather the analysis is undertaken as an enquiry into the structure and processes of the original project. What we are after is understanding and ideas for situation improvement.

^ John does not provide any new visions here (the terms of reference did not include this!) although I feel that his elegant conceptual model does provide a really useful holistic simplification of the Taurus project. In a sense he provides an overview and a ‘cleaned up’ assessment of what the project was intending to achieve and what could have been achieved. It is very useful to compare his rich picture and his conceptual model in this regard.

^ He has adopted a step-by-step approach to the use of the SS-method. He has shown how each step provides a foundation for the development of the next step and in this sense he has developed the approach very much in line with that which John Naughton advocated earlier.

^ Finally, he has advocated a change process which might have produced a better system in the first place. He has set out a systemic approach to developing Taurus but has also looked further – at the work of the Stock Exchange itself – and suggested that the issues of the problem context related to the way in which the Stock Exchange does its business – using numerous sub-contractors and essentially ‘buying in’ solutions. Is there something here which resembles Sue Brown’s losing out to the slick city presenters in Part 1 of Block 2?

Simon writes ...

126 Block 2 Part 3 Using the soft systems method for managing Information Systems on the Taurus project

SAQ 33

Show how the SS-method as applied to the Taurus project conforms to the learning cycle set out in Figure 17. How do the steps correspond to the structure and processes set out there?

SAQ 34

Set out five reasons for believing that the SS-method is a systems method.

SAQ 35

Suggest at least two traps a practitioner could fall into which would make the SS-method non-systemic.

SAQ 36

Keeping in mind the specific requirements and tendencies of the SS- method, describe two contexts (these maybe IS or not) in which the SS-method way of exploring a problem would be of specific value.

1. Review my experience of Taurus

2. Consider the

Talisman project

3. Consider the terms

of reference

4. Develop my

thinking about SSM

5. Review

different ways of doing and applying SSM

6. Review the

materials supplied

7. Provide an initial SSM

of the context

8. Develop an explanation of Taurus in

systems terms.

Figure 20 My conceptual model of John Robson’s approach to Taurus

5 Stage 4 of the learning cycle: engaging with the Taurus project through the soft systems method 127

SAQ 37

From your own experience describe a problem context in which the use of the SS-method would be useful. Set this out in terms of the SS-method cycle.

6 Conclusions on the use of the soft systems method for the Taurus project

In conclusion to this part I want to link the review of John Robson’s application of the SS-method to the Taurus project in terms of the outcomes which might be drawn from the study.

The Taurus project was very messy and proved difficult if not impossible to manage but part of this difficulty appears to have been caused by the manner in which it was undertaken. To some extent this has already become clear from the hard analysis provided by Trevor. In this part John Robson’s soft analysis has underlined that systems methods are ones which aid the decision maker/manager to know and understand the context in which they are working. In particular, the conceptual model which John provided of the project clarifies the core aim of the project and could be used as an agenda for developing the project as a sequential entity.

John Robson has said that SS-method is not an IS development method. This is true to a point. It would not be possible to take the version of SS- method, described by John Naughton and set it out here as an ‘all singing, all dancing’ IS development method. However, the SS-method can be the first stage of such a method and can be applied as a means to evaluate existing IS projects. In this sense the SS-method can be used both to assess the feasibility of IS (as seen in the work of Avison and Wood-Harper, 1990 and Bell and Wood-Harper, 1998) and also as a means to evaluate IS that are running.

The SS-method can be demonstrated to be of value in contexts where goals are unsure and purposes are unclear. Taurus does appear to have been a good candidate for this type of method that deals with such unknowns. From the first part of Block 2 I have argued that information systems are social and technical systems which are centrally involved with the meaning of the information which they contain and distribute. From John’s analysis of Taurus it seems evident that SS-method can be directed to develop an understanding of the meaning of a context and from this gain insights into how an IS might develop. This would seem to be a primary value of the approach.

This analysis does not answer all the questions – most specifically about the nature of the Stock Exchange itself and the way in which it does business. Nor does the use of the method remove irritating problems about decision escalation or the politics involved in decision making. However, the method does seem to allow an analyst the freedom to think widely and inclusively about a problem context, address issues which formal methods ignore and provide action plans to make the complexity manageable. It is interesting here to think back to the juggler in Block 1. How has the B element – the being a practitioner changed between the work undertaken by Trevor Livesey and John Robson? How have they differed in managing the situation? How have they changed in the way they put the situation into context? These are all questions which I will deal with in more detail as I review and reflect upon these exercises in Part 4.

128 Block 2 Part 3 Using the soft systems method for managing Information Systems on the Taurus project

Also in Part 4 of this Block I will be looking in more detail at the comparative values of soft and hard approaches. It is worth recalling that soft and hard are but two of the many systems methods in use today. Both have been criticized for being weak in terms of dealing with political and ethical considerations. This is an issue which is particularly highlighted in Critical Systems Thinking (briefly described in Block 1) as advocated by Robert Flood and Michael Jackson (1991).

7 Summary In Part 3 the reasons for soft systems thinking were discussed and the seven stage SS-method was introduced. The Taurus project was reviewed but this time through application of the SS-method. You have been encouraged (as with the HS-method in Part 2) to read both about the method and a consultant’s use of the method at the same time. You were also encouraged to develop your own use of the SS-method – its usefulness is not restricted to the IS domain.

6 Conclusions on the use of the soft systems method for the Taurus project 129

130 Block 2 Part 3 Using the soft systems method for managing Information Systems on the Taurus project

Part 4 Reflections on Block 2

1 Introduction This part of the block is intended to be an opportunity to reflect back and consolidate what you have learnt in Block 2 and to complete the learning cycle for the block as a whole. As well as the chance to further analyse and reflect upon the two systemic explorations of the Taurus case study, a further method – logical framework – is introduced as a tool for understanding IS projects. Finally we reflect upon the use of systems methods in IS projects.

There is not much new material in this part of the block – you’ll be pleased to know! The main emphasis of this part is to encourage you to reflect on what you have learned in the block and to develop your understanding of both the Information Systems domain and the systems methods used in the block. This is essential preparation for tackling the TMA associated with the block.

Section 2 is a structured summary of the core content of the block. You are encouraged to undertake a few activities and then to attempt a series of SAQs. The SAQs will enable you to gauge your current level of understanding of the material as well as practice some of the key skills. Your answers will provide a useful summary of key parts of Block 2.

The next section gives a different approach to reflecting on the material in this block. The first, in Section 3, was developed by me, as a way of comparing and contrasting HS-method and SS-method. In that section I introduce and make use of a method known as logical frameworks, LogFrame for short. This can be a systematic and a systemic tool with many uses in projects. It is a method you may find extremely useful in your own T306 project.

The second reflection on Block 2, in Section 4, was written by Jake Chapman. The aim is to encourage you to develop your own style of reflection and consciously to include this in all your activities associated with the course.

2 The story so far The starting point for this block was a series of Information Systems disaster stories, stories of serious overruns in time and money and sometimes the abandonment of large projects. The case studies used throughout the block have reflected this general malaise. There has never been any shortage of suitable case study material for this block! There are, of course, also many examples of Information Systems that work; nevertheless it is a striking statistic that 60% of all IS projects are deemed unsatisfactory or to be failures. Various authors have, over the years, presented their own explanations or ten ways to avoid such failures. By now it should be clear that any simple explanation is likely to overlook many of the issues involved in Information System projects.

Given that there exists this history of failure in a domain called an Information Systems domain, it is clearly useful to see whether systems methods and approaches can shed any light on what is happening. A key starting point for this was to establish what is meant by Information and System.

Simon writes ...

Jake writes ...

2 The story so far 131

To gain most benefit from this section it is essential that you attempt all the SAQs as they appear. The text following the SAQ assumes that you have also read the answer at the back of this block, and refreshed your memory of the concepts involved. It is also important that you attempt to answer them without referring back to earlier material; it is only in this way that you will be able to assess your current level of understanding.

SAQ 38

Explain the difference between System and system as used in this block. In your own words describe why this distinction is important.

SAQ 39

What is the difference between data and information? To what degree can data be said to be ‘objective’ i.e. free of interpretation?

The idea of Kolb learning cycles was introduced in Block 1 and developed further throughout this block. Learning cycles are important for your own learning process and are also potentially important for understanding IS failures. They also provide a framework within which other methods can be used more systemically. You will have noted that we used the learning cycle in Parts 2 and 3 as means to encompass all the stages of the SS- method and the HS-method.

SAQ 40

As further revision draw a diagram of the Kolb learning cycle again.

SAQ 41

Learning cycles can be used as a systems method by asking two questions. What are these questions? What, if anything, do they reveal about Information Systems?

Block 1 also introduced a number of systems methods and described the context in which they had been developed. Two of these methods have been applied to the IS domain in the block, the hard systems method (HS- method) and soft systems method (SS-method). You will encounter these methods in other parts of the course and may well wish to use one or both in your own project. The treatment in this block has been an introduction to the methods. The reports by the consultants, Trevor and John, are useful illustrations of how the method can be applied in a formal sense. It is only after you have mastered the formal stages of the methods that you will be able to adapt them to new situations.

SAQ 42

State the eight stages of the hard systems method as set out in Part 2 of this block.

SAQ 43

State the seven stages of the soft systems method as described in Part 3 of this block.

132 Block 2 Part 4 Reflections on Block 2

I have to admit that I have to look up the formal definitions of the stages of each of these methods, so do not be too hard on yourself if you could not remember them all. In the HS-method the sequence of steps is very logical and systematic. In the SS-method I find that it is the first four steps, up to and including constructing the conceptual model, that provides the insights into situations. So I often forget the description of the last three steps, though they too follow logically in the overall sequence.

Within each of the systems methods there were some other tools introduced. It is actually very common for a practitioner to make use of a range of tools, even when following one main systems method. In your own project you should be willing to try a number of these tools and explore further any that appear to you to shed further light on the situation.

SAQ 44

What is a SWOT analysis? What do the letters stand for and how do you carry out such an analysis?

SAQ 45

What is CATWOE? What do the letters stand for and how is this tool used?

SWOT and CATWOE analysis are also useful tools that can be used in a number of systems methods, not only in HS-method or SS-method.

The reflections in the next two sections are largely concerned with comparing the two main systems methods introduced (namely the HS- method or SS-method). As preparation for this attempt the following SAQs. These could have been framed as Activities, but it seemed more appropriate to provide you with answers to compare with your own, so they are presented as SAQs. However you may find it useful to include your answers in your Learning Album.

SAQ 46

What are the main criticisms of the hard systems method? To what extent do you agree with these criticisms?

SAQ 47

What are the main insights or new understandings that you gained (if any) from the application of HS-method and SS-method to the Taurus case study? Which do you consider to have been the most productive?

The following SAQ may take up to 30 minutes to complete. It is provided as a way for you to:

^ practice using the methods introduced earlier in the block;

^ gain a better overview of the block for yourself;

^ facilitate your own reflection on the material.

Learning Album

2 The story so far 133

SAQ 48

Apply the HS-method and SS-method to Block 2 from your perspective. In order to do this you should complete the steps of the HS-method up to and including ‘objectives and constraints’. For the SS-method exercise draw a rich picture, develop a root definition of a relevant system and construct a conceptual model of that system.

3 Logical frameworks: a systematic and systemic reflection

Although the main aim of employing the HS-method and SS-method in this block was to simply illustrate their use, it became clear to me that it was important also to compare the two methods as applied to the Information Systems domain. Part of the difficulty is that this, being the first application of the methods in the course, is a rather formal use of each method. There is deliberately not as much deviation from the formal method as could be expected in a real life application. And, of course, the methods are being applied in retrospect on a selected body of case material. In real life nothing would be this neat and tidy. Nevertheless, having applied both methods to the same case I wanted to find a way to make a useful comparison.

After much thought I remembered a very useful tool that I had used to good effect on a number of projects. This tool, logical frameworks, colloquially known as LogFrame, is really a project management tool. But it provides a framework within which I found it possible to compare and contrast the two systems methods. I decided that it was worth the effort of introducing new material this late in the block because it is another tool that you may find particularly useful in planning and reflecting upon your own project. I think it provides a way of taking a critical approach and checking and drawing out goals and assumptions that may or may not have already been identified by the other methods introduced. LogFrame is an example of a tool that is not overtly a ‘systems’ tool but in my experience it can nevertheless be used to support systems inquiry.

The history and origin of the LogFrame is contentious. It is widely argued by the community of practitioners working in developing countries that its origin was in planning projects in rural development (e.g. agricultural practice improvement projects in East Africa in the 1970s). The exact origin of LogFrame is uncertain but it was developed as a means to provide the controllers and funders of projects with an overview of a project process. Typically the LogFrame as originally conceived would be ‘owned’ by the powerful funder of the project and the other stakeholders and actors in the context would not be involved in its development. More recently there have been attempts to make the LogFrame more available to all stakeholders in a project and to provide these stakeholders with inputs into its creation and development.

I have found the framework of value to me in my practice mainly as a means to develop questions and assess the causes at work in projects. There are four key questions in a LogFrame analysis:

^ What activities are taking place in this project?

^ What are the outputs from these activities – what are they supposed to achieve?

Simon writes ...

134 Block 2 Part 4 Reflections on Block 2

^ What purpose or purposes are these outputs designed to bring about? (You need to take into account the difference between this definition of purpose for logical frameworks to that given to purposes in Block 1.)

^ What wider goal will be made more realizable if the purpose is achieved?

In any logical framework analysis those involved need to be aware that the specification of goals and purposes is highly subjective. By this I mean that different people may well have different goals and purposes corresponding to their different perspective. For example, the ‘purpose’ of an IS project could be – ‘a means to provide employment’, or ‘a way to produce performance indicators’, or ‘a method for using up excess budget at the end of the financial year’. These are all different purposes for the same project. They are all valid but they represent the views of different stakeholders.

A LogFrame is essentially a four by four table or grid that addresses the four questions in four different ways. The questions, in the form of single keywords, appear on the left of the rows of the table (in reverse order – that is, ‘goal’, ‘purpose’, ‘outputs’ and ‘activities’). The columns represent different aspects; namely the narrative, verifiable indicators, means of verification and assumptions. The format of a LogFrame is illustrated in Table 11 on page 136.

The first column of the LogFrame is the narrative summary or general description of the project. The next column in the way I use the LogFrame is column 4; this provides a view of the assumptions of the project. In my work with LogFrame I tend to use the assumptions column as a place to set out the difficult, uncontrollable (by me anyway) and unstructured elements in the context which I have been made aware of.

Columns 2 and 3 set out the way in which the project can be measured for success (as defined by those developing the framework). Column 2 contains the ‘objectively verifiable indicators’, often abbreviated to OVI. Sometimes this column is just called ‘verifiable indicators’ (VI), in acknowledgement of the doubtfulness of claims to ‘objectivity’ in many of the applications of the LogFrame. Column 3, ‘the means of verification’, relates to the manner in which the measurement of success can take place. This column is sometimes abbreviated to MOV.

The framework in total provides a summary of a project in column 1, means to assess this summary in columns 2 and 3 and an overview of the more difficult and unquantifiable features of the project in the assumptions column 4. This framework summary can be used systemically by a team to design and analyse a project, to evaluate a project, or to reflect upon a past or present project as a purposeful system. Similarly, the framework can be used systematically by individuals to develop projects as purposive systems. It is important for individuals and teams to consider the way in which they are applying the LogFrame.

In the next section I will use the Taurus project as an example of how a LogFrame can be used in a project. You may find this a useful technique for your own project, and it is with this application in mind that I introduce the details. Then in the next section I use the LogFrame to compare the HS-method and SS-method analyses of the Taurus case study.

3 Logical frameworks: a systematic and systemic reflection 135

3.1 Reflecting on Taurus

I will now develop a LogFrame for the Taurus project. I would recommend that you follow the same approach as that laid out here if you use LogFrame in your own activities. Based on my own experience of using LogFrame I have included a number of asides which I hope might be helpful to your appreciation and application of the technique.

The first step is to complete column 1, the narrative summary (see Table 12). I wrote this based upon my understanding of the texts provided, Trevor’s and John’s analyses and the audio tape. I started with the purpose (column 1, row 2). This is usually where the process for LogFrame begins. Central to the purpose is the transformation which the project seeks to produce. I then decomposed (or deconstructed) the outputs (row 3) from the purpose and then set out what I considered to be the headline activities (row 4) necessary to achieve the outputs. Finally I set out my view of the goal (row 1). I did this once, reviewed my work, checked the logic and having iterated once more set I out what you see here.

Table 11 The LogFrame

Goal Objectively Verifiable Indicators (OVI)

Means of Verification (MOV)

Assumptions

The higher-level objectives which the project is expected to contribute

Measures (direct or indirect) to verify to what extent the Goal is fulfilled

Sources of data necessary to verify the status of Goal level indicators

Important events, conditions or decisions necessary for sustaining objectives in the long run

Purpose Objectively Verifiable Indicators (OVI)

Means of Verification (MOV)

Assumptions

The transformation which is expected to be achieved as the result of the project (This can be thought of as a root definition in SS-method terms.)

Measures (direct or indirect) to verify to what extent the purpose is fulfilled

Sources of data necessary to verify the status of Purpose level indicators

Important events, conditions or decisions outside the control of the project which must prevail for the Goal to be obtained

Outputs Objectively Verifiable Indicators (OVI)

Means of Verification (MOV)

Assumptions

The results or impacts of the project – that the project should be able to guarantee

Measures (direct or indirect) to verify to what extent the outputs are produced

Sources of data necessary to verify the status of Output level indicators

Important events, conditions or decisions outside the control of the project necessary for the achievement of the Purpose

Activities Objectively Verifiable Indicators (OVI)

Means of Verification (MOV)

Assumptions

The activities which have to be undertaken by the project in order to produce the outputs

Measures (direct or indirect) to verify to what extent the activities are undertaken

Sources of data necessary to verify the status of Activity level indicators

Important events, conditions or decisions outside the control of the project necessary for the production of the Outputs

136 Block 2 Part 4 Reflections on Block 2

Table 12 Column 1 of the Taurus LogFrame as formulated from the perspective of Simon Bell

Goal OVI MOV Assumptions

To make the City of London the premier financial institution in the world and to establish this clearly in relationship with Frankfurt

Purpose OVI MOV Assumptions

A system owned by the City of London Financial Institutions and managed and operated by them – produced in order to place all financial transactions within one overall framework and providing a level playing field for the various parties to the system

Outputs OVI MOV Assumptions

1 A secure, unified transaction system 2 A non-hardware dependent system 3 Software capable of being multi-accessed by people or other

systems 4 A system usable by non-technologists

Activities OVI MOV Assumptions

1.1 Agree unified transaction front-end 1.2 Agree format for technology-based transaction 2.1 Analyse the limitations of software/hardware mixes 2.2 Select best fit solution 3.1 Ascertain the nature of the access forms required by users 3.2 Develop an access approach which can be applied

cross-platform 4.1 Develop an understanding of the work practices of the user

base 4.2 Develop human/computer interface to comply with user

expectations

Aside When LogFrame is used in developing the plan for a new project completing the narrative column often requires many iterations. When working in a team the words and phrases used in any section of the LogFrame may well have been argued over for hours (days sometimes!). The LogFrame has to satisfy a potentially wide range of interested parties and there will always be a degree of disagreement which can manifest itself as conflict. In your own project you will find iterations necessary as you refine your ideas and the goal and purpose of your project shifts.

Before I go on to the project assumptions, I have a further reflection on the framework. Before agreeing on the narrative summary, the practitioner needs to be sure that the vertical logic of the framework is operating. Figure 21 demonstrates the If, Then logic, beginning at the bottom left hand corner.

The practitioner should be comfortable that each aspect leads into the next and that there are no gaps in the vertical logic. Without this assurance, the primary vertical logic of the framework breaks down. Primary vertical logic means that small things achieved will lead to bigger things being achieved and so on. If there are gaps in the vertical logic then further iterations of thinking are needed until the gap is filled.

3 Logical frameworks: a systematic and systemic reflection 137

The assumptions associated with a project are rarely straightforward and consequently rarely agreed by all participants in a project team. Assumptions are difficult to tie down for a number of reasons, the most important of which is that they are taken for granted by at least some of the participants. When someone takes something for granted they will usually object if someone else challenges this, so it is not unusual for project teams to argue about what are and are not assumptions. In your own project you may find it hard to identify your own assumptions, but

important. LogFrame can be a particularly useful in making explicit implicit assumptions.

In Table 13 I have developed the assumptions based on what I know of Taurus and from what the various authors have written.

When I was constructing this part of the LogFrame I realized that if any high level item in the framework changes then all lower items, in all columns, must also be changed. In this case, if the Goal of the Stock Exchange changes then possibly the entire framework changes. This constitutes an insight from the LogFrame – namely that one of the major problems for Taurus was the constantly changing goal and purposes ascribed to the project.

Then the goal

becomes more

realizable

Then the project

purpose is accomplished. If this is so …

If the activities

are undertaken …

Then the outputs are achieved. If the outputs

are achieved …

Figure 21 A flowchart of the If, Then logic

138 Block 2 Part 4 Reflections on Block 2

before the end they should be clear – if not you are missing something tool

From my perspective the assumptions set out in Table 13 seem fairly limited and ‘safe’. They do not set out to say anything contentious about the project itself, the variety of views of the project purpose, stakeholder differences or the political environment surrounding the project. Of course, it is not essential that the assumptions deal with these kinds of issues but the LogFrame provides project planners and assessors with the opportunity to think widely about projects

Superimposed on the assumptions could be a series of arrows that should be ‘read’ from the bottom left hand column upwards and rightwards. The arrows indicate the important If, And, Then logic (see Figure 22) which increases the value of the LogFrame. Most project planning methods assume a flow of sensible ideas and processes. The Logframe however allows us to include assumptions and ‘soft’ considerations in the overall logic of the project plan.

Table 13 Adding the key assumptions to the framework

Goal OVI MOV Assumptions

To make the City of London the premier financial institution in the world and to establish this clearly in relationship with Frankfurt

The Taurus computer system is the method by which this goal is achievable

Purpose OVI MOV Assumptions

A system owned by the City of London Financial Institutions and managed and operated by them – produced in order to place all financial transactions within one overall framework and providing a level playing field for the various stakeholders to the system

An overall framework is both producible and agreeable as well as being technically feasible

Outputs OVI MOV Assumptions

1 A secure, unified transaction system 2 A non-hardware dependent system 3 Software capable of being multi-

accessed 4 A system usable by non-technologists

1 Unification of transaction is technically possible

2 All hardware is capable of running the software

3 Access criteria available to all potential users

4 Technologists/financial analyst interface is clearly understood and explainable

Activities OVI MOV Assumptions

1.1 Agree unified transaction front-end 1.2 Agree format for technology-based

transaction 2.1 Analyse the limitations of software/

hardware mixes 2.2 Select best fit solution 3.1 Ascertain the nature of the access

forms required by users 3.2 Develop an access approach which

can be applied cross-platform 4.1 Develop an understanding of the work

practices of the user base 4.2 Develop human/computer interface to

comply with user expectations

1.1 Such a unified approach can be agreed 1.2 A single format can meet all needs 2.1 There are no mutually exclusive

combinations 2.2 The best fit solution will meet all needs 3.1 Access forms are not mutually exclusive 3.2 Access forms are not hardware specific or

software dependent 4.1 User base work practices can be

explained to non-specialists and confidential practices can be clearly presented

4.2 User expectations are manageable

3 Logical frameworks: a systematic and systemic reflection 139

Then the goal

becomes more

realizable

Then the project

purpose is accomplished. If this is so …

If the activities

are undertaken …

Then the outputs are achieved. If the outputs

are achieved …

and the assumptions

hold true

and the assumptions

hold true

and the assumptions

hold true

Figure 22 A flowchart of If, And, Then logic

Aside I would like to talk briefly about insight in the context of LogFrame exercises. The LogFrame can have the outcome of providing members of the project, or individuals reflecting upon a project, with insights into a project context which they thought that they knew well. Just in the act of juxtaposing goals and assumptions of the project in a common framework can produce significant individual or group insight. As a practitioner, I tend to think that my LogFrame exercise has not been successful if it has not produced at least one good moment of insight in the process of construction or reflection. If I have not had an insight I will usually explore the assumptions again, that is usually where I will be unaware that I am taking something for granted.

Now I turn to the next column of the framework, the Objectively Verifiable Indicators (OVI). My version of these for the Taurus project are shown in Table 14.

140 Block 2 Part 4 Reflections on Block 2

Table 14 Adding the OVI for the Taurus case study

Goal OVI MOV Assumptions

To make the City of London the premier financial institution in the world and to establish this clearly in relationship with Frankfurt

Established to the standards of Siscot by 3/1998

The Taurus Computer system is the method by which this goal is achievable

Purpose OVI MOV Assumptions

A system owned by the City of London Financial Institutions and managed and operated by them – produced in order to place all financial transactions within one overall framework and providing a level playing field for the various parties to the system

In place as a working simulation by 12/1995. Simulation gradually introduced to pilot sites by 6/1996. Overall system in place by 6/1997

An overall framework is both producable and agreeable as well as being technically feasible

Outputs OVI MOV Assumptions

1 A secure, unified transaction system

2 A non-hardware dependent system

3 Software capable of being multi-accessed

4 A system usable by non- technologists

1 Developed by 12/1993, implemented 24 months later

2 Planned and signed off by 6/1993

3 Planned and signed off by 12/1992

4 Planned and signed off by 9/1993

1 Unification of transaction is technically possible

2 All hardware is capable of running the software

3 Access criteria available to all potential users

4 Technologists/ financial analyst interface is clearly understood and explainable

Activities OVI MOV Assumptions

1.1 Agree unified transaction front-end

1.2 Agree format for technology-based transaction

2.1 Analyse the limitations of software/hardware mixes

2.2 Select best fit solution 3.1 Ascertain the nature of

the access forms required by users

3.2 Develop an access approach which can be applied cross-platform

4.1 Develop an understanding of the work practices of the user base

4.2 Develop human/ computer interface to comply with user expectations

1.1 Agreement plan signed off by 8/1992

1.2 Agreement plan signed off by 10/1992

2.1 Comparative analysis report available by 3/1993

2.2 Agreement on selection by Siscot by 5/1993

3.1 Access forms of users compiled by 8/1992

3.2 Access approach agreed by 10/1992

4.1 User base work practice analysis reported by 3/1993

4.2 HCI developed by 7/1993

1.1 Such a unified approach can be agreed

1.2 A single format can meet all needs

2.1 There are no mutually exclusive combinations

2.2 The best fit solution will meet all needs

3.1 Access forms are not mutually exclusive

3.2 Access forms are not hardware specific or software dependent

4.1 User base work practices can be explained to non- specialists and confidential practices can be clearly presented

4.2 User expectations are manageable

3 Logical frameworks: a systematic and systemic reflection 141

The OVIs provide the project with accountability in that they can be used to see whether the project is achieving what it originally set out to achieve. They measure whether activities have taken place, whether outputs have been achieved, whether the purpose is being pursued. In this sense they can measure both the project process and the viability of the overall project design. This could be one of the main benefits for your own use of LogFrame with your project.

Take a good look at the indicators set out in Table 14. Within the conventional logic of a LogFrame these are formal and measurable. Ideally, they should conform to QQT criteria (providing a Quantity of something to be achieved, of a given Quality and to a given Time or schedule). This is sometimes not possible, and in other cases not desirable. In some cases an overemphasis on quantifiable objectives leads to a neglect of the more important qualitative objectives.

Following the development of the OVIs, I now move on to review the Means Of Verification (MOV) of these indicators. My version of these for the Taurus case study is included in the completed LogFrame shown in Table 15.

There is little more to add concerning the development of the means of verification (MOV) in this case. The MOV points are in line with the spirit of the OVIs, in that they do not specify too much detail at this point. They are straightforward and relatively generalized.

The main criterion for a successful MOV is to be ‘feasible’. It must be a thing which can actually be done. This means that there is an iterative process between OVI and MOV development. Figure 23 on page 144 demonstrates this.

I have already mentioned insight as being a valuable output from the LogFrame exercise (e.g. a new learning element which has arisen from applying the framework to a problem). Another desirable output – most specifically in terms of reflecting upon IS project experiences – is measurable accountability which derives from the OVI/MOV exercise (e.g. being able to apply a quality, quantity and time standard to an activity or to the expectation of an output). That is, it results from discussions relating to the two middle columns of the LogFrame.

How does the LogFrame process work?

In the Taurus LogFrame example I have attempted to show you how LogFrame can be applied to a real project. The main learning points about LogFrames which I would hope you would keep in mind are as follows:

^ Engineering versus meaning. LogFrames should not be over-engineered. By this I mean there should not be an accentuation on the engineering of the framework at the expense of using the framework as a thinking tool. Treat it as a means to think through the levels (from activities to goals) and elements (e.g. narrative, assumptions) of a project. It can be a systemic device for inclusive and wide ranging (and shared) thinking.

^ Assumptions. The assumptions column is vital; its value should not be underestimated.

142 Block 2 Part 4 Reflections on Block 2

Table 15 Completed LogFrame for the Taurus case study

Goal OVI MOV Assumptions

To make the City of London the premier financial institution in the world and to establish this clearly in relationship with Frankfurt

Established to the standards of Siscot by 3/1998

Siscot committee minutes The Taurus computer system is the method by which this goal is achievable

Purpose OVI MOV Assumptions

A system owned by the City of London Financial Institutions and managed and operated by them – produced in order to place all financial transactions within one overall framework and providing a level playing field for the various parties to the system

In place as a working simulation by 12/1995. Simulation gradually introduced to pilot sites by 6/1996. Overall system in place by 6/1997

Siscot committee minutes An overall framework is both producable and agreeable as well as being technically feasible

Outputs OVI MOV Assumptions

1 A secure, unified transaction system

2 A non-hardware dependent system

3 Software capable of being multi-accessed

4 A system usable by non-technologists

1 Developed by 12/1993, implemented 24 months later

2 Planned and signed off by 6/1993

3 Planned and signed off by 12/1992

4 Planned and signed off by 9/1993

1 Signed off by Siscot 2 Signed off by Siscot 3 Signed off by Siscot 4 Signed off by Siscot

1 Unification of transaction is technically possible

2 All hardware is capable of running the software

3 Access criteria available to all potential users

4 Technologists/ financial analyst interface is clearly understood and explainable

Activities OVI MOV Assumptions

1.1 Agree unified transaction front-end

1.2 Agree format for technology-based transaction

2.1 Analyse the limitations of software/hardware mixes

2.2 Select best fit solution

3.1 Ascertain the nature of the access forms required by users

3.2 Develop an access approach which can be applied cross-platform

4.1 Develop an understanding of the work practices of the user base

4.2 Develop human/ computer interface to comply with user expectations

1.1 Agreement plan signed off by 8/1992

1.2 Agreement plan signed off by 10/1992

2.1 Comparative analysis report available by 3/1993

2.2 Agreement on selection by Siscot by 5/1993

3.1 Access forms of users compiled by 8/1992

3.2 Access approach agreed by 10/1992

4.1 User base work practice analysis reported by 3/1993

4.2 HCI developed by 7/1993

1.1 As approved by monitoring consultants

1.2 As approved by monitoring consultants

2.1 As approved by monitoring consultants

2.2 As approved in Siscot minutes

3.1 As approved by monitoring consultants

3.2 As approved by monitoring consultants in compliance with user committee

4.1 As approved by monitoring consultants in compliance with user committee

4.2 As approved by monitoring consultants in compliance with user committee

1.1 Such a unified approach can be agreed

1.2 A single format can meet all needs

2.1 There are no mutually exclusive combinations

2.2 The best fit solution will meet all needs

3.1 Access forms are not mutually exclusive

3.2 Access forms are not hardware specific or software dependent

4.1 User base work practices can be explained to non- specialists and confidential practices can be clearly presented

4.2 User expectations are manageable

3 Logical frameworks: a systematic and systemic reflection 143

^ Iteration. A LogFrame needs to be worked and reworked. It should not be set in stone. Once a satisfactory first draft is accepted by those involved, it can be the basis for project implementation; but it needs to be constantly reworked in the light of project experience. This, of necessity, means that the framework will be an abstract of the project detail and cannot contain all the detail.

^ Brevity. This is related to iteration. A LogFrame used as an aid to thinking by the designer must be a reasonably brief affair, usually on one side of A4. Part of the discipline of a good framework is the ability to focus the exercise on the matters of main importance leaving the detail for later exercises as implementation needs follow from design needs.

^ Being systematic. The sequence as I have set out here conforms to what some exponents (e.g. Team Technologies) see as being orthodox. This may not be best for your context. So long as you are systematic in the application and you ensure that the linking vertical logic, horizontal logic and diagonal logic are all correct, then the boxes can be completed in any order. For example, vertical linking logic might proceed like this:

activities ‹ outputs ‹ purpose ‹ goal;

horizontal logic might proceed like this:

narrative summary ‹ objectively verifiable indicators ‹ means of verification ‹ assumptions; and

diagonal logic could proceed like this:

narrative summary ‹ activity ‹ assumptions ‹ narrative summary ‹ outputs and so on.

Reflecting on Taurus

Taurus was a much larger and more complex project than I have described in the LogFrame set out above. Taurus involved a very large number of

striving to be as precise and demanding as possible

potential cycle of compromise as

precision is traded off against feasibility

OVI Column Objectively verifiable

indicators Conforming to QQT criteria

striving to be as feasible as possible

MOV Column

Means of Verification Conforming to feasibility

criteria

Figure 23 An activity sequence diagram of the trade off between OVI and MOV

144 Block 2 Part 4 Reflections on Block 2

teams all working on the various elements of the eventual IS and required a large amount of collaborative working between these teams. However my aim was to show you how a LogFrame could be used as both a project planning tool and as a device for reflecting on a case study or project. In the process I have had one insight, namely that Taurus suffered from too many changes of goal and purpose. I recognized from the vertical logic of the framework that changing the goal had far wider and more fundamental ramifications than might be otherwise be apparent.

3.2 Reflection upon HS-method and the SS-method

I will now move on to apply LogFrame for reflecting upon and comparing the HS-method and SS-method as developed by Trevor Livesey and John Robson in Parts 2 and 3. My intention is to review HS-method and SS-method – comparing them as different but complementary systems methods. I then want to use the LogFrame as a device to explore how a either a HS-method project or a SS-method project can be evaluated. My intention is to improve your understanding of the two methods and to apply the LogFrame as a tool for planning or evaluating projects of all types. In this way I hope to provide you with the capacity to apply any or all three to your own project work within T306.

In this block SS-method and HS-method are seen as being complementary but different ways of understanding and managing complex IS contexts and so, by inference, a wide range of project contexts in other domains. In Parts 2 and 3 of Block 2 the Taurus project was analysed and ways forward for learning from the project were set out. This demonstrated that each method applies different tools and techniques to develop different but powerful views of an IS project.

In order to develop the reflection on the use of the two methods it is useful to compare and contrast some of the key features which they encompass. Five key features of the methods are compared in Table 16 (overleaf).

Table 16 does not capture all the similarities and differences between the methods. Here are some further points which seem to me to be significant.

^ Both HS-method and SS-method are different but useful means to think about problems. The SS-method seems to provide a way to think about a project in broad terms without prejudging the format of the potential problems or tasks which should be engaged in. HS-method appears to be a valuable way of developing a quantitative and measurable model of a ‘solution’ to a given problem.

^ They appear to have specific contexts in which they are of more or less value. For example, SS-method would appear to be a valuable method to apply when first thinking about and trying to understand a problem within a given situation. In contrast HS-method seems best fitted to thinking about a situation which has already been considered and for which a degree of understanding and agreement already exists.

^ They constitute different and not opposed means for discovery and exploration. The two methods both conform to a learning cycle and, if used systemically, can lead to complementary outcomes – e.g. the overview and understanding of a complex context using SS-method and the development of a rigorous and structured model for exploration using HS-method.

3 Logical frameworks: a systematic and systemic reflection 145

^ They require different skills from the practitioner. For example in order to undertake a SS-method the practitioner needs to be able to facilitate groups, empathize with stakeholders and work participatively An HS-method practitioner often undertakes the analysis in isolation, is more of an expert and often provides a model ‘solution’ to clients. In the SS-method the skills needed to produce a rich picture as a representation of a context are quite different from the logical/rational skills required to produce a conceptual model.

Aside This perceived need for a range of skills has been noted by some practitioners and has confirmed to some that SS-method needs to be undertaken by teams working together with a wide range of skills. SS-method is best if it is developed with or arises from multiple perspectives. For example, I worked with a small team on a project for a business in Manchester, UK. The business was concerned with developing tours and visits for high-ranking delegations from around the world. While working with the team on a project to develop better ways of handling and evaluating such visits, it was discovered that one member of the team had a ‘natural’ capacity to draw pictures which caricatured and engaged other members of the team. Another member was extremely gifted at managing the conversations which the team had, whilst a third member was used as a reference point – she was very conversant with current practice and the rules and regulations surrounding the visits programme. She also had a very systematic approach to developing conceptual models. Each team member brought a different but complementary gift to the SS-method process.

Table 16 Comparison between HS-method and SS-method as used in IS exploration

Reasons for development of the method

Aim of the method

Area of application of the method

Method by which SS- or HS-method applied

Key words and concepts

Hard systems method (HS-method)

HS-method (as used in T306) was developed in the Open University as a means to provide a systemic framework for quantitative analysis of problem contexts

The aim of the methodology is to provide clients with tested and modelled means to deal with particular problems

The area tends to be in formal and quantifiable contexts where issues are not contentious and factual information is readily available (generally deals with bounded and problems)

The accurate representation of elements of the problem within a framework in which they can be manipulated, modelled and tested

client, decision maker, system description, objectives and constraint, measures of performance, routes to objective, modelling, evaluation choice

Soft systems method (SS-method)

The failure of formal and quantitative methods to deal with messy contexts and to provide means to develop new solutions to persistent problems

To achieve understanding of organizational problems leading to learning and improvement

The area tends to be informal and messy where issues are not agreed upon and outcomes are far from certain (generally deals with unbounded problems)

The development of conceptual models of new and improved systems through which participants can identify weaknesses and stimulate meaningful change

rich pictures, tasks and issues, relevant systems, root definition, CATWOE, conceptual models, comparison

146 Block 2 Part 4 Reflections on Block 2

^ HS-method and SS-method can be undertaken in a range of ways which make them more or less systemic

You might ask what do I mean by this last statement? Any method can be undertaken in a manner which renders it:

^ more or less participative;

^ more or less inclusive of a range of views;

^ more or less holistic in its vision of problems;

^ more or less concerned with boundaries and relationships;

^ more or less interested in understanding the nature of control and influence in a given system;

^ more or less concerned with personal perceptions of processes; and related to this

^ more or less able to consciously move between mindsets – for example systemic (and all that this means) and systematic (and all that this means).

In this sense it is possible to undertake a ‘systems’ approach to problem solving which is no more than going through a list of tools and techniques (such as those in column 6 of Table 16). This could be called a systematic systems approach. To be systemic means:

^ being participative;

^ being concerned with other views;

^ being concerned with holism;

^ focusing little on designating boundaries or relationships;

^ indicating little interest in understanding control;

^ being aware of the personal perceptions which colour all exploration;

^ being epistemologically aware.

There are correlations here to purposeful and purposive projects – to approaches which are systemic and systematic.

In my own experience I have worked on projects which have been described in their own literature as participative and holistic in intention. I have worked with individuals and groups which claim to be systemic in approach. On at least two occasions I have been surprised to see such groups actually developing a clever pretence (I am not sure if was intentional or unintentional) of systemic behaviours whilst actually perpetuating closed, restrictive, narrow and (on one occasion) despotic approaches to problem solving. I found these experiences personally informative and illuminating. My main learning outcome was to ‘look beneath the words to the actions’. It was not so much in what groups and projects say of themselves but rather the way they are perceived by others and the way their actions are performed that indicates a systemic or non- systemic approach.

Deciding to use LogFrame in reflective analysis of Taurus

So far in this section I have reflected upon the way in which SS-method and HS-method relate to each other and can be seen as being applied in a more or less systemic manner. I now want to move on to compare the two projects, undertaken by Trevor and John, using LogFrame as a means of summarizing and comparing the two studies. In this way I hope to gain insight into how the methods differ in analysing the Taurus case. From

3 Logical frameworks: a systematic and systemic reflection 147

this I hope to draw out some more general lessons about when and why SS-method and HS-method might be applied to other projects or in other domains.

As a first step in this comparison I have used John Robson’s SS-method analysis of Taurus as the basis for the LogFrame set out in Table 17. Clearly this is a personal construction from his report. I am satisfied that it deals with the key issues in his report.

Notice that I have used John’s root definition as the purpose of the LogFrame and his activities from the conceptual model as the activities within the framework. This allows me to develop my view of the likely outcomes in line with these two SS-method components. I have also added my view of the related assumptions. The main systems of interest which John seems to have developed in his SS-method are:

^ The focus on trading (as developed under the root definition in the purpose).

Table 17 Reflective narrative summary and assumptions of a LogFrame of John Robson’s SS-method of Taurus

Goal OVI MOV Assumptions

London remains a premier financial institution

Purpose OVI MOV Assumptions

A Stock Exchange system for electronic transfer and settlement of listed equity securities traded by stockbrokers (on behalf of their clients), which complies with requirements of UK government agencies

The UK need for this system remains and the outcomes are generally agreed to be both beneficial and at pace with global developments in the industry

Outputs OVI MOV Assumptions

1 Regular and accurate confirmations of price information

2 Clear and concise client information on price

3 Sale orders processed according to agreed format

4 Purchase orders received according to agreed format

5 Trading undertaken to the accepted standards and efficiencies as set out by traders

6 Payment procedure operational 7 Ownership transfer noted and agreed by

all parties

1 Price information formats do not change dramatically over time

2 Advisory process keeps pace with changes in the City system

3 Sale order format remains valid and trustworthy as an IT ‘virtual’ entity

4 Purchase order format remains valid and trustworthy as an IT ‘virtual’ entity

5 Trading is monitored for continuing efficiency and honesty

6 Payments are to-date on an agreed average of cases

7 Ownership on the virtual system remains agreed and not open to fraud

Activities OVI MOV Assumptions

1 Obtain price information 2 Advise clients on prices information 3 Receive sale orders for equities 4 Receive purchase orders for equities 5 Agree equity trades 6 Make or collect payments 7 Register ownership

1 Price information available in format acceptable to all parties

2 Advisory process undertaken under effective conditions of privacy and accuracy

3 Sale orders in agreed format 4 Purchase orders in agreed format 5 Trading process undertaken under effective

conditions of privacy and accuracy 6 Payment procedure agreed and majority of

parties consent and conform 7 Ownership registration legally binding

148 Block 2 Part 4 Reflections on Block 2

^ The simplification of the trading process to seven major activities (as developed in the activities list).

^ Therefore, the need for the project to develop around these seven as the core activities (as also indicated in the outputs).

It is worth noting here that John most certainly did not use the SS-method to look at the political and ethical considerations behind Taurus or to undertake a root-and-branch analysis of the Taurus assumptions. He also did not deal with institutional conflicts. He has focused on the systems of interest provided for him in his terms of reference for rethinking how Taurus might have been undertaken using a systems method. In later blocks the Course Team will be introducing other systems approaches to think about the fundamental viability of context and the decision-making autonomy of those involved in it.

SAQ 49

Produce columns 1 and 4 of a LogFrame of Trevor’s HS-method of Taurus. Indicate the main systems of interest which you think Trevor developed in his project

Please ensure that you have undertaken the review of Trevor’s work before you move on. It will provide you with some insights into the next reflective exercise.

Engaging and experimenting again

When I first saw the work which John and Trevor had done I thought it would be interesting if their analyses could be linked together and used to develop an overall view of the project. This would provide a rounded vision of the project – developing a useful background to the problems with which Taurus was attempting to grapple, an activity plan for developing a computerized system and then the ways in which this system could be modelled and assessed. The two analyses complement each other – developing linked and non-contradictory views of Taurus. This complementarity between HS-method and SS-method views is not always present and certainly it would not be advisable to think that SS-method and HS-method can be used as ways of invariably gaining a consensus view of a complex IS (or any other) project.

However, in the Taurus case the two methods developed different but useful and compatible views of the project whole. Whereas John’s review identified the main processes which might be engaged in to develop a successful Taurus, Trevor’s seems to assume this, take it forward and develop a quantifiably justified plan for the development of the processes. It may be useful to consider these views together looking at column 1 of each LogFrame together (see Table 18 overleaf).

It is always possible to read too much into an analysis into a complex domain but several key observations can be made at this time.

^ SS-method and HS-method can be used to complement each other as analysis methods (but see point below). As already indicated, it is often useful for different practitioners to undertake different elements from each analysis because different people will have different capabilities and skills and this encourages a freshness of touch. However, this is

3 Logical frameworks: a systematic and systemic reflection 149

not essential and in learning to use SS-method and HS-method it is necessary for the practitioner to become familiar in applying all elements and reflecting on their use.

^ SS-method and HS-method might or might not complement each other but they will usually show different things and come to different and useful comparative conclusions. In this case John’s analysis reviews the basis for the case of Taurus. Trevor’s, in a sense, assumes this basis and builds what he feels and justifies as a low risk project. Each view is different but potentially useful.

^ Logical frameworks can be used as devices to put together and compare the results of SS-method and HS-method. They can be applied as means to develop and compare without being prejudicial to either method. More fundamentally, a LogFrame can be developed from an SS-method or an HS-method analysis. Such an exercise is useful to formalize and structure a systematic project plan from the use of the method as well as being a basis for considering how the project can be monitored and evaluated by making use of the OVI and MOV columns.

My initial objective was to provide you with the necessary tools to be able to use the LogFrame to critically assess IS projects and the hard and soft methods which have been used to explore it. From this basis I hope you will be able to apply HS-method, SS-method or LogFrame within your own project context (be it in the IS domain or not) and to reflect critically and creatively on your own project experiences.

4 A systemic reflection on Block 2: experiencing and observing again

ACTIVITY 28

Turn to your learning album now and consider:

^ What elements of the two approaches (HS-method and SS-method) did you find personally most interesting? Consider why you found them so. Do have you a personal sympathy for either?

^ Could you see a way to blend hard and soft approaches? Is the learning cycle useful for this?

^ Can you see a way in which systemic approaches can be systematic?

^ How did you own hard and soft approaches compare and contrast with the approaches set out here?

^ How might you apply a LogFrame approach in a systemic manner in your own work?

How might you use these approaches in your projects?

Jake writes ...

150 Block 2 Part 4 Reflections on Block 2

Table 18 Comparing the first columns of the LogFrames of John and Trevor’s analyses

John’s column 1 Trevor’s column 1 Comments

Goal

London remains a premier financial institution

Goal

Preserve the good name of the City of London and the London Stock Exchange

These are harmonious goals – good name and reputation being the basis for a premier institution

Purpose Purpose

A Stock Exchange system for electronic transfer and settlement of listed equity securities traded by stockbrokers (on behalf of their clients), which complies with requirements of UK government agencies

Open tender for three systems integrators to build competitive prototypes and winning tenders to build Pilot and phased implementation

Trevor’s purpose takes John’s view forward. It develops the overview of the project set out by John and then provides a plan for developing a new project

Outputs Outputs

1 Regular and accurate confirmations of price information

2 Clear and concise client information on price

3 Sale orders processed according to agreed format

4 Purchase orders received according to agreed format

5 Trading undertaken to the accepted standards and efficiencies as set out by traders

6 Payment procedure operational

7 Ownership transfer noted and agreed by all parties

1 Approve winning tender

2 Prototype built 3 Prototype piloted 4 Pilot undergoes

phased implementation

The trend was set at the level of purpose. With John’s approach we have the sevenfold overview of a process, a set of activities, which together constitute a summary of what is needed to develop a workable system. With Trevor’s work we see a means to take this forward in terms of four key project tasks

Activities Activities

1 Obtain price information

2 Advise clients on prices information

3 Receive sale orders for equities

4 Receive purchase orders for equities

5 Agree equity trades 6 Make or collect

payments 7 Register ownership

1.1 Advertise for tender 1.2 Shortlist 1.3 Approve 2.1 Specify and agree

prototype outline 2.2 Specify and agree

prototype project processes and procedures

2.3 Develop prototype 3.1 Specify and agree

pilot procedures 3.2 Institute piloting 4.1 Specify adoption

rates and processes for pilot

4.2 Monitor and evaluate implementation

Again Trevor provides a degree of activity which is not present in what John has set out. John’s model is the basis for the logic of a system. Trevor’s is the basis for an IT project to achieve this logical system

4 A systemic reflection on Block 2: experiencing and observing again 151

SAQ answers and comments

SAQ 1 For me the key lies in the word failure. As you may have noticed in Activity 2 it is uncomfortable to admit to failure and even more uncomfortable to discover your own contributions to the failure. This must be even worse in high profile cases that attract a lot of publicity. Who wants to own up to contributing to wasting £60 million of tax payers’ money? So my speculation is that this is the most significant factor in inhibiting learning from previous failures.

There are certainly many other factors. One is that there will be serious disagreement about the cause of the failure and who is to blame. Unfortunately any argument about blame will always inhibit learning – the people involved will be protecting themselves in some way rather than being open to discovering what they could learn.

Another factor will be the large numbers of people involved in the projects. Relatively few people will have an overall view of the project. Most of those working on it are engaged at a very detailed level which is well removed from the level at which failures are identified. It is also the case that projects lasting several years, as most of the big schemes do, will involve a significant turnover of staff at all levels – so the people in post at the end of the disaster can assume that the errors were all made by their predecessors.

SAQ 2 There is no doubt that there is a wide variation in the implied or assumed meaning of the word system in ‘Information System’. However it has been my experience that most frequently people who use this phrase are referring to a concrete entity that they perceive existing in the world out there. When pushed to define or explain it my guess is that most users of the phrase would include the hardware and software and communications links within the ‘System’, but would probably exclude the operators, data entry staff, end-users – i.e. they would exclude the people. The more sophisticated would try to include a positivist view of information in their description, probably by stating that the ‘System stores information’ or something similar. This use of the word System is similar to the way that it is used by astronomers when they describe the Solar System – it is a name attributed to a defined collection of entities in the physical world. It is assumed that there is no problem in establishing the existence of the external reality to which the name is applied.

This is in sharp contrast to the epistemological position taken in Block 1. There it was argued that there was no certainty about our ability to ‘know’ the external world. Further it was argued that systems were best regarded as mental constructs, adopted by a particular person with a particular perspective and purpose in mind. Although the authors of Block 1 stressed that systems practitioners had a choice in this regard, their own preferences were clear, they regarded systems as powerful mental constructs for dealing with complexity.

SAQ 3 In Block 1 the starting point for engaging with complexity was a rich picture and this is a strategy recommended in this block also. Sometimes a rich picture will not succeed in capturing the complexity and you may have to employ another type of diagram, but the time you spend working on the rich picture will still be useful. My version of the rich picture is shown opposite (Figure 24).

I felt it was important to include Sue in the picture. I also included the other main actors, the Board of Directors and the city firm.

152 Block 2

Figure 24 Rich picture of FTS case

SAQ 4 Sue’s perspective is well set out in Box 5, since she wrote it. Clearly she is interested in gaining work, in finding out what would be best for the client and, I think, in providing a win-win context for working together in the future. Her description of the situation indicates that she is fully engaged with the complexity of the technical side of the situation. My suspicion is that she was less well- engaged with the requirements of the Directors, particularly their desire to avoid taking risk with the development.

The perspectives of the other participants has to be inferred from Sue’s descriptions, but they can be established fairly reliably. The Directors clearly wish to improve their information system and wish to avoid either an overly expensive solution or one that does not work. They will be wary of IS contractors and consultants since they have heard of the high failure rate, so my assumption is that they based their decision largely on their perception of the risk involved with each alternative. The Directors would be fully engaged with the business aspects of the necessary change, but probably less aware of the technical aspects.

The city firm are rather denigrated in Sue’s account – understandably so since they won the contract and she must inevitably feel resentful. However it is clear that the city firm would perceive the situation as one where their successful software could be applied. Indeed given their history they would probably only perceive the aspects of the situation that matched the functionality of their software and would probably not ‘see’ the areas of potential problems. Their engagement with the situation would therefore be the least, both because they spent less time with FTS and also due to this bias in their perception.

SAQ answers and comments 153

SAQ 5 My versions are shown in Figures 25(a) and 25(b). It seemed to me that the director’s perspective would include the IS system within FTS and that there would be a significant number of external factors, such as competition and world events, that would be significant for them. Sue’s perspective is more focused on the issues central to the proposed IS system.

insurance systems

brokers oil transport

FTSdirectors

existing IS new IS ?

old data accounts

IS suppliers

auditors

IS consultants

tax calcs

Figure 25(a) FTS systems map from the director’s perspective

FTS

directors users

existing IS accounts

new IS old data

audit

hardware suppliers

software design

methods IS design and supply

tax calcs

Figure 25(b) FTS systems map from Sue’s perspective

154 Block 2

SAQ 6 (a) How well did the University serve you when you first received your guidance

for using the student conferences on FirstClass? It may be that the University has a self-image as an Epoch 6 organization, but that many of the users feel that Epoch 1 is closer to the mark! Answers to questions like the following are often powerful indicators of the mind set embedded in the Information System:

Did I feel welcome to the system?

Did the system appear designed for someone like me?

Was I given support when I needed it? Was I offered support?

Answers that tend to indicate a non-caring or uninterested approach to providing IS might indicate that you would be right in suggesting an Epoch 1 tendency. Answers which indicate thought for your needs and provision of help and guidance would indicate a tendency away from the early epochs.

(b) My perspective is that there is a lot of value in the Epoch 4/5 combination in terms of the focus on users and interfaces. My experience of the globalization of IS is a sense of increased not decreased remoteness. There is also a tendency to assume that existing solutions work and the enthusiasm and potential of the current situation will make problems disappear. Maybe a more considered focus on the user as centre of the system might be better.

(c) My view was that Sue’s perspective and mind set was consistent with Epoch 4. She saw herself as a facilitator and was engaged with a user focused system.

SAQ 7 Peter Checkland and Sue Holwell differentiate quite clearly between:

^ data, which are said to be facts ‘out there’;

^ capta, which are selected facts – facts which I have selected because I think they are potentially informative to me;

^ information, which consists of meaningful facts;

^ knowledge, which they describe as more permanent meaningful facts – if you like facts having lasting meaning to the individual in the context.

Apart from the inclusion of the word ‘capta’, the definition is quite straightforward.

Information = data or facts which are meaningful to me.

Personally I find that they have cleared up a lot of the confusion around the term information, but they have not resolved the issue of whether there really exist ‘data’ independent of an observer. This is similar to, but more pointed than, the issue of whether ‘systems’ exist ‘out there’ or are merely mental constructs.

SAQ 8 The first example, involving the number of windows, was a very basic conceptualization about the unit called a window. The computer program wanted to know about the entities that fill holes in walls. The people who responded 3 were looking at the arrangement within the major frame elements of the unit. The people who responded 6 were looking at the numbers of panes of glass. These are all valid, but quite different, conceptualizations of what a ‘window’ is.

The second example involving sales and commissions is fraught with difficulty because so much is riding on the way of defining a sale. Most commercial organizations have detailed contracts which they give to sales staff when they join the company. The nature of the problem is only apparent when setting up a scheme from scratch. In fact most financial ‘data’ in businesses are subject to this

SAQ answers and comments 155

sort of uncertainty of definition – it is one of the reasons why accountants are able to claim such large salaries! It is only people not familiar with accounting definitions that think that items such as sales, turnover, profit and so on are unambiguous!

The third example rests upon a belief about the nature of the environment in which the Earth exists. The meteorite and comet impacts that have occurred over the last few hundred years have been in remote areas, such as Siberia and the Saudi Arabian desert – so there was an untested assumption that they did not happen. False, as it happens!

SAQ 9 (a) This is information to a HBOS shareholder and rests upon the

conceptualization of the stock market and its operation.

(b) This is certainly information to you. For academics involved in the course, for whom student’s performance is one criteria of the success of the course it is capta. This is because to the academic it is the aggregate of all students’ scores that provides them with information, an individual score is a significant component. It rests upon a conceptual framework for measuring academic achievement by scoring.

(c) This is an example of data. It is unlikely to be of particular interest to the Concorde passenger since they are not intending to go outside. They understand the data because they share the concept of rain as a climatic condition.

(d) The communication will not be understood by the tribesman since he will not share the concepts of money, credit cards or debt. So this is not even data to him, just gibberish (and probably communicated in a language – English – he doesn’t understand anyway!)

SAQ 10 (a) When I re-read the case I found that I was a lot more sceptical about the

proposed project. One feature that struck me very strongly was that historical data had been stored in different formats; it struck me as a problem to convert them all into the same format – they might well be based upon different conceptualizations.

(b) Almost universally the word information was used where data should have been used. The whole project is actually a data storage and processing project – because only human beings can impart the meaning that converts data into information.

(c) Sue is fairly consistent in using information as a substitute for data. Towards the end there are references to user information, but as far as I could tell this was still the data being presented to the user.

SAQ 11 Sue’s main context is a consultant seeking further employment. Within the story she comes across as the victimized heroine, the one who has done the thorough job and who has been defeated by the car salesmen from the snazzy company. I have deliberately exaggerated this description because it became clear to me that Sue was certainly not an unbiased observer of her competitor’s performance. It also occurred to me that she had perhaps underestimated the degree to which the Directors needed to be wowed and convinced by a good sales pitch. When well done this can create the confidence to take a risk that decision makers often need.

156 Block 2

SAQ 12 Various versions of Kolb’s learning cycle were represented in Block 1. The key cycle is shown again in Figure 26.

The four stages can be named differently, but the key feature of the cycle is that there is an experience, some sort of reflection on that experience that leads to knowledge that then informs action that leads to new experiences.

Below are some of the alternative words and phrases that capture the essence of the process.

Experience: Observing, noticing.

Thinking: reflecting, digesting.

Decision: knowing, conceptualizing or developing theory.

Action: intervening, engaging, experimenting.

SAQ 13 It seems to me that the people engaged in the IS failures are completing the learning cycle loop, but they are doing so in an unhelpful fashion. They certainly observe the problem: so the experience step is there. I am confident that they then think about the perceived problem: so the reflection or thinking step is also in place. According to the account in the section, the participants also resolve to behave differently next time, so there has been some decision and development of their own theory about the situation. Finally there is evidence that they do act differently, so the loop is complete.

So the elements of the learning cycle are in place, but something continues to go wrong. My first observations about this are:

(a) Reflecting on how to change other people and their behaviour is never as effective as reflecting on how to change oneself. People do think a lot and act a lot on the basis of ‘blame stories’, but rarely with positive results.

(b) The type of learning that is exhibited is very limited. It is what I call ‘first-order learning’. There is no reflection on whether the goals that have been set or the methods to achieve them are correct. ‘Second-order learning’ questions the goals and methods and is often productive when first-order learning has repeatedly failed.

This analysis indicates that simply completing the steps of the learning cycle is not sufficient to ensure productive learning is taking place.

thinking enables

decision

leads toaction generates

experience

provokes

Figure 26 Kolb’s learning cycle

SAQ answers and comments 157

SAQ 14 Item (a) says:

It is extremely unlikely that the initial design will be ‘perfect’. One of the reasons for this is that clients of such systems are rarely able to articulate all their requirements clearly.

The learning cycle involved here is the client’s cycle of learning how to specify requirements. It is only after seeing the result of a specification that the client can see what was inadequate or incorrect about it – but by then it is too late. This explains, at least in part, why the specification is critical to the whole project, but that it will not be resolved satisfactorily just by paying more and more attention to it at the beginning.

Item (b) says:

With projects that take years to implement the data requirements are likely to change, and thus be out of date even before the system is implemented.

This is particularly true of Information Systems which are implementing items such as tax, Social Security benefits and Child Support, where the legislation changes the definition of the data quite regularly. However even in smaller scale examples changes in the external environment of an organization, whether by legislation or market, or changes in organizational goals will have a significant impact on the data that needs to be collected and processed.

Item (c) says:

The introduction of the System will itself generate change within the organization, both social changes and changes in the perceived data requirements.

This is extremely important because the introduction of a new Information System will certainly have an impact on everyone’s experience and should set off a learning cycle related to how they carry out their role in the organization. If that cycle is then immediately frustrated by an inflexible System there is likely to be a high degree of antipathy, even hostility, to the System which will increase the likelihood of its failure.

SAQ 15 Whereas the issue of methods and methodologies was discussed in general in Block 1, I am looking at them from the distinct point of view of IS projects. To help me explain the difference I have taken another source, Websters dictionary, which describes the two terms as follows:

method:

‘a systematic procedure, technique, or mode of inquiry employed by or proper to a particular discipline or art (2): a systematic plan followed in presenting material for instruction b (1): a way, technique, or process of or for doing something (2): a body of skills or techniques’

methodology:

‘a body of methods, rules, and postulates employed by a discipline: a particular procedure or set of procedures 2: the analysis of the principles or procedures of inquiry in a particular field’

It would appear that the main difference between the two ideas is that methodology includes the analysis of the principles within a field (e.g. the study of the way in which systems principles are applied) whereas method deals with the

158 Block 2

form or process by which such principles are applied (e.g. the orderly application of the principles). Method deals with undertaking a set of tasks and routines, methodology deals with studying and analysing the principles by which the tasks and routines are organized. In this sense a methodology fits alongside an approach in the activity sequence diagram (see Figure 5) but without a clear statement of which comes first – it all depends on the situation and the analyst. methodology is the process of engaging and reflecting by which the method is grown.

SAQ 16 There are many items here, but five might include:

Big Bang is a success – this might lead to unreasonably high expectations of Taurus.

Stock market crash affect on the development of Taurus and on expected cost-savings.

Dispute over who regulates Taurus leads to lack of ownership and control.

Software writing problems leads to increased costs.

Problems with IBM security package.

My attempt at setting these out as an influence diagram with five other notable points appears in Figure 27 (see overleaf).

You could equally well have applied either a multiple cause diagram or a systems map. There are a number of relationships within the diagram – the relationship of the Siscot committee to its authorities, the relationship of software teams to the development to Taurus itself. However, the most important relationship which I can define is the way in which the various elements are related together by power (in the sense of powerful people and groups), cost and time.

Big Bang

Siscot committee

Parliament

regulationStock Market

Taurus 1

software

technical system

cost

IBM security packages

Taurus Project viability

Figure 27 Influence diagram taken from the Taurus chronology

SAQ answers and comments 159

In my answers to the following SAQs I have been able to draw on wider sources than those available in Audio notes 1.

SAQ 17 This question might be seen as a trap – encouraging you to see Taurus as an example of a top-down imposition of the early epochs. Yet Taurus engaged numerous committees and Helga Drummond points out that the managers of the project went out of their way to be inclusive – this points more at epoch 5 type behaviour. The main point might be that the project involved numerous mindsets and at times different sets dominated. The fact that different epoch perspectives were involved meant that problems were inevitable because of the tensions this caused. Maybe a major point is that there was confusion over exactly which way the project was to be driven – they never sorted out what kind of a project Taurus was expected to be? As Helga Drummond notes ‘Taurus meant many different things to many different people’.

SAQ 18 It seems to me that Taurus was often (if not always) obviously systematic – it had a stage-by-stage approach, but then the processes were never put together in an overall whole as such. It remained a series of related processes relying on piecemeal, reactive developments but not working to one systemic outcome.

Maybe one of the most remarkable aspects of the Taurus project is that the Chair of the British Bankers Association working party on Taurus could be confidently announcing eventual success for the project which we now know failed barely a month later.

SAQ 19

Table 19 1986 SWOT of Taurus (project’s inception)

Strengths

Financial backing Technical expertise Legacy of success (Talisman) Political support Financial expertise

Weaknesses

Unclear scope of project Unclear command line Unclear line management Escalating demands Escalating expectations

Opportunities

To be first To put the city of London ahead To develop new expertise Competitive advantage Speed efficiencies

Threats

To be over-extended To take on a high risk venture IT driven system Lack of accountability To fail utterly

SAQ 27

Table 20 SWOT of Taurus (project’s cancellation)

Strengths

Tested technical expertise Hard lessons learned (CREST)

Weaknesses

Demoralized staff Legacy of failure Lack of trust in user community Impoverished resources Scepticism about all IT ventures

Opportunities

To learn To show the ability to develop new ideas To redesign IS projects To reassess IS priorities

Threats

To lose a global market To lose international reputation To lose out on new IS ventures To fall behind terminally to Frankfurt

160 Block 2

SAQ 21 Maybe the most surprising thing is that Taurus provided a valuable lesson in how not to do an IS project. If this were to be thoroughly explored it might lead to the development of new and innovative approaches to IS projects. The opportunity arising from SWOT was to develop new IS in the light of priceless(!) lessons learned in how not to do it.

SAQ 22 Perhaps the major indicator was the sheer scale and unclear scope of the project and the lack of consideration of the range of elements which could go wrong and the unclear line management to deal with them. It almost appears that the project team (in so far as the Board, etc. formed a single team) could not believe that money and technical expertise could fail. The effect of this failure on that mindset must have been devastating.

SAQ 23 The HS-method in T306 appears as shown in Figure 7. In Figure 28 I have set out how other hard methods might map onto this cycle as discussed in the hard review. For me the main points for mapping were:

1 Investigating the existing situation: information gathering, problem identification, feasibility study.

2 Analysis of the existing situation and the provision of a solution to the problem by designing a new system on paper.

3 Implementing the solution.

4 Evaluating its effectiveness.

This is very much based on my interpretation (or mental model) of the method and cycle – yours may differ somewhat.

experience or evaluate

model or experiment or evaluate

reflection or investigation

identify and abstract or analysis

experience or evaluate

Figure 28 An activity sequence diagram of the HS-method and other hard methods as a learning cycle

SAQ answers and comments 161

SAQ 24 In my example (Table 21) I have set out the major SWOT elements as I have experienced them in using the method in the IS context. You will have developed your own thinking in reading the text to this point but will probably not have such a specific set of ideas about the (for example) opportunities provided by the use of HS-method.

Table 21 SWOT of HS-method and IS

Strengths

Clearly agree on objectives Quantifiable measures of success/failure Assessment of alternative routes Sequential development

Weaknesses

Problem if objectives are unclear Unable to deal with unquantifiable measures of success/failure Only able to assess quantifiable alternative routes Sequentialism might lead to weak feedback from stage to stage

Opportunities

To develop a high degree of control over project processes To engage in contingency planning To see the project in terms of wider considerations To quantifiably model potential problems

Threats

Control of the formal may lead to lack of notice to the informal Contingency is only planned for formal and planned aspects Wider considerations may not include informal aspects Unable to model unquantifiable and intangible problems

SAQ 25 As I see it Trevor has used the approach pretty much as we asked him to. I develop his specific approach to the learning cycle in Figure 29. This is rather a wordy diagram and usually I would not want to see so many words but I have not abbreviated here so as to keep the process involved in the cycle clear.

SAQ 26 The HS-method is predisposed to be systemic in that it:

^ looks at projects as whole processes to be investigated;

^ enables analysis to be undertaken taking into consideration multiple perspectives of the problem/issue;

^ provides a boundary to the project;

^ encourages practitioners to apply systemic tools and techniques;

^ seeks to develop emergence from the analysis;

^ develops its analysis in a learning cycle.

SAQ 27 Really this question relates to the potential cynicism of the practitioner working with the approach. Four easy ways of losing the systemic virtue of HS-method would be to:

1 ask for but then ignore multiple perspectives on the project wholeness;

2 know in advance how you want the analysis to go and to lead it to this point;

3 concentrate on a quantifiable model that ignores the social aspects;

4 assume that the client is the only person or group with a stake in the situation and work to their limited brief.

162 Block 2

SAQ 28 Numerous contexts come to my mind and these are mainly in the IS domain. Two specific ones might be:

1 A university student records system. This is quite close to home for me but would seem to fit the bill. The number and registration of students, while full of potential formal problems about signing on, paying fees, making course choices are complex, they are nevertheless formal and quantifiable. To process these data elements in a computer system would seem relatively straightforward making use of a relational database to produce performance indicators relating to full time equivalent students (e.g. the full time equivalent (FTE) number of students enrolled on a specific course – where FTE = full time students + (part time students multiplied by 2)) would be relatively straightforward.

Model or experiment with the developed model

Experience actions in the world by the decision maker

Trevor receives the Taurus material and develops the basis for the approach.

‘London needs to be modernized and streamlined’.

Experience again

Here Trevor models out the three routes to objectives with the three measures. There are no black and white answers but he comes to a judgement that one specific approach has the

best chance of meeting the needs of the project and achieving the objective.

Reflection Trevor makes use of a spray diagram to capture this, then he develops the

analysis with a multiple cause of the reasons

develops a systems map to clarify his thinking.

behind the opportunity to expand. Finally he

Identify and abstract Initially, by use of an objectives hierarchy Trevor sets out what needs to be done

and settles on the most practical of these. His focus emphasizes the need to achieve

the projects objectives (probably in view of the catastrophic failure of the actual Taurus). He goes on to provide three measures of performance to analyse the practicality

of the project and three routes to objectives.

Figure 29 An activity sequence diagram of Trevor’s use of HS-method and the Taurus project

SAQ answers and comments 163

2 A supermarket check-out system. Again the data is available and the problem is formal. In this case the quantities of food and goods in the store would be known on the goods-in ledger. The process would require some form of noting and checking goods as they leave the store and cross-referencing this to the goods-in ledger. The problem is quantifiable and formal and although it is complex the check-out provides the basis for the count and check of goods leaving the store.

SAQ 29 This is not an IS problem but ...

I was recently involved in developing some training materials for a large multi- national agency. They had a very specific problem and came to me asking for a vision of the way out. I came up with a plan which I set out below in the HS- method learning cycle (Figure 30).

SAQ 30 Peter was talking about the development of the method as part of an action research programme which involved using the method in practice in order to derive the principles on which to further develop the method. Because he is using the method as a learning cycle it naturally becomes a methodology. I have taken the view that you need to learn the method itself before you can reasonably start to use it as a methodology.

SAQ 31 I outlined a series of ‘key’ ideas, acceptance of which seemed to characterize devotees of the soft approach. Crudely summarized, these are:

1 ‘Problems’ do not exist independently of observers: they are constructs of the concerned mind.

2 People have different appreciations of problem situations because they see them in genuinely different ways. It is often difficult, and sometimes impossible, to adjudicate between the merits of these different ‘ways of seeing’.

3 Just as problems are intellectual constructs, so too are ‘solutions’.

4 The concept of a ‘problem’ (a perceived mismatch between a desired and an actual state) is inadequate for describing many of the difficulties which actually arise in organizations or human systems. Better descriptions are provided by Ackoff’s concept of a ‘mess’, or by the notion of a problem situation – a setting in which problems may reside.

5 Improvements in problem situations are most likely to be brought about through the sharing of perceptions and a process of persuasion and debate.

6 The analyst cannot be detached from the problem situation or from the analysis of it.

164 Block 2

training needed. the constraints were: budgetary,

Model or experiment with the developed model

Experience actions in the world by the decision maker

Project management is not working well across a range of projects world-wide

Act again, implement the agreed changes in the new context

Three-month training package developed and presented in Rumania, Czech Republic and Cuba. Generally the short-term feedback

programme is now being planned.

was highly positive. Too early for longer term feedback. Wide scale use of the

A selection was made based upon budget constraint and known performance of the

training, developed and presented was selected for modelling. A three-month

various types of training. In the end short-term regionally,

trial was engaged in

Reflection: problem perception, system description

The client needs a project training system to develop the capability

management

of the staff within the organization.

identify objectives and constraints, consider route to objectives, measures of performance

The objective was to develop a course to provide the

international

objectives included distance,

The measures of performance related to the quality efficiencies of these various types of

Identify and abstract:

time and location; the organization is and needs to have the training delivered internationally. The routes to and short-term training delivered in the UK

three-monthly or regionally.

assessed known training to this type of context.

Figure 30 An activity sequence diagram of the HS-method learning cycle and a training project

SAQ answers and comments 165

SAQ 32 Of course you may come up with a different set of ideas but here are some which seem relevant to me when I am applying SS-method in an IS project context:

Table 22 SWOT of the SS-method

Strengths

Finding problems which are not obvious Providing a mechanism to analyse and ‘out’ tricky issues Providing legitimacy to informal analysis Accepting that not all IS problems have a technology source

Weaknesses

To lose sight of the technology To lose focus on data issues To be unable to cope with the functionality of IS To get side-tracked into non-relevant issues To lose the ability to keep up with the rate of change

Opportunities

To develop wider plans for IS development To encompass the wider organization in the analysis process To develop IS which are of relevance to the informal and the formal organization

Threats

To try to meet all needs and actually meet none To treat all problems as soft To miss the formal requirements of systems To miss the narrow needs of specific sections/sectors in the organization

SAQ 33 John Robson followed the SS-method approach set out in this block quite closely. In terms of the learning cycle his approach fits as shown in Figure 31.

SAQ 34 There are any number of good reasons for the SS-method being considered as a systems approach. These are my top five – I would guess that you would be able to think of many more:

^ SS-method deals with contexts as wholeness.

^ SS-method invites multiple perspectives on the problem context.

^ The approach seeks to clearly demarcate a boundary to the issue.

^ SS-method defines a system as a personal mental construct.

^ The methodology is fundamentally concerned with relationships within contexts.

SAQ 35 Like all systems methods, SS-method can be treated in a cynical manner which renders it non-systemic in effect. From my perspective as a practitioner making use of SS-method I would suggest the following as my top two ‘spoiling’ tendencies in any SS-method exploration:

^ Applying the approach in a linear and mechanistic fashion, expecting each element to follow from the first without the need to justify how each follows from the previous and without due levels of iteration at each a stage.

^ Using the approach as a means to justify a ‘solution’ which has been pre- arranged by the parties prior to the analysis.

166 Block 2

SAQ 36 In my experience SS-method lends itself to a vast range of problem contexts. these are two projects which I worked on:

^ In 1994 I was working on an IS project in Nigeria which involved the development of a Management Information System (MIS) for a central government training agency near Lagos. This was a very ‘soft’ context because there was little agreement on goals and perspectives, no clear guidelines on what the MIS was expected to achieve and absolutely no idea of the competencies and abilities of local staff to develop and deliver the system. SS-method proved to be a really useful front-end to an eclectic method called Multiview because it provided a basis for the establishment of the change that was sought and the outline of an activity map for the various parties and this included a detailed training schedule for local staff.

^ My second example is equally problematic. In 1996 I was working in Nepal on the development of another MIS but this time for a government ministry. In this case I had a week to ‘scope’ the project and develop awareness of what might be achievable. I applied SS-method as a quick to use approach to finding out what was going an and what was needed. The method provided me with justification for developing a map of multiple views of the potential project outputs and also the capacities of the local team to deal with the issues involved.

I ask John to take a look at Taurus. My problem is to see how SSM can be used to make sense of the mess.

Experience a problem in the world

Experience again

Model or experiment with the conceptual model

John’s conceptual model is a basis for developing a different vision of the

Taurus context

John’s rich picture provides some insights into the project and helps to draw out

some of the main themes which have arisen there. In defining a number of key problem issues he begins to develop his perception

of the context.

Reflection – problem unstructured and structured in the rich picture.

Identify and abstract – issues and tasks – the root definition

John provides a root definition which develops the need for Taurus to focus on a core business need within the context. He provides a focus for developing analysis and a potential opportunity

to improve upon the original situation

Figure 31 An activity sequence diagram of the learning cycle and John’s SS-method of Taurus

SAQ answers and comments 167

SAQ 37 Again this is not just an IS project but it is an example of where SS-method can be applied to gain advantage in understanding a complex context. In this case I was working in Pakistan on the development of a project plan for a rural development system. The purpose of the system was to develop the means whereby the productive capacity of a region was to be enhanced but the project was in an opium producing region and there were considerable local sensitivities as to how such information could be gathered. See Figure 32 (below).

SAQ 38 System is used to refer to a collection of entities in the external world. The word system is reserved for mental constructs that are created by a practitioner to gain insight into a situation. These two uses of the word reflect two different epistemological positions and are kept separate to remind you of the different positions adopted.

Experience a problem in the world The UN Drugs Control Programme

(UNDCP) is highlighting the need to reduce opium poppy production.

Experience again

It is decided to run a range of transformational sub-projects including the development of saffron farm trials and the importing of new pea seed varieties. This is

accompanied by the development of new roads and further irrigations systems

infrastructure. A detailed project action plan is developed.

Reflection The UNDCP initiates the process. I set up meetings with local people and develop rich

pictures of the present situation. This emphasizes the areas in which different stakeholders hold different views of the project process and the central issue or tasks for the project process to tackle.

The tasks and issue for the project are multitudinous at the outset. The range of issues includes fighting international crime to producing more peas and

tomatoes. Finally, following lengthy discussion it is decided that the core transformation is the economic development

of several valleys where opium is produced. This root definition also produces a range of potential transformation devices

including the development of roads, electricity and cash crops such as late peas and saffron.

Model or experiment with

Identify and abstract

Figure 32 An activity sequence diagram of SS-method and the development of a monitoring and evaluation system in Pakistan

168 Block 2

SAQ 39 Data is the name given to observations or numerical evaluations of items ‘in the world’. Information is the significance attributed to data items in a specific context. The attribution is always done by a person, so information is something that can only be generated by people, not computers, and always has a substantial subjective or personal component. Data also has a subjective component in the sense that it is impossible to make observations or evaluations of the world outside a conceptual or theoretical framework. Data that is widely regarded as ‘objective’ is based upon widely shared cultural conceptualizations.

SAQ 40

See answer to SAQ 12.

SAQ 41 The questions identified in Part 1 were ‘what learning is going on here?’ and ‘is there anything blocking the completion of learning cycles?’ In practice any questions that require you to identify the content of the learning cycles and explore whether each stage is being completed will serve.

SAQ 42 Formally the eight stages are as follows:

1 System description

2 Objectives and constraints

3 Measures of performance

4 Routes to objectives

5 Modelling

6 Evaluation

7 Choice of route

8 Implementation.

SAQ 43 The seven stages of the soft systems method are:

1 The situation unstructured (finding out)

2 Construct a rich picture

3 Develop a root definition of a relevant system

4 Construct a conceptual model

5 Compare the model with reality

6 Identify feasible and desirable changes

7 Develop actions to improve the situation.

SAQ 44 A SWOT analysis examines four aspects of a situation, namely Strengths, Weaknesses, Opportunities and Threats. Analyses are carried out by constructing a four-part table and entering items relating to the situation into the relevant section of the table. In groups this is often carried out by a brain-storming type of activity.

SAQ answers and comments 169

SAQ 45 CATWOE is a method for checking that a root definition is adequate. The checks are:

Customer Is there a clear customer for the system defined?

Actors Are the actors specified?

Transformation Is the core transformation accomplished by the system clear?

Weltanshauung What is the inherent ‘world view’ implicit in the system?

Owner By whom is the system owned?

Environment What are the environmental constraints on the system?

SAQ 46 The main criticisms of the HS-method were set out at the start of Part 2, and can be summarized as follows:

1 It is based on an engineering perspective which is not universally applicable.

2 The root of the HS-method is mathematical, or at least quantitative, and this precludes problems, or aspects of problems, that cannot be quantified.

3 The method emphasizes solving problems rather than questioning why problems arise, or avoiding them altogether.

4 The practitioner is regarded as a ‘scientific expert’ outside the situation.

5 There is a history of HS-method failing to assist policy decision making.

Personally I agree with all these criticisms, but nevertheless find the method extremely useful in certain domains. For messy problems SS-method is my preferred tool, but even within large messy situations there may be specific tasks or areas of activity that require a hard nosed examination, and the HS-method can provide this admirably.

SAQ 47 It is hard for me to provide you with a definitive answer to this question since much will depend upon your previous experience, both of the IS domain and the systems methods themselves. If you have been following the advice and instructions provided then the insights and understandings you have gained from the block should be identifiable in your Learning Album. So you should be able to check your own answer by looking there.

My guess is that if you are a technologist with little prior experience of the IS domain then you will have been most impressed by the apparent precision of the analysis carried out in the HS-method. On the other hand if you are actively involved with IS then you will know that the estimates of costs and risks used in the HS-method are subject to enormous uncertainties – as illustrated by the high incidence of outright failures. So you are more likely to have been impressed with the more pragmatic and cautious conclusions reached in the SS-method analysis. But these comments do more to display my prejudices rather than assist you in establishing your own learning outcomes!

SAQ 48 It is likely that the main benefit you will gain from attempting this SAQ is in reviewing your own appreciation of the block as a whole. As an author of the block I cannot provide you with an analysis from your own perspective. All I can do is to provide you with the results of my own analyses, which are from the perspective of one of the authors of the block, not a student. So my representations will be rather different from your own, nevertheless you may find they provide a useful alternative perspective.

170 Block 2

HS-method of Block 2

My context for Block 2 is as an author and member of the T306 course team. I am aware of the differences in opinion about the purpose of the block, the approaches taken by the different authors of the block and the needs of the authors of other blocks who will build on what is in Block 2. These concerns are as significant as those of the learning outcomes for the students of the material.

System description

Following from the context there are really two interlocking systems in which Block 2 is a key component. The first is the T306 course. The second is the student’s experience of the course and accomplishment of learning outcomes. The difference between these systems is in their avowed purpose. The first is to create an academic entity in collaboration with colleagues. The second is to provide a rich environment in which as wide a range as possible of OU students can learn directly about systems methods and their application to the IS domain. I have represented these in the systems map in Figure 33.

Other OU courses

Other Systems courses

OU Student

Other activities

Own goals and objectives

Work experience

Previous experience

Skills

Part 1 Part 2

Part 3 Part 4

TMA

Other Blocks

Editor Other authors

Designer

Exams

Tutors External

Assessors

OU administration

Student records Exams and

Assessment

Print production

T306

Time available

BLOCK 2

Figure 33 Systems map for HS-method of Block 2

SAQ answers and comments 171

Identification of objectives and constraints

Following from the two systems identified earlier, there are two sets of objectives and constraints. Actually as I write this I can appreciate that it is because all authors are operating under two separate sets of objectives that creating these teaching texts is sometimes so fraught. Personally I always favour the student objectives and will forego some of the academic issues to ensure that the material is as accessible as possible. However many of my colleagues find this irresponsible and insist on presenting material that stands up to stringent scrutiny – even if this sometimes obscures issues for some students. So for me the main objectives are

1 provide clear presentation of the selected material;

2 provide clear learning objectives and means for students to check their attainment of these objectives;

3 develop ideas and concepts in as interesting a way as possible, always from the simple to the complex;

4 make my own perspective and context clear to the student.

and the main constraints are

(a) provide material that can be read and assimilated within the allocated time;

(b) only assume concepts and skills that have been explicitly taught prior to this point in the course.

SS-method of Block 2

My rich picture of Block 2 is shown in Figure 34. This clearly shows the significance of the previous course, T301, influencing the methods used in Block 2. I was struck by how the material on learning cycles was separate from the rest of the picture, so too were the techniques in the Tool Bag.

Constructing a root definition proved to be more difficult than I expected. I started with:

A system to illustrate the use of systems methods within the IS domain.

I realized this was actually not adequate, it did not encompass the teaching about the IS domain itself and concepts such as data and information. So my next attempt was:

A system to illustrate issues in the IS domain, to explain key concepts in the domain and to introduce systems methods to explore case studies in the domain.

I played around with this for quite a while, but could not significantly improve upon its description of the primary tasks of the system until I realized that the transformation was supposed to involve you, the student! So what I used finally was:

A system, owned by the T306 course team, to illustrate issues, explain key concepts and use systems methods to explore case studies in the IS domain to enable OU students to improve their ability as systems practitioners.

I am still not fully happy with this, but it will suffice for this exercise. After three or four iterations the conceptual model I developed from this definition is shown in Figure 35. Were I to pursue this further I would actually revise the root definition to encompass more about the self-learning aspect of the block and less about the formal content – but I have gone far enough to illustrate the application of the SS-method.

172 Block 2

F ig u re

3 4

A ri ch

p ic tu re

o f B lo ck

2

SAQ answers and comments 173

SAQ 49 Table 23 shows my version of the LogFrame based on Trevor’s analysis of Taurus.

When describing the outcomes of John’s analysis I said he developed:

^ the focus on trading;

^ the simplification of the trading process to seven major activities;

^ therefore – the need for the project to develop around these seven as the core activities.

What Trevor seems to have done is progress from this point and start developing how the analysis undertaken by John might be taken forward. Without John and Trevor working together, they have come up with something where the HS- method seems to develop off the SS-method. In a sense, John has provided an analysis which confirms the problems and indicates an activity set to take the project forward. Trevor has developed a model for planning and developing this. So the main systems he develops are:

^ A system to develop an IT process for trading.

^ A system for the potential development of seven major activities within a piloted software product.

^ A system for rolling out this process with a monitored implementation plan.

In my view the logical framework comes into its own here as a means to develop a rounded project vision of the whole.

Select issues

select case studies

select systems methods

illustrate issues

describe cases

describe methods

apply each method to cases

provide self learning and self

assessment material

relate outcomes to systems practice

Explain key concepts

Figure 35 A conceptual model of the root definition derived for Block 2

174 Block 2

Table 23 Simon’s LogFrame based on Trevor’s analysis of Taurus

Goal OVI MOV Assumptions

Preserve the good name of the City of London and the London Stock Exchange

Purpose OVI MOV Assumptions

Open tender for three systems integrators to build competitive prototypes and winning tenders to build Pilot and phased implementation

The UK need for this system remains and the outcomes are generally agreed to be both beneficial and at pace with global developments in the industry

Outputs OVI MOV Assumptions

1 Approve winning tender 2 Prototype built 3 Prototype piloted 4 Pilot undergoes phased implementation

1 Winning tender is proved to have the capacity/learning ability to develop the project in all phases

2 Prototype conforms to client needs 3 Piloting procedure produces an IT product

which can be applied across a range of potential clients/users with minimal disruption to working practices

4 Implementation process develops without impairing existing processes

Activities OVI MOV Assumptions

1.1 Advertise for tender 1.2 Shortlist 1.3 Approve 2.1 Specify and agree prototype outline 2.2 Specify and agree prototype project

processes and procedures 2.3 Develop prototype 3.1 Specify and agree pilot procedures 3.2 Institute piloting 4.1 Specify adoption rates and processes

for pilot 4.2 Monitor and evaluate implementation

1.1 Appropriate candidates for tender come forward

1.2 Criteria for shortlisting are agreed 1.3 Approval is possible given adequate

quality of those tendering 2.1 Appropriate prototypes are provided 2.2 Processes and procedures are acceptable

to the client set 2.3 Approved tendering agency/company has

adequate resources to develop the approved prototype design

3.1 Procedures acceptable to the client set 3.2 Piloting confirms that client set satisfied

with product to-date 4.1 Adoption procedures can be undertaken

by main clients without severe disruption/ risk to trading

4.2 Monitoring agency has effective access to procedures and processes

SAQ answers and comments 175

Appendix A

Glossary 4GL – Fourth Generation Language. Computer program which is semi- intelligent, allowing the computer to be more interactive with the user.

Application – The main activity of a computer-based information system (e.g. an MIS is an application).

Attributes – The basic features evident in an entity, for example the first name, second name, address, telephone number, etc. in an entity called ‘address’.

Bugs – Faults in computer software. These can occur if software has not been adequately tested prior to installation.

CASE (Computer Assisted Software Engineering) tools – Software packages which assist analyst’s in the process of developing applications. They were particularly designed to work with structured analysis and design approaches (an early and widely used CASE tool was ‘Excelerator’).

Computer-based information system – A computer-based processing and storage system which provides, on demand, a number of key information products requested by an identified user community.

Data – Unstructured, unverified, unvalidated material which is the basic foundation for information products. Some form of processing must be undertaken to transform the data into information (e.g. sales data can be compiled as information on company turnover).

Data flow diagram – A linear diagram indicating flows of data (represented as arrows) through a series of processes (often represented as boxes).

Database – A store for data. A simple enough idea but made difficult by the range of numeric and written data available and the wide range of storage devices in use. The database is the store of data which is used by an IS application to generate information (e.g. a spreadsheet of numbers might be the database which produces the annual business account (information) for a small business.

Debugging – The procedure whereby a new item of software is analysed to remove faults or ‘bugs’.

Decision Support System – A computer-based system which supports decision-making. Decision support systems (DSS) often provide users with the capacity to carry out ‘what if’ analyses (e.g. ‘If I increase inflation by 4% and decrease output by 7% what does this do to my balance of trade?’). DSS are often based on spreadsheets.

Decomposition – The process of breaking down functions into sub- functions and, if necessary, sub-sub-functions. Decomposing a task down to sub-tasks.

Dialogue systems – The screen formats and protocols which a computer uses to inform users and explain procedures.

Entities – The description of anything about which we wish to store data (e.g. the addresses in an address book).

176 Block 2 Appendixes

Entity model – A model of an Information System in terms of the entities it is concerned with. Diagrams of entity models show these entities connected by lines which represent the relationships between them.

Equity – The ordinary shares in a company, which confer ownership of a fraction of a company in proportion to the number of shares held. Holders of equity receive dividends, at a rate recommended by directors and agreed by the company (all of the share holders) at its general meeting. The level of dividend varies and a major factor deciding it is the profitability of the company.

Events – These are the triggers which will spark off functions in an information model (e.g. the end of a financial year may be the event which triggers the function ‘do the annual accounts’).

Fixed account – The Stock Exchange used to have ‘Accounts’ which usually lasted 3 weeks (but could occasionally be different periods). Trades (contracts to purchase and sell shares) were accumulated within the account. Settlement followed on a fixed date around two weeks after the end of the ‘account’. Trading within an account were combined to form a ‘position’, which was to be cleared before or on the following settlement day. If within an account you bought 200 shares in company A and subsequently sold 150 of them, you would receive 50 shares on settlement day and you would have to pay the balance owing on the transactions (or receive the balance due to you – unlikely in this example but it might happen if the shares had risen sternly in price between the two trades).

Functions – In information modelling, the activities which are associated with entities and which prompt information processing to occur (e.g. the function ‘sort into alphabetic order’ may occur upon the entity store of data on library books).

Gopher – A software device which can be used to find information on the Internet.

Hacker – Any individual using a computer-based information system without authorization. In recent years this term has been most specifically related to users of the Internet breaking into supposedly secure systems such as that belonging to the North Atlantic Treaty Organization (NATO).

Hard disk – A fixed disk drive which is usually located in the computer and is not designed to be removed. Hard disks are usually large, and may provide many gigabytes of storage.

Hardware – The computer unit itself and its related components, (e.g. the visual display unit or monitor, the main processor box, a keyboard, printers, modems and optical scanners).

Human Computer Interface/Interaction – The interface between an information system and its user. The Human Computer Interface (HCI) should be designed to be as easy and intuitive as possible.

Information modelling – A hard analysis and design technique. The technique is concerned with setting out the major entities of a system, their functions and attributes and the events which will trigger the functions into activity.

Internet – A worldwide computer network connecting many different kinds of computers.

Glossary 177

Intranet – A computer network within an organization, based upon Internet technologies.

ISDN (Integrated Services Digital Network) – A fast communications link, much like a standard telephone connection, but providing users with more capacity for moving data and information.

LAN (Local Area Network) – A network of computers linked together on a particular site (such as in one organization).

Lotus Notes – In 1998 the most popular ‘groupware’ application, allowing remote groups to work on projects at the same time via computer and communications hardware.

Management Information System(s) (MIS) – Information systems designed to supply management, at set times or on demand, with key information products called ‘performance indicators’. MIS are usually based on computers but do not have to be.

Market making – Acting as a trader in a companies shares. A market maker (formerly known as a jobber) quotes buying and selling prices at which they are willing to trade. Market makers trade in their own right. Their major source of income is the difference in their buying and selling prices (the ‘turn’). A market maker carries some shares, but attempts to adjust prices to roughly balance purchases and sales. Traditionally the London Stock Exchange was based on market makers. (This is also known as a ‘quote driven’ system, as prices were established by the quotes given by the market makers).

Milestones – Significant points for the evaluation of achievement. For example, a milestone for the implementation of a new Information System might be ‘review progress on data incorporation into the computer system at the end of the financial year’.

Modem – A hardware device attached to, or incorporated in, a computer, allowing communication via the telephone network.

Multi-user system – A computer system with a network that allows a number of users to use the same software at the same time.

Network – A collection of computers and other hardware devices linked together so that they can share information. Popular networks include Ethernet-based systems linked to the Internet and running their own intranet.

Object – A component used in object-oriented modelling or programming. It represents some element of the real world as a collection of data, together with the instructions which work on this data.

Object-Oriented Development – Designing and building an Information System which is based on a set of objects. See object-oriented programming.

Object-Oriented Programming – Writing a software application which is made up of objects, each object communicating with other objects and carrying out its task in harmony with them.

Order Book – An ‘order book’ is a list of open offers to trade at given prices and volumes. The order book is created by the people who want to buy or sell. When two orders correspond (i.e. there is an offer to purchase which can be matched in price and volume to an offer to sell) a trade is

178 Block 2 Appendixes

agreed. Such a trade is also described as a ‘matched bargain’. Shares are transferred from a seller to a buyer, without being purchased by a market maker.

Performance indicator – A key factor which indicates the relative success or failure of elements of an organization or of its functioning. A Management Information System will often monitor a number of performance indicators.

Piracy – The illegal copying of software products.

Prototyping – A method for rapid development of software, in order to discover users’ requirements. This usually requires a programmer with access to sophisticated software tools who can iteratively develop the MIS application in consensus with users and user teams.

Rapid Application Development (RAD) – A form of prototyping which makes use of CASE tools to iteratively produce systems quickly.

Recipient Community – The group of stakeholders and users who will be the eventual managers, operators and clients of an information system.

Retrieval – Obtaining information from a database via an application.

Rolling Settlement – Settlement occurring a fixed time after a trade. For example T + 5 means settlement of trades five working days after the date of the trade. The London Stock Exchange now uses rolling settlement.

Router – In general, a device for routing data across a network; similar to modems but usually making use of an ISDN line.

Settlement – Delivery of shares and/or money owing. (Trading simply puts contracts in place.) Delivery of shares and cash had to take place on Settlement Day.

Social and Technical Systems Analysis – The linking together of human and technological resources to make the best combination for the specific problem context.

Software – An application (e.g. a word-processor, database, etc.) which runs on a computer.

Software–hardware mismatch – The wrong software on the wrong hardware.

Stakeholder – Any individual with an interest in the existing or proposed Information System.

Stock Exchange Calendar – List of Accounts giving Start Day, End Day and Settlement Day. This was published for each calendar year. The ‘calendar’ was only needed when the Stock Exchange had ‘Fixed Account’ trading. It is not used with ‘rolling settlement’.

Structured Analysis – A form of analysis which makes use of some of the tools set out in this text. The main concepts are data flow diagrams, data dictionary, store structuring and process logic representations.

Systems Analysis and Design – The process of discovering what an Information System (as a combination of hardware, software and human processes) should do, and setting out a plan for a feasible development. Often a technical procedure set in a sequential and systematic structure.

Technical aspects – The range of component aspects which combine to produce the total information system.

Glossary 179

UNIX – A computer operating system originally designed by Ken Thompson of AT&T Bell Laboratories, later joined by Dennis Ritchie. Development work began in 1969. Initially it was designed for a single user. The C language was subsequently developed specifically for UNIX, and the system was rewritten almost entirely in C. UNIX was improved by the addition of multiprogramming and time-sharing capabilities and enhanced portability. Long thought of as the natural system for mini computers, it is also being adopted for micro computers.

Viruses – Software, sometimes designed for ‘fun’, sometimes with malign intent, which will make a computer break down in a minor or major way. Viruses are usually brought into computers via pirated software or from the Internet. They can lead to total system collapse.

Visual Basic – A programming language used extensively for the development of databases.

WAN (Wide Area Network) – A network which links local computers with national and sometimes international computer systems and databanks.

Web – An approach in systems analysis and systems design which attempts to see all aspects of an organization (management systems, financial systems, information systems) as an integrated whole. Web is generally seen as being opposite to discrete entity analysis which sees all systems within an organization as separate.

Website – A unique address on the World Wide Web where organizations and/or individuals can present multi-media information.

WINTEL – The ‘unholy alliance’ between the two corporations INTEL and Microsoft which dominated the software and hardware markets for personal computers throughout the 1980s and 1990s.

Word-processors – Applications for editing documents. Word-processors are the most commonly used packages in modern computing. Much more than clever typewriters, they provide users with the ability to input ideas, develop themes, write, work and re-work text and usually produce high quality printed output as well as draft.

Workspace – The amount of store, memory, time, or all three, which is allotted to a user.

World Wide Web – The best-known aspect of the Internet which provides users with information in a graphical format, or as multi-media.

180 Block 2 Appendixes

References Anderton, R.H. (1991) ‘Information and Systems’, Journal of Applied Systems Analysis, vol. 18, pp. 57–60.

Avison, D. and Fitzgerald, G. (1995) Information Systems Development: Methodologies Techniques and Tools, second edition, London, McGraw- Hill.

Avison, D.E. and Wood-Harper, T. (1990) Multiview, London, McGraw- Hill.

Awad, E. (1998) Management Information Systems: Concepts, Structures and Applications, San Francisco, CA, Benjamin Cummings (Pearson Education), 616p.

Bell, S. and Wood-Harper, T. (998) Rapid Information Systems Development: Systems Analysis and Systems Design in an Imperfect World, second edition, London, McGraw-Hill.

Burgess, T. (1979) ‘New ways to learn’, J. Royal Society of Arts, pp. 117–57.

CCTA (1993) Applying Soft Systems Methodology to an SSADM Feasibility Study, London, HMSO Publications.

Checkland, P. and Holwell, S. (1998) Information, Systems and Information Systems, New York, Wiley.

Checkland, P. (1981) Systems Thinking, Systems Practice, Chichester, John Wiley & Sons.

Checkland, P. (1982) ‘An organised (?) research programme in information systems?’, Internal Discussion Paper 1/82, Department of Systems, Lancaster University.

Checkland, P.B. and Scholes, J. (1990) Soft Systems Methodology in Action, New York, Wiley.

Collins, T. and Bicknell, D. (1997) Crash: Ten Easy Ways To Avoid A Computer Disaster, Simon and Schuster.

Daniels, A. and Yeate, D. (1971) Systems Analysis, Science Research Associates, Palo Alto, CA.

de Mello, A (1989) The Heart of the Enlightened, London, Harper Collins.

Drummond, H. (1998) Escalation in Decision Making, Oxford, Oxford University Press.

Flood, R.L. and Jackson, M.C. (1991) Creative Problem Solving: Total Systems Intervention, New York, Wiley.

Galliers, R. (1992) Information Systems Research, London, Blackwell Scientific.

Holwell, S. (1989) Planning in Shell: joint learning through action research, MSc dissertation, Lancaster University.

Hoos, I.R. (1976) ‘Engineers as analysts of social systems – a critical enquiry’, Journal of Systems Engineering, 4 (2), (reprinted in ‘Systems Behaviour’, third edition, ed. Open Systems Group, London; Harper and Row, 1981).

References 181

Lee, B. (1979) Introducing systems analysis and design. Volume 2, Manchester, NCC Publications.

Liebenau, J. (1990) Understanding Information: An Introduction, London, Macmillan, 125p.

Lilienfeld, R. (1978) The Rise of Systems Theory, An Ideological Analysis, John Wiley & Sons, New York.

Morris, D. and Tamm, B. (eds.) (1993) Concise Encyclopaedia of Software Engineering, Oxford, Pergamon Press.

Popper, K.R. (1972) Objective Knowledge: an evolutionary approach, London, Oxford University Press.

Ward, J. et al. (1990) Strategic Planning of Information Systems, Chichester, John Wiley and Sons.

Winograd, T. and Flores, F. (1986) Understanding Computers and Cognition, Reading, MA, Addison-Wesley.

182 Block 2 Appendixes

Acknowledgements Grateful acknowledgement is made to the following sources for permission to reproduce material in this block:

Text

Box 1 ‘British Gas consumers turn heat up over bills’, Computer Weekly, 17 October 1996, # Reed Business Information Ltd; Box 2 Collins, A. (1996) ‘£2.6bn DSS system fails to hit targets’, Computer Weekly, 28 March 1996, # Reed Business Information Ltd; Box 4 ‘Scottish Power bags the wrong customers’, Computer Weekly, 3 April 1997, # Reed Business Information Ltd; Box 7 Checkland, P. and Holwell, S. (1998) Information, Systems and Information Systems – Making Sense of the Field, # John Wiley and Sons Ltd. Reproduced by permission of John Wiley and Sons Ltd; Box 9 Collins, A. (1997) ‘How British Gas took the blame and still managed to survive’, Computer Weekly, 20 March 1997, # Reed Business Information Ltd; pp.91–92 Edited version of a talk given by Peter Checkland to the OUSys Annual Conference 1996, reproduced by permission of Peter Checkland.

Figures

Figure 2 Ward, J., Griffiths, P. and Whitemore, P. (1990) Strategic Planning for Information Systems. Copyright # 1990 by John Wiley and Sons Ltd. Reproduced by permission of John Wiley and Sons Ltd; Figure 6 Bell, S. G. and Wood-Harper, T. (1998) Rapid Information Systems Development, McGraw-Hill. Reprinted with the kind permission of McGraw-Hill Publishing Company; Figure 26 Adapted from Kolb, D. A., Rubin, I. M. and Osland, J. (1984) Organizational Behaviour: An Experiential Approach, 4

th ed, Prentice-Hall, Inc.

References 183

Course team Simon Bell, author

Jake Chapman, author

Martin Reynolds, course chair

Laurence Newman, course manager

Mike Aiken, critical reader

Mandy Anton, graphic designer

Rosalind Armson, critical reader

Ian Beeson, critical reader

Victor Bignell, critical reader

Chris Blackmore, critical reader

Peter Day, script author

Helga Drummond, critical reader

Tony Duggan, project control (Technology)

Lisa Taylor, compositor

Mike Haynes, critical reader

Sue Holwell, critical reader

Caryl Hunter-Brown, subject information specialist

Ray Ison, critical reader

Andy Lane, critical reader

Gilbert Mansell, critical reader

Jane Moore, editor

Graham Paton, critical reader

Peter Roberts, critical reader

Pat Shah, course secretary

John Taylor, graphic artist

Robert Wood, editor

Bob Zimmer, critical reader

External assessor

Olov Forsgren, associate professor, Department of Informatics, Umeå University, Sweden

184 Block 2 Acknowledgements