10-12 March 2005Glasgow Complexity in Design Workshop 1 Complexities of Multi-Organisational Error...

10-12 March 2005 Glasgow Complexity in Design Workshop 1

Complexities of Multi-Organisational Error Management

John Dobson, Simon Lock, Dave Martin, Ian Sommerville

University of Lancaster


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


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)


Causal responsibility

• Two types of causal responsibility– Responsibility to enact the process in ‘normal’ situations– Responsibility to deal with exceptions


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


Causal responsibility failures

• Responsibility misunderstanding• Lack of competence• Lack of time• Lack of resources• Unassigned responsibility• Conflicts of interest


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


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


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


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


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


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.


Organisational Boundaries (1)

If maintenance responsibilities are in a different enterprise from the operation responsibilities,

where exactly does the boundary lie?



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



in practice, maintenance will include at least some monitoring



shared responsibilities require good communications channels and some way of resolving conflicts in priorities, because this model is equivalent to the following:


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?


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?


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."


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


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


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 2005Glasgow Complexity in Design Workshop 1 Complexities of Multi-Organisational Error...

Documents

Transcript of 10-12 March 2005Glasgow Complexity in Design Workshop 1 Complexities of Multi-Organisational Error...