Complexities of Multi-Organisational Error Management
John Dobson, Simon Lock, Dave Martin, Ian Sommerville
University of Lancaster
10-12 March 2005
Glasgow Complexity in Design Workshop
1
Consequential responsibility
• In general, responsibilities can be recast as
responsibilities for some goal
•
Who gets the blame if a goal is not reached
• Always associated with an organisation/role/person
not an automated system
10-12 March 2005
Glasgow Complexity in Design Workshop
2
Causal responsibility
• Causal responsibility can be considered as the
responsibility for doing something
• This can generally be recast as the responsibility for
enacting some process (possibly not explicitly
defined)
• Consequential responsibilities always have
associated causal responsibilities (although the
responsibles may be different)
10-12 March 2005
Glasgow Complexity in Design Workshop
3
Causal responsibility
• Two types of causal responsibility
– Responsibility to enact the process in ‘normal’ situations
– Responsibility to deal with exceptions
10-12 March 2005
Glasgow Complexity in Design Workshop
4
Consequential responsibility failures
• Failure to assign consequential responsibility (to a
role)
• Failure to identify (adequate) evidence of discharge
of responsibility
• Misunderstanding of consequential responsibility
• Failure to translate consequential to causal
responsibility
• Conflicts of interest
10-12 March 2005
Glasgow Complexity in Design Workshop
5
Causal responsibility failures
•
•
•
•
•
•
Responsibility misunderstanding
Lack of competence
Lack of time
Lack of resources
Unassigned responsibility
Conflicts of interest
10-12 March 2005
Glasgow Complexity in Design Workshop
6
Summary: Responsibility models
• Consequential responsibility is a relation between a role/agent
and a goal
• Causal responsibility is a relation between a role/agent and a
process
• There are processes of creation associated with evidence. Each
process has an implicit goal (Successfully Do It) hence a
responsible
• Processes also have causal responsibles who are responsible
for enacting the process
• One or more responsibles may be assigned a responsibility
10-12 March 2005
Glasgow Complexity in Design Workshop
7
Shared responsibility
• Shared consequential responsibility for some goal is
common in multi-organisational systems
• A possible source of error is when this responsibility
crosses organisational boundaries
• This is particularly true when the responsibility
involves the prevention of failure
10-12 March 2005
Glasgow Complexity in Design Workshop
8
Life cycle and Responsibilities
In preparation for mapping out the responsibilities
implicated in a failure, it is useful to start by looking at
the major life-cycle phases of an operational system
as a way of distinguishing different responsibilities
10-12 March 2005
Glasgow Complexity in Design Workshop
9
Operational System Life-cycle Phases
There are four major phases (defined by processes) in
the life cycle of an operational system:
–
–
–
–
procurement
operation
maintenance
decommissioning
It is easier to deal with particular faults in particular
ways at particular points in the life-cycle
10-12 March 2005
Glasgow Complexity in Design Workshop
10
Procurement includes making assessments of the risks and
consequences of operational failures
Operation includes monitoring errors and following plans for
recovering from the errors so as to prevent them from giving rise
to failures
Maintenance includes taking retrospective action to prevent
subsequent occurrences of fault-error-failure chains
Decommissioning includes ensuring that documentation
concerning the (in)accuracy of the failure mode assumptions
and (un)successful ways discovered of managing failures is
preserved for posterity
10-12 March 2005
Glasgow Complexity in Design Workshop
11
Dependability Responsibilities
The previous analysis leads to the following articulation of overall
responsibilities:
The positioning in this model of (intra- and inter-) organisational boundaries is key
to effective error recovery.
10-12 March 2005
Glasgow Complexity in Design Workshop
12
Organisational Boundaries (1)
If maintenance responsibilities are in a different enterprise from the operation
responsibilities,
where exactly does the boundary lie?
10-12 March 2005
Glasgow Complexity in Design Workshop
13
Organisational Boundaries (2)
all the monitoring can be contracted out, but the operator is then dependent on
another organisation for critical management information; there are a number of
possible organisational failure associated with such a critical dependence
10-12 March 2005
Glasgow Complexity in Design Workshop
14
Organisational Boundaries (3)
in practice, maintenance will include at least some monitoring
10-12 March 2005
Glasgow Complexity in Design Workshop
15
Organisational Boundaries (4)
shared responsibilities require good communications channels and some way of
resolving conflicts in priorities, because this model is equivalent to the following:
10-12 March 2005
Glasgow Complexity in Design Workshop
16
Organisational Boundaries (5)
10-12 March 2005
Glasgow Complexity in Design Workshop
17
Example of
cross-organisational responsibilities
For example, recovery planning in the infrastructural
enterprise might assume the existence of certain
recovery mechanisms and procedures in the
operational enterprise. But whose responsibility is it to
determine whether these exist and if necessary ensure
that they do and are appropriate? Whose policy it it?
10-12 March 2005
Glasgow Complexity in Design Workshop
18
Working Across Organisational Boundaries In The UK Railways
•
When safety relies on inter-organisational coordination of work we need to consider the
nature of the relationship between the organisations
–
–
Structure (trains and rolling stock operated and managed by the train companies) and
infrastructure (rail network and signalling operated and managed by Railtrack)
Relationship: provider – consumer/customer?
• For operation Railtrack provided and managed a working infrastructure on
which train journeys are scheduled and re-scheduled dynamically
–
But what of the relationship for safety
• Nature of delegation, monitoring, enforcement or ideal of simple cooperation?
–
How well are safety procedures specified across boundaries?
• Control for safety strategy distributed across organisations
• No systematic coordination of safety work, reliance on some document flows
(e.g. SPAD reports) and other ad hoc interventions (e.g. letters and phones
calls by management)
• Creates problems in sticking to a schedule or achieving agreed upon analyses
and solutions to safety problems
• Open-ness and concealment: lack of transparency of organisational workings
creates the problem of working out how safety procedures inter-link/achieving
a coherent strategy
• Who has responsibility for managing the interactions between the
organisations?
10-12 March 2005
Glasgow Complexity in Design Workshop
19
Interactions between Organisations
The split between operation (trains) and infrastructure (signals) means that
some errors arise from inadequate co-ordination between the two enterprises,
particularly if there are faults in each enterprise which interact, or if the major
phases in the two organisations are poorly synchronised.
"(Railtrack) did not inherit, and does not have, the overarching role of BR. Its
undertaking was and remains markedly narrower. Nonetheless there is a
widespread perception of Railtrack as the successor to BR, particularly as
respects driving of trains, responsibility for drivers and responsibility for the
design of trains. Railtrack is not an inheritor of those and other functions and
they fall outwith Railtrack's proper province today. Professor Uff QC recognised
this on his report on the Southall accident when he made several
recommendations for standards to be developed by ATOC. Furthermore,
Railtrack does not presently have full power to set standards which it considers
to be desirable or appropriate, for example, where the costs of implementation
would exceed the achievable safety benefit. Despite these matters, Railtrack is
widely but erroneously seen to be responsible for ensuring safety on the whole
railway network and to have the power to do so."
10-12 March 2005
Glasgow Complexity in Design Workshop
20
Dependability cases
• Dependability cases are justifications for a belief that
a certain level of dependability has been achieved
• They include
– Claims - a statement of some thing. It might be thought of as
the achievement of a goal
– Evidence - information to back up that statement
– Arguments - arguments why the evidence backs up the
statement
10-12 March 2005
Glasgow Complexity in Design Workshop
21
Proposal
• Associate consequential and causal responsibility
information with dependability cases
–
–
–
–
Documents and makes explicit who is responsible for what
Reveals unassigned responsibilities
Provides a basis for responsibility discussions
Clearly relates responsibility to dependability
10-12 March 2005
Glasgow Complexity in Design Workshop
22
What next?
• Modelling the responsibility (rather than the allocation
of responsibilities)
– Description, Competences, Resources required, Constraints,
Etc.
• Modelling responsibility sharing (transfer, delegation,
inter-organisational)
10-12 March 2005
Glasgow Complexity in Design Workshop
23