The Impact of Technology Insertion on Organisations

More documents

Recommendations

Info

HFIDTC/2/12.2.1/1 Version 3 / 21 November 2007 risks occur just as frequently in material, component and physical technology insertion projects as in IT and IS projects. <strong>The</strong> use <strong>of</strong> IT and IS examples here is simply due to the extent with which these two domains have analysed TI failures through the use <strong>of</strong> detailed case studies. <strong>The</strong>se case studies are particularly valuable as they seek to understand the causes <strong>of</strong> problems on IT and IS projects as they take a qualitative as well as a quantitative approach to understanding the underlying issues. 5.2.1 Project Size Willcocks and Griffiths [34] reviewed the main research studies on risk and concluded that prominent projects commonly experience overruns, are <strong>of</strong>ten over budget, do not perform in the way expected, or are cancelled prior to their completion after the expenditure <strong>of</strong> considerable sums <strong>of</strong> money [35], [36], [37], [38]. Small projects run less risk and are <strong>of</strong>ten more tolerant <strong>of</strong> process lapses, while large projects run exponentially larger risk and need ever increasing management and control <strong>of</strong> risk. A 1994 survey <strong>of</strong> 200 IT projects found that for projects over £660,000, 90 per cent were over budget, 98 per cent had changed specification, 60 per cent were over time, and 20 per cent were inappropriate [39]. 5.2.1.1 Pressure on Managers and Implementers Miller [40] reported that to implement IT innovation, top administrators are expected to take the risk <strong>of</strong> failure or delay <strong>of</strong> IT adoption. An assessment <strong>of</strong> five IT projects in the Danish public sector found that the customers as well as the developers have had unrealistic expectations about how easily the systems could be installed and put into operation [41]. Research has also suggested that IT project managers may not be equipped to lead projects that are expected to transform an organisation, and are poorly equipped to set technology priorities that affect more than one part <strong>of</strong> the organisation [42]. Another problem is the over optimism and unrealistic mindset <strong>of</strong> upper management which can come from insufficient understanding <strong>of</strong> the technology and a lack <strong>of</strong> awareness <strong>of</strong> the magnitude <strong>of</strong> the impact that the new technology will have upon the organisation. 5.2.1.2 Escalation <strong>Technology</strong> projects have a tendency to escalate, with decision makers electing to commit additional resources to a project where financial and organisational outcomes as well as common sense indicate that the project should be cancelled or redirected. While escalation <strong>of</strong> commitment is a general phenomenon that can occur with any type <strong>of</strong> project, the literature [43], [44], [45], [46], [47] suggests that IT projects may be particularly susceptible to this problem. <strong>The</strong> intangible nature <strong>of</strong> s<strong>of</strong>tware makes it difficult to obtain accurate estimates <strong>of</strong> the proportion <strong>of</strong> work completed which may promote escalation <strong>of</strong> commitment by giving a false perception that successful completion <strong>of</strong> the project is near. To add to the difficulty <strong>of</strong> measuring progress, IT projects are dynamic and tend to have volatile requirements [44], [46], which cause project scope to change frequently. Almost certainly, projects subject to such volatility are especially difficult to manage and control. For these reasons, it is not surprising that escalation occurs with high frequency in IT projects. Project failure in the IT area is a costly problem and troubled projects that seem to take on a life <strong>of</strong> their own are not 13
HFIDTC/2/12.2.1/1 Version 3 / 21 November 2007 uncommon [48]. Prior research has shown that managers can easily become locked into a cycle <strong>of</strong> escalating commitment to a failing course <strong>of</strong> action [49]. 5.2.2 Maturity <strong>of</strong> <strong>Technology</strong> In 1999, the United States (US) General Accounting Office (GAO) produced an influential report that examined the differences in technology transition between the Department <strong>of</strong> Defense (DoD) and private industry [50]. It concluded that the DoD takes greater risks and attempts to transition emerging technologies at lesser degrees <strong>of</strong> maturity than does private industry. <strong>The</strong> GAO concluded that use <strong>of</strong> immature technology increased overall program risk and recommended that the DoD adopt the use <strong>of</strong> National Aeronautics and Space Administration’s (NASA) <strong>Technology</strong> Readiness Levels as a means <strong>of</strong> assessing technology maturity prior to transition. <strong>Technology</strong> Readiness Levels (TRLs) have been used within the NASA as part <strong>of</strong> an overall risk assessment process (since the late 1980s). By the early 1990s, they were routinely used to support technology maturity assessments and comparisons <strong>of</strong> maturity between different hardware technologies. In the UK TRLs and broader System Readiness Levels (SRLs) have been adopted by the (then) DPA to assess the maturity <strong>of</strong> evolving technologies (materials, components, devices, etc.) prior to incorporating that technology into a system or subsystem and continue to be used within technology procurement projects to this day. <strong>The</strong> primary purpose <strong>of</strong> using TRLs is to help management in making decisions concerning the development and transitioning <strong>of</strong> technology. Advantages include: o Provides a common understanding <strong>of</strong> technology status o Risk management o Useful to making decisions concerning technology funding o Useful to support decisions concerning transition <strong>of</strong> technology Although many project teams have found TRLs to be useful, several sources cite the difficulties in applying TRLs to assess the readiness <strong>of</strong> s<strong>of</strong>tware-based technologies and products. Some <strong>of</strong> the characteristics <strong>of</strong> TRLs that limit their utility in assessing COTS s<strong>of</strong>tware products include the fact that readiness does not necessarily fit with appropriateness or technology maturity. Smith [51] points out that ‘readiness’ and ‘maturity’—though frequently used interchangeably—are not the same thing. A mature product may possess a greater or lesser degree <strong>of</strong> readiness for use in a particular system context than one <strong>of</strong> lower maturity. Numerous factors must be considered, including the relevance <strong>of</strong> the products’ operational environment (usage patterns, timeliness/throughput requirements, etc.) to the system at hand, product-system architectural mismatch, as well as other factors. 5.2.3 Human Centred Design <strong>The</strong> National Audit Office (NAO) report by the Controller and Auditor General [52], addresses the reasons why many equipments accepted into service by the MoD do not fully meet the operational requirements. This report provides examples <strong>of</strong> projects where 14
Page 1 and 2: The Impact
Page 3 and 4: HFIDTC/2/12.2.1/1 Version 3 / 21 No
Page 17: HFIDTC/2/12.2.1/1 Version 3 / 21 No
Page 69 and 70:
HFIDTC/2/12.2.1/1 Version 3 / 21 No
Page 71 and 72:
Page 73 and 74:
Page 75 and 76:
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?