The Impact of Technology Insertion on Organisations

More documents

Recommendations

Info

HFIDTC/2/12.2.1/1 Version 3 / 21 November 2007 Langley lists other key considerations for COTS products, including the need to get hands on experience <strong>of</strong> product functionality, ‘while vendor literature and demonstrations contribute to an understanding <strong>of</strong> product functionality, there is no substitute for extensive hands on experience.’ Langley argues that this is the only way to determine whether generalised capabilities provided by a COTS product meet the specific customer requirements. This consideration is perhaps given extra credence by the problems that the National Programme for IT (NPfIT) encountered when trying to procure and insert COTS technology throughout the NHS [60]. In an effort to digitise patient records in the NHS, a COTS s<strong>of</strong>tware product, developed for use in the US healthcare system was procured. <strong>The</strong> project is a public private partnership (PPP) between the Trust and a US based s<strong>of</strong>tware house (USCo) contracted to supply, configure and support their customisable<strong>of</strong>f-the-shelf healthcare information system in cooperation with an in-hospital project team. Although there were many other issues in the NPfIT, one <strong>of</strong> the major stumbling blocks was the fact that the COTS product had been designed around the US model <strong>of</strong> health care. Key differences in healthcare provision between the two countries caused significant challenges to implementing the new s<strong>of</strong>tware. One <strong>of</strong> the major differences between the NHS and US healthcare is that US healthcare services are not ‘free at the point <strong>of</strong> use’, so the COTS user interface had sections dedicated to payment and insurance details, which were not relevant in the UK. Trying to fit a US (insurance and payment) oriented system to the UK is– ‘like fitting a square peg in a round hole.’ [60]. Some authors feel that the use <strong>of</strong> COTS can be considered a security risk. Richardson [59] quotes Dr Stephen D Bryan, former Director <strong>of</strong> the DoD’s Defense <strong>Technology</strong> Security Administration, who warned that ‘if we are selling COTS on an unrestrained basis globally, then any strategic advantage we gain… will be immediately <strong>of</strong>fset. COTS will become a security risk instead <strong>of</strong> a security benefit’. 5.3 Organisational Risks <strong>The</strong>re is now an increasing body <strong>of</strong> evidence to suggest that organisational issues play a significant role in system failures. Jeffcot and Johnson [61] found that a lack <strong>of</strong> consideration <strong>of</strong> organisational issues in systems development can cause project failure. Organisational risks can be defined as the ‘non-technical aspects <strong>of</strong> systems development, which might have an impact on the ultimate success or failure <strong>of</strong> a project’ [62], [13]. Considering these aspects as risks seems sensible, given the evidence, Ewusi-Mensah and Przasnyski [19], for example, found that organisational factors such as ‘senior management involvement’ and the ‘degree <strong>of</strong> end-user participation in the project development’ were the ‘most widespread and dominant factors contributing to project failure’. Although the importance <strong>of</strong> organisational issues is well understood, especially in disciplines such as socio-technical systems, research shows that systems development is more <strong>of</strong>ten than not, technology led. Consequently organisational issues are not properly addressed [6], [13], and too much responsibility rests with IT pr<strong>of</strong>essionals. <strong>The</strong> implications <strong>of</strong> this are illustrated by Hornby [63] who argues that ‘Systems analysts do not claim to have knowledge <strong>of</strong> organisational issues in IT systems, and there is no evidence that they are encouraged or rewarded for considering such issues’. <strong>The</strong> literature backs up the view <strong>of</strong> these authors that systems development methodologies typically encourage the implementing <strong>of</strong> a system, and then simply hope that they will be able to cope with the organisational implications later. 19
HFIDTC/2/12.2.1/1 Version 3 / 21 November 2007 Mackenzie’s [64] belief that in order ‘To make computer systems safer, we need to address not merely their technical aspects, but also the cognitive and organisational aspects <strong>of</strong> their real-world application’ seems entirely appropriate. 5.3.1 Organisational Barriers to <strong>Technology</strong> Changes <strong>Technology</strong> research suggests that there are organisational and technological factors that limit the adoption and use <strong>of</strong> technologies. Indeed there is evidence that numerous aspects, such as organisational size, resources, management support, and innovation history influence the extent <strong>of</strong> technology adoption. Researchers have also been aware for a long time that the introduction <strong>of</strong> new technology can <strong>of</strong>ten result in changes to people’s roles within the organisation. Several authors have identified what they refer to as ‘barriers’ to organisational change and hence technology adoption. <strong>The</strong> following section will discuss what barriers may be encountered, where these ‘barriers’ appear and what their consequences can be in terms <strong>of</strong> technology project success. 5.3.1.1 Acquisition Processes Surprisingly perhaps, an organisation’s own acquisition processes can lead to risks to the success <strong>of</strong> technology programmes. Military acquisition processes have been particularly problematic when it comes to technology insertion projects. For example Marshall and Underhill [55], whilst discussing the Tornado platform, state that ‘Many capability requirements cannot be met . . . because the current processes for both sustainment modifications and capability upgrades take too long and . . . cost too much’. <strong>The</strong>y argue that the defence procurement system is ‘perceived as overly bureaucratic, inefficient and lacking in pragmatism and flexibility’. Similarly, Skorczewski [65], chairman <strong>of</strong> the Industrial Avionics Working Group, argues that established arrangements for providing the Armed Services with weapons and equipment are not designed to stimulate technology insertion. He goes on to state that ‘purchasing rules, procedures and culture are all actively discouraging. <strong>The</strong> defence industry is particularly affected yet is expected to respond when required with the skills, resources and innovation to match MoD’s needs’. It would appear that the UK is not alone in this respect, with Gentry [57] suggesting that the lack <strong>of</strong> centralised accounting <strong>of</strong> DoD equipment means that there is not sufficient management <strong>of</strong> the DoD’s IT infrastructure. 5.3.1.2 <strong>Technology</strong> Adoption; Demographics, Politics and Fear <strong>of</strong> Change <strong>Technology</strong> adoption, technology acceptance and the diffusion <strong>of</strong> innovations are domains <strong>of</strong> study in their own rights. Work in these areas has revealed that organisational politics can play a role in technology adoption. A number <strong>of</strong> authors have found that managers and personnel will actively resist technology changes if they feel they would lose power and decision making authority. <strong>The</strong>re are a number <strong>of</strong> ways that this resistance might occur, for example Edmondson et al [66] found that those with power would influence others’ views by conveying their thoughts about the implications <strong>of</strong> a new technology. Other researchers have similarly found that one <strong>of</strong> the key ways in which organisational politics may affect the ‘post-implementation success <strong>of</strong> a technology’ is through user 20
Page 1 and 2: The Impact
Page 3 and 4: HFIDTC/2/12.2.1/1 Version 3 / 21 No
Page 23: HFIDTC/2/12.2.1/1 Version 3 / 21 No
Page 75 and 76:
HFIDTC/2/12.2.1/1 Version 3 / 21 No
Page 77 and 78:
Page 79 and 80:
Page 81 and 82:
Page 83 and 84:
Page 85 and 86:
Page 87:
show all

The Impact of Technology Insertion on Organisations

Create successful ePaper yourself

Delete template?

Save as template?