OP3 Control over implementation quality at the boundary between the

The two theoretical categories of organisational precursors previously identified, OP1 and OP2, point, essentially, at organisational dynamics that are internal to the organisation. The third category presented here, instead, points at the unfolding relationship between the software manufacturer and the organisation at the time the system is purchased and implemented. From the collected evidence, it emerged that neither Alphasky nor Deltasky developed the system in-house, but contracted out its implementation. They appeared to differ, however, in the way they managed the quality of the automated alarm implementation at the boundary between the service provider and the software manufacturer. By control over the implementation quality it is meant the type of mechanisms that the service provider adopts to ensure that the quality of the supplied system, as provided by the software manufacturer, is fit for its own, specific operational environment (Kern & Willcocks, 2001). As suggested by research on information system outsourcing, such controls may come in a variety of forms—e.g., project plans, contract forms, peer pressure, etc. (Kirsch, Sambamurthy, Ko, & Purvis, 2002)—and establishing appropriate controls is one of the main challenge for the purchasing organisations. In the present case two basic types of controls have emerged, which seems to influence the quality of the alarm implementation.

 Requirement based. On the one hand a service provider can recur to the formal specification of the outcome, i.e., system requirements. The analysis of the Alphasky case, the best in class implementer, indicated that this service provider has an internal team responsible for the collection, the specification, and the transmission of the requirements to the software manufacturer (see A7.

Chapter 6. Study 2 results

119

Specifying system requirements to the manufacturer). By means of the specified requirements, the organisation is able to effectively being provided with the system they specify for their operational system;

 Trust based. On the other hand, failing to see the complexity of system implementation while trusting the software manufacturer may result in leaving the quality of implementation to the latter. After deciding to implement the MSAW after this was proposed by the manufacturer, Deltasky did not specify the requirements of the alarm to the manufacturer in the initial contract, as the manufacturer was trusted because of its reputation (see D3. Purchasing the system in absence of specified MSAW requirements). However, it is generally acknowledged that in the absence of adequate outcome controls such as system requirements, other means need to be in place to ensure that the manufacturer, the controlee, will act in the best interest of the controller, the service provider. Failing to do so risks leaving the organisation purchasing the system with an implementation reflecting more the manufacturer view of implementation than the client side. The case of Deltasky seems to confirm this general pattern: the absence of formal controls over the alarm implementation at the service provider-software manufacture boundary resulted, in fact, on the provision of a suboptimal system—in that specific case a system with a terrain grid specified for another function (see case category D4. Manufacturer providing a sub-optimal alarm).

Overall, the difference observed between Alphasky and Deltasky regarding their interaction with their respective manufacturers, and, in particular, the problematic outcome of the trust based approach observed in the Deltasky case suggest that the control over implementation quality at the service provider-software manufacturer boundary is an organisational dynamic that one has to consider to understand the quality of human automation interaction of an operational system. The broader implication is not that all trust based form of control necessarily result in the poor implementation of a supplied safety-critical alarm system. But, indeed, the collected evidence points at the potential risk associated with this approach—this approach may inadvertently result in a suboptimal implementation quality, something that is not realised by the purchasing company until the operational system is implemented and when the manufacturer has completed its contractual duties.

120

CHAPTER CONCLUSIONS

This chapter has presented the second empirical study of this thesis. The study examined the organisational experiences of (mis) managing the issue of the MSAW-related nuisance alerts during the implementation and operation of the MSAW within two European ANSPs. In particular the chapter has looked at how these two organisations have handled the problem of the MSAW-related nuisance alerts. The chapter has contributed to OPHAII development by:

 Further supporting the importance of OP1: Organisational assumptions driving automation implementation and improvement as a precursor to the management of HAI issues. This theoretical category was already identified at the end of Study 1 (chapter 5), and it has received further support by the evidence collected in this study;

 Identifying two additional relevant theoretical categories of organisational precursors, namely: OP2: Organisational capability for handling HAI issues, and OP3: Control over implementation quality at the boundary between the service provider and the software manufacturer.

The updated version of the OPHAII framework resulting from this study is presented in Table 19. What remains to be done is to assess the validity and generalisability of the framework. This is undertaken in the following chapter.

Table 19. The updated version of OPHAII based on the findings of Study 2. While OP1 has remained unchanged, two more categories of precursors (OP2 and OP3) have been identified.

OP1: ORGANISATIONAL ASSUMPTIONS DRIVING AUTOMATION

IMPLEMENTATION AND IMPROVEMENT - View of the alarm’s role

- View of the HAI issue

OP2: ORGANISATIONAL CAPABILITY FOR HANDLING HAI ISSUES - Parameterisation process

- Positive attitude towards air traffic controllers’ involvement - Supporting software tools and organisational roles

OP3: CONTROL OF IMPLEMENTATION QUALITY AT THE BOUNDARY BETWEEN THE SERVICE PROVIDER AND THE SOFTWARE MANUFACTURER