11

CMSCB3004

Systems, Cybernetics and Management

FAILUREThe Systems Failures Method

22

Systems & Failure• Last session we considered soft systems approaches• This time we consider the area of FAILURE• Particularly using a systemic means of analyzing failure• Why the study of failure is appropriate - Learning from failure is a

crucial element of development • As Jung said

The psychotherapist learns little or nothing from his successes. They mainly confirm him in his mistakes, while his failures on the other hand, are priceless experiences in that they not only open up the way to a deeper truth, but force him to change his views and methods".

• More recently Ackoff made a similar point When one does something right, one only confirms what is already known: how

to do it. A mistake is an indicator of a gap in one's knowledge. Learning takes place when a mistake is identified, its producers are identified and it is corrected

• These refer to individual learning - but this can be extended to learning from the experience of others and to organizational learning

33

Learning Organisations• The notion of the Learning Organization has become

increasingly popular in recent years in the US and UK• Based on the view that successful organizations must ‘learn’

in a similar way to humans and animals when presented with a challenging situation

• Learning should be devolved through the organization the organizations that will truly excel in the future will be the

organizations that discover how to tap people's commitment and capacity to learn at all levels in an organization

• How organizations can be seen to be ‘learning’ is debatable • Monitoring progress across a broad range of measures and

performance indicators seems appropriate - then failure can be recognized and addressed - relies on establishing a blame free environment

As a decision support system, BASIS (a BA Safety Information System, developed in 1990) has been developed to facilitate and encourage an open reporting-system supported by a company commitment to Penalty Free Reporting. This was deemed necessary because it was recognized that it was important to encourage crews to report all incidents as fully as possible without fear of recrimination. The success of this has been seen in the improvement (40 per cent) in reports since the beginning of 1991

44

Learning from other Organisations

• Organizations also learn from other organisations

• e.g. in Air Transport, a problem in one area can result in aircraft being grounded in other areas e.g. the recent French Concorde crash

• Organisations from different economic sector can also learn from each other

• Similar to ‘benchmarking’ where the performance of organizational processes are compared with other organisations

• This process isn’t limited to the same type of company, may include organisation from apparently unlikely sources

55

Uncovering the Lessons

• Usually learning from failure has been limited to two sources Formal investigations - usually convened to apportion

blame Typified by the Official Enquiry thorough/slow looks for

a single cause Ad hoc recollections of what went wrong

relies on impressions and memories - haphazard/subjective

• We consider a third way - The Systems Failures Method Employs systemic modeling techniques Can be used to look back at past failures However, can also be employed to look forward to

attempt to avoid potential failure

66

Reluctance to consider failure

• Although emergency planning is common in high risk industries, other industries are generally somewhat reluctant to consider that something may go wrong

• The widespread reliance on computer systems means that organizational well-being is more and more dependant on computer systems running well

• Increasing numbers of business disruptions caused by computer failure, 70% of incidents in last decade in last three years

• Survey found that out of 300,000 large/mid sized installations, less than 35% had any kind of disaster plan

• Planning for failure considered essential in good IT project management - yet it does not appear to be performed

Curiously, despite the enormous attention project management and analysis have received over the years, the track record of projects is fundamentally poor, particularly for the larger and more difficult ones. Overruns are common. Many projects appear as failures, particularly in the public view. Projects are often completed late or over budget, do not perform in the way expected, involve severe strain on participating institutions or are canceled prior to their completion after the expenditure of considerable sums of money

77

The Systems Failures Method

• As with other systems methods, this approach takes the analyst from the real world - the failure situation to the conceptual world of systems thinking

• Modeling and comparison with standard models used to increase understanding which is taken back to the real world

Situa tion

V iew p oin ts /p e rsp ectives

P u rp ose fors tu d y

D ecision abou tw h at con stitu tes

fa ilu re

U n derstan d in g

Lesson s

N eed for fu r th e rin ves tiga tion

A ction

Systemrepresen ta tion

C om par ison

S ys tem stech n iq u es

S ys tem scon cep ts

S ys tem s m od e lsan d p a rad igm s

