The Impact of Technology Insertion on Organisations

More documents

Recommendations

Info

HFIDTC/2/12.2.1/1 Version 3 / 21 November 2007 existed or the business process does not allow any other method to be used concurrently. Examples <strong>of</strong> such systems include the introduction <strong>of</strong> e-mail or ticketing systems. <strong>The</strong> London Stock Exchange used a big bang approach in 1987 when it computerised trading. Potential problems <strong>of</strong> the big bang approach may include complete system failure, inappropriate modules and/or institutional shock. Parallel running involves introducing the new system whilst continuing the old system in tandem with it. This reduces the risk <strong>of</strong> the new system failing as the old one is available as a backup. However, this approach doubles work requirements and therefore requires greater resources and the added cost that this entails. All users can get used to the new system, and fall back on their old system if necessary. Phased adoption means that the introduction <strong>of</strong> new technology occurs in several phases. In a phased approach aspects <strong>of</strong> the new system are introduced over a period <strong>of</strong> time. Whilst this phasing in may be done on a geographical basis or user group basis, it is more commonly done on a functional basis. <strong>The</strong> system is rolled out over a period <strong>of</strong> time, building and developing functionality with each phase <strong>of</strong> the roll out. This is a common approach with bespoke systems. Whilst it enables users to concentrate on specific elements one at a time, problems may occur where functionality is linked, in new networks, or where there is a mismatch <strong>of</strong> the old and new system. If minimising risk to operation <strong>of</strong> the organisation is key, then either a parallel running or a phased introduction approach may be appropriate. <strong>The</strong> trials and dissemination approach is used where there are several different sites for implementation. <strong>The</strong> system is implemented one site at a time as a series <strong>of</strong> implementations. Sites may be selected for ease <strong>of</strong> implementation to ensure that the correct approach is used and in order to iron out problems. However, sometimes different sites can have different problems requiring a different approach. Another risk is that the initial site selected to pilot the system may not be reflective <strong>of</strong> the other sites. <strong>The</strong> final approach, incremental evolution, is a mixture <strong>of</strong> strategies and <strong>of</strong>ten involves parts <strong>of</strong> a system being tested, whilst continuing to make changes. This approach is user driven and is <strong>of</strong>ten beneficial for discretionary users, but can result in reduced momentum. This approach can also be difficult to plan. 8.2 Risk Assessment in <strong>Technology</strong> Programmes In Section 5 some <strong>of</strong> the key risks to technology insertion were outlined, however there is evidence from case study research and from the literature [179], [180], [181] <strong>of</strong> an undermanagement <strong>of</strong> risk in technology projects. Pike and Ho [181] found that there is a general lack <strong>of</strong> managerial use <strong>of</strong> risk analysis in capital budgeting decisions to the detriment <strong>of</strong> IT projects. Research studies have shown that the result <strong>of</strong> this is that over 20 per cent <strong>of</strong> IS expenditure is wasted and between 30 and 40 per cent <strong>of</strong> IS projects realise no net benefits, however measured [183]. 41
HFIDTC/2/12.2.1/1 Version 3 / 21 November 2007 8.2.1 Risk Assessment Models Risk assessment is the process involved in estimating the degree <strong>of</strong> risk associated with a given project, usually at the feasibility stage <strong>of</strong> development [184], [185]. This approach is designed to reduce risk; however, Lyyntinen and Hirsheim [186] found that a narrow focus on risk techniques can blind participants to the organisational context, where many projects encounter their most serious difficulties. <strong>The</strong>re have been a number <strong>of</strong> risk assessment models developed specifically to analyse risk in technology projects. Although most outline important characteristics <strong>of</strong> risky technology projects, not all <strong>of</strong> them reflect the importance <strong>of</strong> organisational issues and the overall environment and context within which the technology needs to function. Environment and context are two important concepts, which need to be thoroughly analysed and accommodated in design, if a technology is to function successfully within an organisation. <strong>The</strong> under-management <strong>of</strong> risks in IS projects is very surprising considering the size <strong>of</strong> IT expenditure, and when the history <strong>of</strong> disappointed expectations is considered. 8.2.1.1 Willcocks and Margett's Risk Assessment Model <strong>The</strong> basis <strong>of</strong> Willcocks and Margett's Risk Assessment Model came from work by Pettigrew et al. [187], [188] on organisational change. Applying this premise, Willcocks and Margetts developed six conceptual, interplaying categories that can be brought into analysing the development, introduction and use <strong>of</strong> information systems: History: Prior organisational development, e.g. relevant IS experience and organisational history and most importantly, previous IS success or failure. Internal Context: <strong>The</strong> characteristics <strong>of</strong> the organisation itself, e.g. strategy, structure, reward system, management, human resources and industrial relations arrangements, IS infrastructure and management. External Context: <strong>The</strong> ‘givens’ that an organisation and its members need to respond to and accommodate, e.g. the economy, political and governmental policy, markets, competition and, in the public sector, department or local government guidelines, procedures and funding arrangements. Content: <strong>The</strong> changes involved in and substance <strong>of</strong> a project, e.g. size and complexity <strong>of</strong> project, technical uncertainty, whether radical or incremental in impact. Processes: How things are done and the issues perceived, e.g. project management, project team experience, staffing stability, user commitment. Risk Outcomes: Planned or unanticipated, desirable or otherwise, e.g. cost, time, technical performance, operational efficiency, user acceptance. How these categories link together is illustrated in Figure 7: 42
Page 1 and 2: The Impact
Page 3 and 4: HFIDTC/2/12.2.1/1 Version 3 / 21 No
Page 45: HFIDTC/2/12.2.1/1 Version 3 / 21 No
Page 87: HFIDTC/2/12.2.1/1 Version 3 / 21 No

The Impact of Technology Insertion on Organisations

Create successful ePaper yourself

Delete template?

Save as template?