Complexities of Multi-Organisational Error Management

1. Complexities of Multi-Organisational Error Management John Dobson, Simon Lock, Dave Martin, Ian Sommerville University of Lancaster Glasgow Complexity in Design Workshop

2. 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 Glasgow Complexity in Design Workshop

3. 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) Glasgow Complexity in Design Workshop

4. Causal responsibility • Two types of causal responsibility • Responsibility to enact the process in ‘normal’ situations • Responsibility to deal with exceptions Glasgow Complexity in Design Workshop

5. 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 Glasgow Complexity in Design Workshop

6. Causal responsibility failures • Responsibility misunderstanding • Lack of competence • Lack of time • Lack of resources • Unassigned responsibility • Conflicts of interest Glasgow Complexity in Design Workshop

7. 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 Glasgow Complexity in Design Workshop

8. 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 Glasgow Complexity in Design Workshop

9. 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 Glasgow Complexity in Design Workshop

10. 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 Glasgow Complexity in Design Workshop

11. 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 Glasgow Complexity in Design Workshop

12. 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. Glasgow Complexity in Design Workshop

13. Organisational Boundaries (1) If maintenance responsibilities are in a different enterprise from the operation responsibilities, where exactly does the boundary lie? Glasgow Complexity in Design Workshop

14. 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 Glasgow Complexity in Design Workshop

15. Organisational Boundaries (3) in practice, maintenance will include at least some monitoring Glasgow Complexity in Design Workshop

16. 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: Glasgow Complexity in Design Workshop

17. Organisational Boundaries (5) Glasgow Complexity in Design Workshop

18. 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? Glasgow Complexity in Design Workshop

19. 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? Glasgow Complexity in Design Workshop

20. 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." Glasgow Complexity in Design Workshop

21. 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 Glasgow Complexity in Design Workshop

22. 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 Glasgow Complexity in Design Workshop

23. What next? • Modelling the responsibility (rather than the allocation of responsibilities) • Description, Competences, Resources required, Constraints, Etc. • Modelling responsibility sharing (transfer, delegation, inter-organisational) Glasgow Complexity in Design Workshop