R e a l W o rld

S y ste m s T h in k in g

88

Failure Categories• Simple definition - Something has gone wrong• Slightly better categorization

Type 1 failure - Objectives of designers not met - toll bridge not used - invention never properly works

Type 2 failure - Objectives met but serious side-effects result e.g. Thalidomide = birth defects - mining in Aberfan = unsafe spoil heaps

Types 1 & 2 may not be mutually exclusive - Concorde over cost/noisy

Type 3 - Designed failure - fuse in a plug, fuse failure on high current protects rest of device

Type 4 - Inappropriate objectives - objectives met/ no undesirable consequences - requirement no longer exists - railway bridge completed but no line left.

• Straight forward categorization complex - depends on standpoint

99

System Failure• Previous examples concern designed objects• However, anything can be considered in this way and

regarded as an outcome of a set of activities• For the purpose of the approach used here those

activities are considered as taking place within an organized whole -

‘a system’• Failures here have been referred to as Systems Failures

and characterized as: human perception and identification as a failure, thereby acknowledging that

one person's failure may be another person's success;

failure to meet system objectives attributed by those involved, such as designers and users;

OR

the production of outputs that are considered to be undesirable by those involved

1010

IT Project Failures

• Design & development failures Construction/Civil Engineering e.g. Channel Tunnel

High visibility/high cost/high risk - failure is conspicuous

IT projects are similar - frequently expensive/increasingly high risk

• Computer press littered with significant failure - London Ambulance fiasco Some systems never work. The full suite of programs and files are

never made operational because they will be unacceptable to the user. Some work, but come in either cripplingly over budget, very late or both. Others are pared down in terms of facilities, while others still are literally forced into place in their host organization, despite their being either inappropriate or unacceptable. Some perform to specification but turn out to be so inflexible that maintenance and enhancement assume nightmarish proportions. Others are thought to work, but turn out not to

1111

IT Project Failure Types• Aims• Goal failures: inadequate specification of what it is the system has to achieve.• Requirement failures: deficiency in the more detailed specification of the project.• Organization• Resources failure: insufficient people, time or money to achieve the objectives.• Size failure: mismatch between the management of the project and the resources available on the

one hand and the scope of the activity on the other hand.• Organizational failures: both internal management of the project team and support from the

organization.• Methodology failures: overall synthesis of software projects involves an explicit method to which the

project needs to adhere.• Planning and control failures: inadequacy in monitoring and control which ideally needs to be coupled

to realistic, achievable plans.• Methods• Techniques failures: misapplication of particular tools or misjudgment about their appropriateness.• Technology failures: reliance on technologies such as hardware and software that do not perform as

expected.• People• People management failures: failures in motivation and team building that jeopardize success.• Personality failures: conflicts between individuals and mismatches between personal attributes and

task requirements.• User contact failures: insufficient checking by designers and builders with those who will use the

system.

1212

IT Project Hints & Tips from the Master• In information systems projects, the avoidance of failure has

become an important part of project planning. Ackoff offered five rules for practitioners:

• Never sign a contract you cannot break.

• Never report to anyone lower than the authority capable of controlling all the functions involved in the study.

• Never report to the responsible authorities through intermediaries.

• Never fail to complain forcibly to management about undesirable research conditions.

• Never perform research for anyone at no cost to him or her.

1313

IT Project Critical Success Factors• Aims

Project goals are clearly stated.• Organization

Resources are sufficient. Control mechanisms are in place and are used. Project has support of top management. Communication channels are adequate. There is capability of feedback. Contractors are responsive to clients.

• People Project manager is competent. Project team is competent.

1414

Systems Failures Method

Pre-an a lysis

Iden tifica tionof sign ifican t

fa ilu res

Systemselection

SystemM odelin g

C om par ison

Fur th eran a lysis

Syn th esis

In form ation abou tsitua tion s

V iew poin ts/perspectives

Purpose

System s tech n iques

Parad igm s

Purpose

Lesson s

A gen da forch an ge

D esign /redesign

R em edy

Form alsystem m odel

Systemtech n iques