The Systems Failures Method

1

1

CMSCB3004


Systems, Cybernetics and Management


FAILURE

The Systems Failures Method

2

2

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

3

3

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

4

4

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

5

5

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

6

6

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

7

7

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

Situation
Viewpoints/
perspectives
Purpose for
study
Decision about
what constitutes
failure
Understanding
Lessons
Need for further
investigation
Action
System
representation
Comparison
Systems
techniques
Systems
concepts
Systems models
and paradigms
Real World
Systems Thinking
8

8

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

9

9

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

10

10

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

11

11

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.

12

12

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
.

13

13

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.


14

14

Systems Failures Method

Pre-analysis
Identification
of significant
failures
System
selection
System
Modeling
Comparison
Further
analysis
Synthesis
Information about
situations
Viewpoints/
perspectives
Purpose
Systems techniques
Paradigms
Purpose
Lessons
Agenda for
change
Design/
redesign
Remedy
Formal
system model
System
techniques