Synopsis of a Scholarly Article

Research article

Factors affecting the successful realisation

of benefits from systems development

projects: findings from three case studies Neil F Doherty1, Colin Ashurst2, Joe Peppard3

1The Business School, Loughborough University, Loughborough, UK; 2The Business School, Durham University, Durham, UK; 3Cranfield School of Management, Cranfield, Bedfordshire, UK

Correspondence: NF Doherty, The Business School, Loughborough University, Loughborough, LE11 3TU, UK. Tel: þ44 01509 223328; Fax: þ44 01509 223960; E-mail: [email protected]

Abstract The return that organisations derive from investments in information systems and technology continues to disappoint. While there is a very significant body of literature on the factors that should facilitate a successful outcome from systems development, there is growing concern that these prescriptions are not having their desired effect. In this paper, we argue that the success of a systems development project should be measured in terms of its ability to deliver meaningful benefits, rather than the timely delivery of a technical artefact, and therefore organisations should adopt an explicit and proactive benefits realisation approach when investing in IT. Consequently, we sought to explore those actionable factors that might facilitate the effective realisation of benefits from systems development initiatives. Three organisations were identified that claimed to adopt a proactive approach to benefits realisation, and detailed studies of their systems development practices were conducted. Our analysis found that whilst one organisation had been successful in its adoption of a benefits realisation perspective, the other two had not, and this allowed us to identify those factors that helped to explain this difference in outcomes. In short, this paper makes an important contribution by identifying how a sub- set of traditional systems success factors might be enhanced, to give them a more explicit benefits realisation orientation. Moreover, it presents a coherent set of principles that can be used for deriving other factors and practices. Journal of Information Technology (2012) 27, 1–16. doi:10.1057/jit.2011.8 Published online 9 August 2011 Keywords: IT development projects; benefits realisation; organisational change; ISD success factors; value

Introduction

T he context for the research reported in this paper is the continued high failure rate of investments in information systems/information technology (IS/IT): a considerable

amount of time, money, effort and opportunity can be wasted upon IT investments that ultimately fail to deliver benefits (Fortune and Peters, 2005; Peppard and Ward, 2005). Estimates of the level of failure may vary, but over the past 30 years they have tended to stay uncomfortably high. More specifically, it has been suggested that in the late 1970s only 20% of the projects ‘achieved something like their intended

benefits’ (Eason, 1988), and that by the late 1980s, it was estimated that up to 70% of IS projects could be classified as failures (Hochstrasser and Griffiths, 1991). By the end of the 1990s, Clegg et al. (1997) reported that ‘up to 90% of all IT projects fail to meet their goals’. In the last decade, Shpilberg et al. (2007) reported that 74% of IT projects from 1994 to 2002 failed to deliver expected value, and a British Computer Society (BCS, 2004) study concluded that ‘only around 16 per cent of IT projects can be considered truly successful’. An even more recent survey of IT executives found that 24% of IT

Journal of Information Technology (2012) 27, 1 –16 & 2012 JIT Palgrave Macmillan All rights reserved 0268-3962/12

palgrave-journals.com/jit/

projects were still viewed as outright ‘failures’, while a further 44% of projects were considered to be ‘challenged’, as they were finished late, over budget, or with fewer than the required features and functions (Levinson, 2009). Against this backdrop, it is important that more reliable ways of managing projects to implement IT investments should be established to help ensure that these can consistently deliver important organisational benefits, rather than becoming a drain on corporate resources.

In response to the ongoing problem of systems failure, academics and practitioners have sought to develop lists of those critical factors that, if addressed, might help to ensure that an organisation’s ability to develop and implement effective new IS might be radically improved. Such lists routinely include factors such as senior management commitment, proactive user engagement, etc. (Plant and Willcocks, 2007; Wang et al., 2008). Unfortunately, despite the widespread promotion of such prescriptions over the last decade, there have only been modest improvements in IT success, and in too many cases the return from IT investment projects continues to disappoint (Shpilberg et al., 2007; El Emam and Koru, 2008). As noted by Cobb (1996), in his now much quoted paradox: ‘we know why [information systems] projects fail, and we know how to prevent their failure – so why do they still fail?’ One possible explanation as to why systems development projects are still frequently perceived to be failing, despite our accumulated knowledge of those success factors that should prevent failure, may well be due to how we define success/ failure and monitor performance. An IT project is still often judged, by the project team/management, to have been successful if the commissioned technical artefact is delivered, on time, on budget and to specification (Ahn and Skudlark, 1997; Clegg, 2000; Doherty and King, 2001; Eason, 2001; Markus, 2004; Sauer and Davis, 2010). However, from the perspective of the organisation, a project will only be perceived as successful if it ultimately delivers benefits that exceed the cost of achieving them.

One potentially important mechanism for ensuring that an IT project is focused upon improvements in organisational performance, rather than simply the delivery of a new piece of IT, is through the establishment of a formal and explicit benefits realisation programme. Benefits realisation manage- ment (BRM) has been defined as ‘the process of organising and managing, such that the potential benefits arising from the use of IT are actually realised’ (Ward and Elvin, 1999). Such an approach is based upon the growing recognition that the benefits of IT typically come from the organisational change that accompanies its introduction, rather than stemming directly from the possession of a technical artefact (Goodhue et al., 2002; Peppard and Ward, 2005; Hughes and Scott Morton, 2006; Peppard et al., 2007). Indeed, a number of previous studies have attempted to promote the role of formal and explicit ‘benefits realization’ approaches, for improving the outcomes of IS development projects, through the proactive management of organisational change (e.g. Farbey et al., 1992; Ward et al., 1996; Remenyi et al., 1997; Ward and Elvin, 1999; Peppard et al., 2007). However, to date, there is little evidence that organisations have been able to translate these prescriptions into effective working practices (National Audit Office, 2006; Ashurst et al., 2008). Consequently, there is a pressing need for more empirical insights into how

organisations might most effectively incorporate an explicit ‘benefits realisation’ perspective into their existing procedures for the design, implementation and operation of IS. One novel and potentially promising line of enquiry might be to explore how our existing understanding of project success factors might be modified, if such factors were far more explicitly focused upon the realisation of benefits, rather than the delivery of a technical artefact. To this end, we sought to investigate how traditional success factors might be tailored to explicitly facilitate the successful realisation of benefits from an IS development project. In so doing, we sought to forge productive new links between two substantial bodies of literature – IS success factors and benefits realisation management – that as yet have failed to deliver on their promise.

In this paper, we focus on the detailed findings of case studies from three public sector organisations. One case study is of particular interest, in that it provides an example of an organisation that has been successful in the adoption of a benefits realisation approach, when managing its investments in IT. This positive case example is contrasted with two other organisations that are also attempting to adopt a clear benefits realisation focus, but with far less success. The structure of the remainder of this paper is as follows. Firstly, we set out the foundations for the study in a review of relevant literature. We then outline the overall research model and the research methods adopted. Next, we provide brief background on the organisations explored in the research, following which we outline the findings related to factors that have facilitated or impaired the adoption of benefits-driven practices for IT-enabled change, before finally relating these findings to the extant literature and then reviewing the implications for practice and further research.

Review and research objectives The purpose of this section is to provide a critical overview of the literatures pertaining to the success factors for systems development and the realisation of benefits from IT projects, before highlighting the gaps in these literatures, and then presenting the study’s objectives.

Success factors for systems development The primary driver for the research into success factors for systems development has been the continuing failure of organisations to realise the full potential from their investments in IS/IT (Standish, 2001; BCS, 2004). Against this backdrop, a significant body of research has been conducted, over the past 30 years, in an attempt to identify and verify those actionable factors that are critical to the successful outcome of complex IS development projects. Most of the early research contributions attempted to derive generic lists of those factors that would be equally appropriate for all classes and types of information system (e.g. Cerullo, 1980; Rademacher, 1989; Yap et al., 1992; Sauer, 1993; Willcocks and Margetts, 1994; Li, 1997). In more recent years, the tendency has been to focus studies more explicitly on success factors for specific categories of information system. For example, the success factors for CRM systems (Kim and Pan, 2006; King and Burgess, 2006); ERP systems (Somers and Nelson, 2001; Plant and

The successful realisation of benefits NF Doherty et al 2

Willcocks, 2007; Wang et al., 2008); executive IS (Poon and Wagner, 2001; Salmeron and Herrero, 2005) and global systems (Angeles and Nath, 2007; Biehl, 2007) have all been previously studied. Despite the significant period over which success factor studies have been published, and the variation in the technologies studied, there is a surprisingly high degree of consistency in their findings. In particular, nearly all studies have highlighted the importance of factors such as: active user involvement (e.g. Rademacher, 1989; Yap et al., 1992; Kim and Pan, 2006); senior management commitment (e.g. Sauer, 1993; Li, 1997; Wang et al., 2008); appropriate staff training (e.g. Milis and Mercken, 2002; Biehl, 2007); the expertise and capability of IT staff (Rademacher, 1989; Yap et al., 1992) and clear identifica- tion of project outcomes (Somers and Nelson, 2001; Biehl, 2007).

Although there is now a vast body of literature pertaining to success factors in systems development contexts, as noted in this paper’s introduction, there is no significant evidence to suggest that the adoption of these universal prescriptions – such as user involvement or senior management commitment – have led to any noticeable improvement in project outcomes. Part of the problem may well be that although the success factors approach has many attractions, it is also flawed in a number of significant ways. For example, it has been argued (e.g. Nandhakumar, 1996; Bussen and Myers, 1997; Larsen and Myers, 1999; Goldfinch, 2007) that:

(i) The success factors literature views system develop- ment projects as a static process instead of a dynamic phenomenon, and therefore ignores the potential for a factor to have varying levels of importance at different stages of the development and implementation process. For example, user involvement may be very important during the systems analysis, testing and implementation phases of a project, but less so during the software-coding phase.

(ii) The success factors approach does not explicitly recognise the variability of systems development projects, and therefore it fails to account for the dynamics of the social, organisational and political context in which any IS project will unfold. For example, it can be argued that the effects of user participation on project outcomes may vary greatly depending upon contextual factors such as: participa- tion forms; types of participants; participation climate; and leadership styles (He and King, 2008).

(iii) The approach treats each individual success factor as a discrete independent variable, and it therefore fails to take account of any potential inter-relationships between the variables. For example, the clear identi- fication of appropriate project outcomes may be dependent upon active user involvement during the early stages of an IT investment project.

(iv) The existing literature also typically assumes that these success factors are purely focused upon a project that concludes with the delivery of the technical artefact. More specifically, while the dependent variable may be composed of operational measures (efficiency, effec- tiveness), as well as project-related measures (budget, timescale, etc.), by and large project-related factors are

used to define the independent variable (Nelson, 2007). Indeed, success factors – such as: project selection; project team members; project champion; user parti- cipation in project and project resources are widely adopted (e.g. Milis and Mercken, 2002; King and Burgess, 2006; Wang et al., 2008) – are frequently and explicitly defined in project-related terms. This is an important limitation of the existing literature, as it implies that the realisation of benefits is wholly dependent upon actions that were undertaken during the systems development project.

A further problem with the factors approach, as noted by King and Burgess (2006), is that many, if not most, success factor studies conclude with a list of factors but provide little further guidance about how and when these factors should be applied in the context of actual IT projects. Consequently, all too often there is a serious disconnect between success factors and project success, so that it becomes difficult to discern any clear causal relationships. Finally, in addition to these much rehearsed criticisms, it can also be argued that as the approach is project focussed, it typically fails to take account of organisational learning and capability development over a significant period of time, in which many individual projects may be undertaken (Nelson, 2005).

In conclusion, the stream of literature on success factors in systems development is far too pervasive and substantial to be completely without merit, yet it appears that the common prescriptions it offers need to be far better explained and focused if they are to become more effective. One potentially fruitful, yet currently unexplored, line of enquiry is to investigate how success factors might be re-configured if they were more explicitly focused towards the delivery of benefits in the medium to long term, rather than the delivery of a new piece of IT in the short term.

Benefits-driven approaches to systems development There has been a great deal of prior academic interest in, and indeed argument about, how the benefits arising from IT can best be measured (e.g. Delone and Mclean, 1992; Farbey et al., 1992; Irani et al., 2007; Petter et al., 2008; Mitra et al., 2011). Despite this uncertainty, it has also been argued that benefits should act as the focal point for all design and ongoing development activity throughout a system’s operational life (Ward and Elvin, 1999). However, in practice, it has been found that IT project teams tend to only consider benefits when writing the initial business case, but then once approval has been granted, any ongoing benefits focus tends to rapidly fade away (Ashurst et al., 2008). What is more, even if organisations did want to use their business cases as the point of departure for a more proactive attempt to manage the delivery of benefits, they would still face two major problems. Firstly, in order to get their projects approved, the writers of business cases typically overestimate the benefits and understate costs (Ward et al., 2008). Secondly, as it is widely argued that the outcomes from systems development projects are typically emergent, over the life of the system, rather than planned (Orlikowski, 1996), it is unlikely that the initial business case will provide a reliable road map for the downstream

The successful realisation of benefits NF Doherty et al 3

management of benefits. Against this backdrop, it has become clear that there is a great deal more to benefits realisation than simply encouraging IT professionals to stick to their business cases.

As benefits rarely spring automatically from the introduc- tion of a new technology (Eason, 2001; Doherty et al., 2003), the adoption of a benefits realisation programme is increas- ingly seen as an important mechanism for proactively managing new IT initiatives (Peppard et al., 2007; Ashurst et al., 2008). The defining characteristic of a benefits realisation approach is that it seeks to facilitate a programme of organisational change that will complement a new information system’s functionality, and in so doing facilitate the realisation of important benefits (Serafeimidis and Smithson, 2000; Hughes and Scott Morton, 2006; Peppard et al., 2007). Such technologically mediated organisational changes come in all shapes and sizes. For example, an organisation is far more likely to realise benefits from its new Enterprise Resource Planning (ERP) implementation if it explicitly redesigns its working practices to more closely reflect the process model embedded in the system (Ke and Wei, 2008). Similarly, benefits may only be leveraged from a new data warehouse if the host organisation actively seeks to modify its culture so that its staff are more flexible, customer- focussed and empowered (Markus, 2004).

In addition to its explicit focus on organisational change, the other really significant area in which benefits reali- sation differs to more traditional approaches is in terms of its timescale. Although it may be possible to effectively plan some types of benefit in advance, others are emergent as users innovate and improvise with their local working environments (Orlikowski, 1996); as powerful actors initiate technologically occasioned organisational change (Leonardi and Barley, 2010) or as information from a new system is used to guide further organisational change (Leonardi, 2007). Indeed, the operational life of a system is typically punctuated by a series of changes to the organisational form and function, coupled with modifica- tions to the information system’s design (Lyytinen and Newman, 2008). BRM therefore has a critical role to play in both facilitating and regulating this ongoing process of organisational change to ensure that opportunities are exploited in a productive manner (Ashurst et al., 2008).

Unfortunately, despite this growing interest (e.g. Ward et al., 1996; Reymeni and Sherwood-Smith, 1998), the benefits realisation agenda is exhibiting many of the same characteristics, as the socio-technical literature (Mumford, 1995; Avison et al., 1998): an excellent idea, in theory, but having little impact on the way projects are being managed, in practice (Pfeffer and Sutton, 2000). There is a growing body of literature that advances the case for a variety of different benefits realisation tools, techniques and approaches (e.g. Reymeni and Sherwood-Smith, 1999; Bradley, 2006; Ward and Daniel, 2006; Esteves, 2009). However, there has been relatively little empirical investi- gation of what, if anything, organisations are doing in practice, to proactively manage benefits from their IT investments. Against this backdrop, there is a pressing need for novel contributions that present insights into how an explicit focus on benefits realisation might best be incorporated into the actual routines of systems develop- ment and implementation.

Critique of literature and research objectives For far too long IS success has been primarily defined, and therefore IT project managers rewarded, in terms of completing a software development project on time, to specification and within budget (Nelson, 2005; Sauer and Davis, 2010). Indeed, the most well-used index of informa- tion success/failure – the biennial Standish Group reports – defines success using these very criteria (e.g. Standish, 2001). Consequently, the literature on success factors for IS development has also typically adopted a short-term perspective, which assumes that the success of projects can be judged once the software development project has been completed, which is normally shortly after implementation (Sauer et al., 2007). In practice, however, the delivery of IS on time, to specification and within budget, does not automatically equate to the delivery of real benefits to the host organisation, as there is increasing recognition that the impacts of IT are typically emergent, over the operational life of the system (Orlikowski, 1996; Lyytinen and Newman, 2008), and its benefits cannot therefore be readily or accurately planned in advance. Consequently, it is appro- priate to view benefits realisation as an ongoing journey, rather than a destination (Goh and Kauffman, 2005; Hardgreaves and Armstrong, 2005).

Against this backdrop, the project’s process-focused success factors that contribute to the successful outcome of software development projects might not identify with those that are necessary to deliver real organisational benefits in the longer term. The key difference, apart from timescale, would seem to be that the traditional success factors literature focuses primarily on the delivery of a technical artefact, and rather ignores, or underplays, the need for complementary organisational change, upon which the realisation of business benefits is dependent (Markus, 2004). Indeed, project management methodolo- gies like PRINCE2 focus primarily on delivering ‘the product’ (i.e. the technical artefact), paying far less attention to business benefits. Consequently, there is a pressing need for a critical re-evaluation of the traditional prescriptions for ensuring the successful outcome of software development projects, to see whether they take on a different form when being applied within the confines of IS development initiatives that have an explicit benefits realisation orientation. In particular, we were keen to explore how such success factors might be modified, if their purpose was to facilitate the realisation of meaningful business benefits in the long term, rather than the delivery of a technical artefact in the short term.

Overview of the research methods The purpose of this section of the paper is to review and present the methods by which the research data were collected, validated and ultimately analysed. However, before reviewing the research methods, it is necessary to comment on our philosophical perspective (Lee, 1999), which can be broadly categorised as ‘interpretive’ as our aim was to gain ‘knowledge of reality’ through the study of social constructions, in particular, language and documents (Klein and Myers, 1999). In particular, this study adopted a dialectic hermeneutic approach (Myers, 1994: 58) to help make sense of an information system’s development and

The successful realisation of benefits NF Doherty et al 4

utilisation process, in which ‘different stakeholders may have confused, incomplete, cloudy and often contradictory views on many issues’. Moreover, in designing this study, we prioritised the need to produce ‘relevant and timely’ research (Davenport and Markus, 1999: 20) and to ‘produce knowledge about how to intervene in the world and change it in order to satisfy real-world needs’ (Lee, 1999: 29). The aim of this section is to provide a review of the context in which the research was located, before reviewing the overall research design, and then describing the targeting, execu- tion and analysis of the case studies.

Research design To provide rich and critical new insights into the realisation of benefits from IS development projects, we needed to gain a high degree of access to IT professionals and business stakeholders working on a variety of IT development projects. Public sector organisations were targeted, as we perceived that they might have the most to gain from involvement in our research, as prior research suggests that such organisations have typically struggled with IT projects (Fountain, 2001; Goldfinch, 2007), and they are generally more willing to be more open about their experiences than their private sector counterparts. Ultimately, we gained permission to conduct in-depth case studies at three public sector organisations, each of which had three or more individual IS projects underway, which could be studied. The decision to focus on a variety of projects within each case organisation was an important element of the research design, as it allowed us to focus upon organisation-wide competences and practices, rather than project-specific approaches. The first system investigated, in the first case organisation, was used as a pilot to test out the overall approach to collecting and analysing evidence.

Data collection The aim of our study was not to define and explore hypotheses about the role and impact of benefits realisation

approaches in a ‘positivist’ sense but to develop a rich understanding and explanation of a highly complex situation, which in the longer term may be of real use to practitioners (Eisenhardt, 1989). Consequently, our pri- mary data collection instrument was the semi-structured interview, which allowed for a high degree of flexibility, and at each case organisation we interviewed at least ten individuals, some of whom we interviewed more than once. The interviews were either tape-recorded or detailed notes were recorded, depending upon each interviewee’s preference. To provide a broader perspective, and to triangulate the findings, a number of key project events – such as steering committee or project meetings – were observed at each organisation, and a variety of project and strategic documentation were critically analysed. Upon completion of each data collection exercise, a provisional analysis of the data was conducted, after which a series of follow-up meetings were held with each case organisation, to validate and extend the analysis, as well as helping to fill any gaps in our understanding. A more detailed review of the data collection strategies adopted at each of the three case organisations is presented in Table 1. It can be seen from an inspection of the data in Table 1 that there are some imbalances in the number of data collection activities conducted at each case site, which is inevitable in circumstances in which access to each data source has to be individually negotiated with each case organisation. How- ever, given the relatively modest nature of these differences, and the large amount of data collected at each site, we do not believe that such differences will have made any material difference to our analysis and interpretation of the data.

Data analysis The notes made during each interview were reviewed and typed up immediately after the interview, after which additional ‘marginal notes’ (Miles and Huberman, 1994) and a brief summary of key themes were added. This data-recording and preliminary analysis was in line with

Table 1 Data collection approaches

Organisation type

Organisation A: strategic health authority

Organisation B: university Organisation C: city council

Interviews/ Interviewees

Seventeen interviews with fourteen interviewees: business sponsor, programme manager, project manager, users, etc.

Seventeen interviews with seventeen interviewees: Dean; IT Director; analysts, users, etc.

Eleven interviews with ten interviewees: Director of business division; IT Director; project managers; transformation manager, etc.

Document review

Examples include: business change plan; project initiation document; health deployment plan, etc.

Examples include: IS strategy; requirements specifications; functional specifications; project briefs, etc.

Examples include: customer service strategy; user guides; communication plan; customer services plan, etc.

Observation Four individual events: strategy meetings, benefits workshops, etc.

Seventeen individual events: strategy, project, progress and user meetings, etc.

A number of visits were undertaken to the council call centre and offices, at which the researcher could both observe and informally interview workers

Follow-up meetings

Four clarification/validation meetings

Three clarification/validation meetings

Three clarification/validation meetings

The successful realisation of benefits NF Doherty et al 5

the recommendations by Silverman (2000) that it is important to expand beyond immediate observations to have four levels of notes: notes made at the time, additional notes as soon as possible after the session, a fieldwork journal to record problems and ideas that arise, and a provisional record of analysis and interpretation. This approach to data gathering and initial analysis was very helpful as it made it possible to adapt later interviews to take account of earlier findings and, for example, explore specific areas or seek evidence to support preliminary conclusions (Daniel and Wilson, 2003).

Following the preliminary analysis of each individual interview, a hermeneutic approach was applied to further analyse and make sense of all the research data that had been collected (Butler, 1998; Lee, 1999). To ensure that a rich and valid interpretation of the data was ultimately achieved, the within-case analysis was not conducted in a single iteration: the researchers sought to ‘understand the whole’ by continually revising it in ‘view of the reinterpreta- tion of the parts’ (Myers, 1994: 56). Consequently, the researchers would keep re-visiting their interview tran- scripts and other documentary evidence, for a specific case, and where necessary initiate follow-up phone-based interviews, to help integrate the individual pieces of evidence into a coherent whole (Butler, 1998). For example, ‘innovative governance structures’ was a recurring theme identified from the initial review of four of the interview scripts from Organisation C. Subsequently, all the interview scripts and business documents were reappraised several times to explicitly develop a more comprehensive under- standing of this phenomenon. In situations in which there was any uncertainty over the purpose, operation or implications of these ‘innovative governance structures’, phone-based follow-up interviews would be initiated to clarify our thinking.

This case-based evaluation continued over an extended period of time as all the data were analysed and interpreted and the findings were documented, and then discussed with the organisational sponsor.1 Having thoroughly analysed each case individually, the focus then shifted to cross-case comparisons, to explore the degree to which there were commonalities across, or inconsistencies between, the three distinct cases. The key to cross-case analysis was to look at the data in many different ways with the goal of going beyond initial impressions (Eisenhardt, 1989; Walsham, 2002), to try to develop a robust and meaningful set of new insights.

The case study organisations This section provides brief background information on the three case organisations and the projects involved in the research. While Organisation C was explicitly seeking to adopt a benefits-driven approach and to develop a benefits realisation capability, organisations A and B were also trying to improve their ability to realise benefits from systems development projects.

Organisation A: Organisation A was a strategic health authority (SHA), part of the National Health Service in the UK. The SHA was part of a regional ‘cluster’ of SHAs that was in the early stages of the NHS National Programme for

IT (NPfIT). The SHA co-ordinates healthcare within a geographical region, working with the various trusts delivering, for example, primary and acute healthcare services. NPfIT was one of a number of major improvement initiatives: ‘The National Programme for IT, delivered by the new Department of Health agency NHS Connecting for Health, is bringing modern computer systems into the NHS to improve patient care and services’. The research focussed primarily on three IS projects, as a well as interviews at the SHA, exploring the wider context within which the projects were taking place. These projects were: (1) a single assessment process, to provide a ‘one stop shop’ for health and social services; (2) a child health support system, to provide better, more complete, patient information for a particular primary care trust (PCT); and (3) a separate child health support system, for a different PCT, which was based on similar software, but supporting different processes and objectives. Unfortunately, due to a very significant restruc- turing of the SHA, at about the time that the systems went live, none of the systems were ever utilised in the organisational unit for which it had been specifically designed, and ultimately few if any benefits were delivered. While this type of problem is all too common in the NHS (Heeks, 2006), and therefore this type of outcome potentially foreseeable, we had been very pleased to gain access to an NHS organisation, as we believed that such a track record might make it a highly fertile environment for the adoption of a benefits realisation approach.

Organisation B: Organisation B is a university, which operates a federal structure, with each faculty and depart- ment having considerable autonomy. The management of IT is in line with this model. The IT function is one of a number of service departments and does not have full control over IT decision making across the university. At the time of the study, this governance framework was evolving and there was an attempt to move towards greater central control of decision making, for example through establishing a new IT steering group and through greater centralisation of IT budgets. The case study addressed four distinct IT projects, which were as follows: (1) a desktop upgrade; (2) an online eLearning system; (3) a customer relationship management system; and (4) a student administration system. In terms of the university’s success in realising benefits from these projects, the picture was very mixed. The desktop upgrade was successfully com- pleted as a technical project with smooth deployment of the upgraded version, but there was little focus on any complementary strategies, to ensure that end-users could take advantage of these new features. The customer relationship management and student administration projects were cancelled before implementation. The eLearning system was being extensively used across the university with generally positive feedback from staff and student users.

Organisation C: In response to pressure from the govern- ment to ensure that the local government was providing value for money, the council undertook a ‘best value review’ covering IT and various service functions (payroll, council tax collection, etc.). The review exercise resulted in a Transformation Programme and the outsourcing of some

The successful realisation of benefits NF Doherty et al 6

council activities. The Transformation Programme was based upon business change and benefits realisation: ‘In a compressed period of time we’re bringing about radical change in how the Council works using IT as a catalyst y The Transformation Programme plan and the Transforma- tion Programme office is about monitoring the benefits realised and making sure benefits are realised at the appropriate time y IT is recognised as a key business enabler’. The case study is primarily based upon three projects that were part of the overall Transformation Programme. These projects were: (1) a desktop renewal system, across all council PCs; (2) a human resources (HR) and payroll system, and (3) customer relationship manage- ment, to ‘challenge the way we operate and deliver services around the needs of the customer’. At the end of the data collection period, all three projects were projected to deliver their planned benefits, and many benefits had already been realised. For example, the Customer Relation- ship Management (CRM) system had increased the resolu- tion of queries, at the first point of contact, from 70% to 83%, while also significantly improving customer satisfac- tion ratings. With respect to the HR system, the IT Director commented ‘It went in absolutely on time and on budget’, and perhaps most importantly it achieved all of its primary objectives, most noticeably ‘a reduction in the incidence of sickness absence’.

Research results: succeeding with benefits realisation The research has provided valuable insights into how organisations can succeed with realising real business benefits from IT-enabled change. Case study Organisation C had adopted a clear and proactive focus on the realisation of benefits through business transformation, rather than delivery of IS/IT solutions, and organisations A and B were both also attempting to make benefits the primary focus of their software projects. The remainder of this section is used to present evidence from these three cases to demonstrate how many of the traditional success factors for IS development projects have been reconstituted, when applied in projects that have a far more explicit benefits focus.

From identifying goals and objectives to detailed benefits planning The success factors literature is very clear that, at the outset of every systems development project, an un- ambiguous set of goals and objectives for the project should be articulated, so that all stakeholders have a shared vision of the resultant system’s likely contribution (Somers and Nelson, 2001; Akkermans and van Helden, 2002; Biehl, 2007). However, the success factors literature has been far less clear about how such objectives should best be realised, in terms of explicitly linking them to specific aspects of software functionality, organisational redesign, or both. Consequently, we were keen to establish whether business cases were, in addition to specifying benefits, now also explicitly focusing on how such benefits might be attained. For example, to what extent were more benefits-oriented techniques such as the benefits dependency network (BDN)2 (Ward and Daniel, 2006; Peppard et al., 2007) being deployed.

In Organisation A, they were trying to use a variant of the BDN, but they experienced a number of problems in its adoption. Indeed, several project participants stressed that the benefits planning approach was not working, primarily because they felt that it was being imposed on the programme in the hope of finding benefits – which in fact did not exist. As one interviewee (A08) noted: ‘The programme is already up and running and the systems are being developed. The work on benefits is just being forced fitted onto a signed off model – there is very little choice. It can’t work, as there is no opportunity to influence what is happening. No one wants to do it. It becomes a political game – seeking for benefits that aren’t there’. This view was supported by another interviewee (A03)3: ‘Business cases are very weak. The benefits are not well defined – it’s just management speak’.

At Organisation B, the projects showed no explicit focus on proactive benefits planning, beyond the inclusion of a list of general benefits in project documentation. There was no specific focus on measurement or ownership of benefits, or the definition of the business changes required to realise the benefits. A typical example of the highly abstract nature of Organisation B’s project goals was to ‘replace all manual and semi manual systems with one consolidated and rationalised system’ (B03). The organisation had little experience of managing IS projects successfully, and consequently it had no established framework, practices or indeed appropriate competences for managing such projects. Indeed, project planning was handled via existing departmental committees, and the informal dialogues that take place around them, rather than instituting a com- pletely new and more tailored approach (B20e).

Traditionally, Organisation C had adopted a very laissez faire approach to benefits planning. As one interviewee (C10) commented: ‘we often had a clear picture about the beginning – “implement a system”, and a clear picture about the end – “top quartile performance”, but there was a big gap about what goes on in between, that is what is the change in the business that is going to benefit the customer’. With the Transformation Programme, a radically different approach was adopted, in that every separate project had its own clearly defined business benefits. Moreover, the project team would seek to identify what was required to make the changes happen and realise the benefits, particularly in terms of clearly specifying changes to business processes and working practices, and articulating the role of IT as an enabler of benefits. As one interviewee (C10) commented: ‘The benefit roadmap doesn’t focus just on IT implementa- tion – we’re making it business driven, we’re trying to establish a systematic approach to change management’. Consequently, in Organisation C, we see an approach being utilised that has moved from simply identifying goals, to detailed planning for the realisation of benefits.

From project management to the management of transformation The IS development process is usually conceived as a time- and budget-constrained project, the goal of which is to deliver a new technological artefact, which is capable of delivering some pre-specified functionality (Sauer and Davis, 2010). Consequently, the literature has typically emphasised the critical role of effective project management processes in

The successful realisation of benefits NF Doherty et al 7

facilitating successful outcomes (Akkermans and van Helden, 2002; Lam, 2005). By contrast, the benefits realisation literature (Ward and Daniel, 2006; Ashurst et al., 2008), while recognising the valuable contribution of project management techniques, places far more emphasis on the need to effectively manage organisational change, so that business processes and working practices can be transformed to accommodate the new information system. Moreover, this process of organisational transformation should extend over the working life of the new information system, rather than being terminated at the end of the traditional development project, when the new technological artefact has been successfully implemented.

At Organisation A, there was a heavy dependence on formal project management techniques, with PRINCE2 being routinely used to support all project planning, control and management requirements. By contrast, although the need for a complementary programme of change management was widely acknowledged, it had been extremely difficult to institute in practice. The effort required to go from group to group, managing change through a process of engagement, training and other activity was recognised to be enormous: ‘there is a general resource shortage. Who covers the clinicians while they’re involved in design and systems training? This has a major resource impact. In some areas there are just one or two people in teams. This is such a complicated, unsolvable problem that it’s just ignored. If you tell them the commitment required they’re horrified’ (A12). The interviewee stressed that, in other change initiatives, the approach taken was to establish new incentives and targets so that change was driven locally: ‘The new contract with associated targets and performance measures has driven change. We will change if it is well aligned with practice goals and patient care. The current IT paradigm is central planning and control – it isn’t working. An alternative paradigm could be based on the NHS as lots of small independent businesses and creating an environment where innovations can spread’.

At Organisation B, the emphasis was also placed on managing the delivery of new technology in the short term, rather than initiating and managing a process of transforma- tion in the longer term. Despite recognising the importance of complementary organisational change, in practice this was hard to do, as changes to processes and procedures were typically initiated centrally, and it was difficult for depart- ments introducing new technologies to unilaterally tailor their working practices. However, once new IS were implemented, the university did establish teams, with a good mixture of technical and business skills, to provide support and training for users, as well as sharing good ideas and good practice. As one team member (B16) noted: ‘our aim is to work with academic staff to help them enhance learning for students’.

By contrast, at Organisation C, there was an explicit recognition that although good project management techniques were important, they did not go far enough, particularly in terms of their ability to help manage organisational change. As the Transformation Director noted (C10): ‘PRINCE2 – we have adapted this. We embraced the fundamentals – it’s only a methodology – it’s going to help. We’ve had a look at why programmes typically fail and we’ve come to a focus on business change. We need to get the capability to change. PRINCE2 doesn’t address change4 – we need broader skills’.

Consequently, in Organisation C, we are seeing evidence of an explicit move towards a very different way of managing IT initiatives, in which technology was seen as just one component of a wider business transformation strategy. A good example of this approach was found with regard to the initiation of a project to provide higher levels of customer service, while simultaneously reducing the costs of service delivery. The key deliverables from this project were two new customer service centres supported by a state-of-the-art CRM system. The key challenge was to ‘completely redesign the operation and delivery of services around the needs of the customer’, to greatly increase the ‘first point of contact resolution of queries’ (C05). Moreover, it was recognised that as well as redesigning business processes, the success of this project was also reliant upon the extensive retraining and education of staff and the fostering of a more explicit customer-centred culture, in which ‘staff were empowered to make the decisions’ (C06). Ultimately, this Transformation Programme was perceived to have been a great success, as: ‘first contact resolution went up from 40% to 80%’; ‘customer satisfaction im- proved’; and the ‘number of queries processed rose’ (council website).

It should be noted that the aim of this section has not been to argue against the adoption of the well-established tools and techniques of project management, as these will always have an important role to play in the effective management of complex IT projects. However, it can be argued that projects should be defined and managed broadly as business transformation, rather than software delivery projects.

From well-balanced project teams to coherent governance structures The importance of assembling well-balanced and effective teams, comprising an appropriate mix of skills and capabilities – to the successful outcome of systems development projects – has long been recognised in the literature (White and Leifer, 1986; Yap et al., 1992; Larsen, 2003). Prior research has also emphasised the importance of effective IT governance structures (Weill and Ross 2005; Tiwana and Konsynski, 2010), and that IT governance is perceived to play ‘a prominent role in fostering project success and delivering business value’ (Bowen et al., 2007). What is far less apparent from the literature is how project teams should be integrated into governance structures so that they can explicitly facilitate the realisa- tion of benefits.

Interviewees at Organisation A recognised the need for a shared focus on benefits: ‘the challenge is to develop and build a benefits realisation capability – we need a common language related to them and their environment’ (A15). Despite having dedicated project teams, in many instances they could not make progress because of the fragmentation of goals and governance structures. In practice, the overall governance structures and decision-making processes were very complicated, with different layers from national, through regional to local, and, too often, it was hard to establish where the actual authority was: ‘we have to escalate queries and problems [to the national or regional level] to get them resolved – the complexity has hugely

The successful realisation of benefits NF Doherty et al 8

increased’ (A12). The issues of governance and decision making were compounded by problems of communication and culture: ‘we’re finding big language/cultural barriers – e.g. around terminology/deliverables and also much bigger issues of style’ (A06). In a similar vein, at Organisation B, there was often confusion about governance and authority because the university’s traditional federal structure – in which departments had considerable authority – was gradually being challenged by IT services who were seeking to establish IT steering groups and impose a greater centralisation of IT budgets. However, it was recognised that this IT-led strategy would not be successful without a significant change in culture: ‘People need to have a more corporate, as opposed to departmental, outlook’ (B01).

One way in which Organisation C increased their success in benefits realisation was to adapt the approach taken to each project, particularly the project team structure and governance framework, depending on the people involved. There was absolutely no doubt that effective team work was perceived to have played a significant role in the delivery of benefits, as one of the project managers (C04) noted: ‘Let’s just remember that success is about casting more than anything else – we could have done the project with different people and it would have fallen flat. It really is about the people’. However, as the Director and Transformation Programme Manager (C10) observed, success went beyond choosing the correct team members and facilitating effective team work: ‘we have moved from asking is X a suitable project manager for this project to how can we best shape the project management role on this team so that X can succeed in this role’. He went on to note that this change has ‘implications for the wider team and project governance framework’. This approach resulted in a number of different structures for project teams and approaches to projects, each of which retained a focus on benefits realisation. For example, important elements of the governance structure used by Organisation C for their payroll and HR system included:

1. Project Team: The team brought together business and IT council staff with external specialists (e.g. in SAP and SAP training). The project team was empowered to take decisions and to propose decisions to other levels of the governance framework.

2. Operational Representatives Group: The operational reps were practitioners (i.e. rather than managers) represent- ing the different teams and departments affected by the project. They provided a two-way communication channel for the project team.

3. Vision Group: The SAP methodology is to focus the work on requirements and design on specific ‘topics’. For this project, 17 topic papers were prepared and the Vision Group was the forum for reviewing key issues from these papers and gaining consensus on key policies.

4. Project Board: The project board included some of the same people as the Vision Group, but was kept separate so the board could focus on delivery against budget and timetable.

5. Transformation Programme Board kept this project under review, along with the 20þ others in the programme.

Effective and focussed governance structures clearly have an important role to play in the delivery of benefits, but it was also recognised that such structures need to be given direction through active business leadership. Perhaps more importantly, there was a strong recognition, at Organisation C, that benefits did not typically arise from a single project, but rather from the combined impacts of a number of complementary IT initiatives. Consequently, their govern- ance structure was designed to ensure that projects, and hence benefits, were managed as an interdependent portfolio.

From senior management support and commitment to active business leadership The crucial role of senior management support and commitment has been much promoted in the systems development success factors literature (Thong et al., 1996; Larsen, 2003; El Emam and Koru, 2008). However, senior managers are typically portrayed as playing a fairly passive and reactive role in the systems development process: providing resources, accepting risks and encouraging participants, as and when necessary (Larsen, 2003). By contrast, we were keen to explore the extent to which senior managers were prepared to actively lead IS development projects, and in so doing, take personal responsibility for the management of organisational change and the delivery of business benefits.

The fragmentation of governance structures at Organisa- tion A, as discussed earlier, was accompanied by the disengagement of senior business leaders from IT-related projects: ‘we currently have a programme board across 10 PCTs plus acute and mental health – but only IT managers are attending – not Chief Executives as intended’ (A06). One interviewee (A01) highlighted that ‘They [senior managers] see it as “all too techie”, we need to break down the barriers. If we do anything they send their IT managers – they’re scared of IT ’. The same interviewee went on to argue that senior managers needed to change their perceptions of the nature of IT and their role within IT projects: ‘senior management need to see their function as transformation’. A number of interviewees (A02, A05, A14) provided evidence of situations where project team members were in need of guidance and were struggling because senior managers were unwilling or unable to provide direction. A similar situation was found at Organisation B, as there was no clear business ownership of the projects, governance structures were found to be weak, and there was no clear route to get project resources allocated in an effective manner: ‘part of the challenge was a new manager and their lack of engagement in the project itself ’ (B13).

The contrast with the approach enacted at Organisation C was stark. Indeed, one manager (C05) commented on the value of the commitment from their business sponsor from the start of a major change programme: ‘To get started you could just kick down doors – as we had such strong backing y I couldn’t count the times we’d just mentioned [the Chief Executive], and this at least got us started’. However, this senior manager’s role went well beyond simply empowering his project team. He established a clear vision for the project in terms of benefits for the organisation and other stakeholders and he played a critical role in realising the

The successful realisation of benefits NF Doherty et al 9

benefits. The project sponsor emphasised a number of additional aspects of his leadership role including ‘coaching outside the meetings’ and ‘co-ordination – handling tensions between different stakeholders and making it happen at board meetings and in between’ (C03). These activities required a significant effort and commitment for the manager, and he acknowledged: ‘it took up a lot of time – a substantial number of hours each week for a year. I gave him (the project manager) the support he needed’. This level of commitment was confirmed by a colleague (C03) who noted: ‘he [the Chief Executive] had daily contact with the project exec’.

From user participation to stakeholder-enabled benefits realisation All too often organisations have used IT projects as the opportunity to confront users with new, and often irreversible, facts on the ground that they then have to live with and adapt to. However, there is now a long- established stream of literature suggesting that the out- comes of systems development initiatives can be improved if users, and other key stakeholders, are actively encouraged to engage with, and participate in, the process (Yap et al., 1992; Kim and Pan, 2006). Typically, such activities are conceived of as occurring within the implementation process and focussing upon the accurate capture of user requirements and the encouragement of positive attitudes towards the embryonic system (Hartwick and Barki, 1994). By contrast, we were keen to explore the extent to which stakeholders had been given a broader remit, which included the responsibility for the specification of benefits, during the development phase of the IT projects in which they participated, and a significant role in the delivery of benefits once the system was operational.

At Organisation A, there was a clearly stated ambition to adopt a more benefits-oriented way of working and a strategy of user engagement, but the two were not obviously or explicitly linked. The organisation had limited experi- ence with benefits management approaches, and the emphasis was placed on completing a range of template- based documents, rather than using the documents to help realise benefits. As one senior manager (A02) noted, the rationale for benefits realisation was widely recognised – ‘a big risk is that we just automate the old way of doing things’ – but went on to reflect that radical changes could not be seriously considered or effectively implemented as ‘people don’t understand why they are doing things’. Consequently, as another interviewee (A11) commented, the scope of user involvement was limited: ‘we didn’t do the work to think through the goals – we were just given a system’. In Organisation B, the verdict on user engagement was even less positive, as staff generally believed that changes were imposed on them, with limited consultation.

In sharp contrast to the lack of alignment between stakeholder engagement and benefits realisation at Orga- nisations A and B, at Organisation C there was extensive stakeholder involvement, with an explicit benefits focus, in each of the projects: ‘we got people involved through training and communication. It generated a lot of excite- ment – it also saved a lot of problems as the users could see the potential pitfalls’ (C06). As a result, benefits were specified in ways that were meaningful to the stakeholders

and there was also much stronger stakeholder engagement in the delivery of the benefits. Moreover, all relevant stakeholders, not just users, were encouraged to engage with projects. Consequently, when designing the new Customer Services system, the customers were actively engaged: ‘they had a good idea of what they wanted, as a result of their [prior] experience of the Customer Service Centre’; ‘they said what was required and so there was ownership’; ‘they were demanding, but it was good’ (C08). Of most importance, when it came to benefits realisation, stakeholders were able to take key decisions: ‘The key was that the people were empowered to make the decisions’ (C05).

From rigorous software testing to ongoing benefits review Over very many years, the success factors literature has presented a clear and consistent message that successful project outcomes are, to a significant extent, dependent upon the rigour and the effectiveness of the software-testing and quality assurance processes (Ennals, 1995; Coombs et al., 1999; Nah et al., 2003; Finney and Corbett, 2007). The rationale underlying this message is very straightforward; inadequately tested software can cost the host organisations very significant amounts of money (Ji et al., 2005), in terms of down-time, disruption and rework. However, the literature has focussed almost wholly on the use of testing to ensure that reliability has been tested into the emerging information system (Butler and Gray, 2006). However, Butler and Gray (2006) suggest that reliability primarily arises from paying close attention to the way in which work is undertaken, once a system is operational. This principle is very closely aligned with Ashurst et al.’s (2008) notion of benefits review, and we were therefore keen to explore whether any of our case organisations were engaged in an ongoing process of benefits review to improve both the reliability and the value of their software implementations.

At Organisation A, major problems were being experi- enced with systems that had been installed with inadequate user input and very little by way of rigorous testing: ‘in the changeover, due to problems, I lost two surgery sessions (60 patients) and could not access my computer for 3 days. The PCT have provided the hardware – but there is no service management to back it up. No one cares about getting the system working. I have now got no access to diary, email or contacts and they don’t want to fix it’ (A09). In a similar vein, it was noted that: ‘there are problems with the system and also with the way the software solution provider are treating the problems – we can’t get out the information we need’ (A11). Consequently, it was recognised that it was not possible to review and exploit benefits until the software was operating reliably: ‘we can’t focus on benefits/change if the basics are not in place’ (A07). A similar situation was noted at Organisation B, where there was no explicit mechanism for exploiting new technologies on an ongoing basis. As one user noted: ‘there is an overwhelming feeling that we’re not making the most of what is available – the problem is, you don’t know what you don’t know’ (B11).

In Organisation C, the need to review the benefits arising from each of their software/transformation projects, on an ongoing basis, was widely recognised. At the conclusion of each IS development project, the functionality of the

The successful realisation of benefits NF Doherty et al 10

resultant software was rigorously tested, but this was a relatively minor component of the ongoing programme of benefits review. For example, with the CRM project, although a phased programme of benefits to be delivered was established relatively early on, this programme was flexible and the benefits review process was used as the mechanism for ensuring that benefits were ultimately achieved. As one interviewee commented (C08): ‘the CRM project is now in its seventh year, and each phase, has had clear goals and benefits – the organisation has not attempted to change everything all at once and have taken time to get benefits at each stage, and also to learn what works and to develop our ability to manage change’. It was also widely recognised that an ongoing process of benefits review was necessary because many benefits would not be apparent at the outset of a project: ‘to my mind it was more a process of discovering the benefits and I think it was for the organisation as a whole y they have been superb at scrutinising themselves and admitting constraints as they learn, but also finding new opportunities as they go through the cycle’ (C04).

One of the very positive effects of Organisation C’s strategy of ongoing benefits review is that it provided a very effective mechanism for IT-oriented organisational learning (Eason, 1988; Nelson, 2005). For example, over the period of the Customer Services programme there had been the opportunity for many of the supervisory staff to develop process mapping and process design skills, which they had eagerly embraced. This meant that the Customer Services team can now effectively run their own workshops rather than having them ‘done to them’ (C04). Crucially, this also meant that there was much deeper knowledge of the system and process within the Customer Services team. In a similar vein, the Transformation Programme Director (C01) saw one of his key roles as developing his teams’ capacity for the management of change related to IT programmes, in general, but particularly strongly focused on their ability to deliver benefits.

Discussion: from systems development to benefits delivery Organisations have become highly reliant on a complex portfolio of IS to support all aspects of their day-to-day operations, as well as their strategic positioning. Unfortu- nately, despite the billions of dollars that organisations are now investing in IT, too often these systems are failing to provide a level of performance and value commensurate with such enormous levels of investment (e.g. BCS, 2004; Goldfinch, 2007). On a positive note, in recent years there has been some noticeable improvement in organisations’ ability to deliver technical artefacts to meet the budget, schedule and scope expectations (Sauer et al., 2007; El Emam and Koru, 2008). However, as Sauer and Davis (2010: 264) note, ‘a project might be successful in meeting its internal targets, yet not deliver beneficial business out- comes’ – a ‘failed success’ in Nelson’s (2005) terms – and this is where organisations still frequently struggle. Conse- quently, an urgent problem facing both the IS academic and the IT practitioner communities is how IT expenditure can be more effectively and consistently translated into mean- ingful business benefits.

The research presented in this paper presents a novel and potentially important contribution to this debate, by assessing the extent to which the outcomes from software implementation projects might be improved if the tradi- tional IS success factors were given a far more explicit benefits realisation orientation. To this end, we were fortunate to be able to gain access to three distinct organisations that were attempting to bring a far more explicit benefits orientation to their software development and implementation process – one of which was making very good progress – and to be able to learn important lessons from all three organisations.

In this paper we have explored how just six of the large number of proposed success factors might be recast to give them a far more explicit benefits orientation. These six were chosen both because they are extremely prominent in the literature, and were also very much to the fore in our three case studies. However, it must be recognised that our list of benefits-oriented factors is by no means complete, as every new system, and its host environment, will be very different, and therefore may require a different set of factors, or similar factors but in a modified form. Consequently, a further important contribution of this paper is to distil the key themes emerging from this study into a set of principles upon which other factors can be established, as described below:

(i) Benefits orientation: A common theme, if not the defining theme, of each of our six modified factors is their clear and explicit focus upon the delivery of benefits to the investing organisation. While the delivery and implementation of a piece of new software is clearly an important milestone, the ultimate goal of an IS development project should be the delivery of clear business benefits. While benefits may not be at the forefront of every discussion and decision, throughout the project, there are many critical junctures in which users and senior managers must play a proactive role in ensuring that benefits will ultimately be realised.

(ii) Organisational change: As it has been persuasively argued, benefits primarily arise from the organisa- tional change, including improved information usage, that accompanies an IT implementation, rather than directly from the technology (Marchand et al., 2000; Peppard and Ward, 2005; Hughes and Scott Morton, 2006); each factor must explicitly address organisa- tional change (or transformation), as well as software provision. Consequently, whether it be business leadership, user participation or benefits planning, they should all focus, at least in part, on the complementary organisational change that will be necessary to realise the benefits.

(iii) Tailor to context: No two IT development projects are the same, and therefore it is important that the application of these factors must be tailored to its specific organisational context and to meet changing demands during the project and investment lifecycle.

(iv) Factors are interdependent constructs: Prior research has tended to view success factors as independent constructs (King and Burgess, 2006), but our study would suggest that these factors are highly

The successful realisation of benefits NF Doherty et al 11

interdependent and therefore they need to be managed as such. For example; user involvement can be more effective if it is enacted through well-balanced teams, and senior management commitment can be more effective if it is delivered through, and supported by, effective governance frameworks.

(v) Investments have a lifecycle: While traditional success factors have been conceived as being applicable for the duration of the software development project, our study suggests that most, if not all, have currency throughout the operational life of the system. Too often an IS development project is seen to end at ‘go- live’ or when it is handed over to its sponsor or users (Hartono et al., 2003; Butler and Gray, 2006). Indeed, process-oriented measures of project success reflect this. However, it is of critical importance to recognise that the investment must be actively managed through its full lifecycle. The latency dimension of many business benefits means that they will emerge well after the project team has disbanded and moved on to the next project.

(vi) Portfolio focus: Factors should not be applied to individual systems, but should be applicable across a portfolio of systems rather than a specific system, as part of the process of developing a benefits realisation capability (Ashurst et al., 2008). For example, in our study the capabilities that Organisation C developed in organisational transformation and benefits exploi- tation were applied to all three of the researched projects.

Based upon the above analysis, it can be argued that this paper makes a number of important theoretical contribu- tions, as discussed in the final section.

Concluding remarks For the past 30 years it has been recognised that an unacceptably high proportion of IS investments end in failure (Hochstrasser and Griffiths, 1991; Clegg et al., 1997), which wastes many billions of dollars of organisational resources annually (Dalcher and Genus, 2003; British Computer Society, 2004). The cost of missed opportunities is probably a great deal more. Consequently, a great deal of research effort has been devoted to understanding how more systems development projects might result in the delivery of benefits, rather than end in failure. Two of the more important strands in this growing body of research relate to IS success factors (e.g. Sauer, 1993; Plant and Willcocks, 2007) and BRM (e.g. Ward and Elvin, 1999; Ashurst et al., 2008). However, to date, neither the breadth nor depth of these two bodies of literature appears to have significantly reduced the level of failures (Fortune and Peters, 2005; Levinson, 2009).

Against this backdrop, this study makes a number of significant contributions to the extant literature. For example, it makes a major contribution to theory by demonstrating the significant synergies that exist between two important branches of the IS’s literature that have previously been viewed and treated as discrete entities. The recognition of this synergistic relationship has enabled us to demonstrate how a number of the traditional IS

success factors can be usefully modified to give them a far more explicit business benefits orientation. Moreover, we have developed the case that IT initiatives might be more successful, in terms of benefits delivery, if they were conceived and managed in terms of ongoing exercises in technology-enabled organisational change, as opposed to simply software delivery. Consequently, while the success- ful delivery of a new piece of software might be seen as an important milestone, it should not be viewed as the primary objective of a new IS project.

While there has already been some recognition that benefits might only be realised once users begin to app- ropriate the technology and adapt it to their own require- ments and working contexts (Boiney, 1998; Leonardi and Barley, 2010), the findings from this study provide some significant new insights into how this process might be facilitated. More specifically, the set of principles, presented in the previous section, should allow IT professionals to refine their existing working practices, to give them a far stronger and longer-term benefits’ orientation. It is important to note, when considering these contributions, that we are not suggesting that the existing systems success factors are intrinsically flawed, but rather that their focus could be enhanced, to improve their chances of delivering positive outcomes. Consequently, the establishment of a set of benefits-oriented success factors may have an important role to play in organisations wanting to rise to the challenge of generating greater value from their IT investments.

Research within complex organisational settings will invariably contain a number of inherent limitations, as compromises and trade-offs are always necessary (Scandura and Williams, 2000). In particular, the adoption of the case study format reduced the number of organisa- tions that could realistically participate in the research and there is also potential bias with respect to the way in which the researchers interpreted the situations to which they were exposed. A second limitation relates to the fact that the research was conducted when each of the reviewed projects was at a different stage in its life cycle, and therefore comparisons have to be made with some caution. Consequently, although this study provides many interest- ing and novel insights, there is now a pressing need for follow-up studies, which employ different methods and target different populations. In particular, we are now keen to undertake some more detailed, longitudinal case studies to explore this phenomena more closely, and in so doing, we hope to gain a deeper understanding of the specific mechanisms by which benefits realisation approaches and practices might best be accommodated within IS develop- ment projects.

Acknowledgements The authors would like to thank the many managers from our three case study organisations who so enthusiastically contributed to our research, as well as the handling editor and reviewers who helped to shape the final version of this paper.

Notes

1 At each case organisation, one, or more, key individuals were given the designation ‘sponsor’. In this capacity, they acted as the liaison between the researchers and the case organisation,

The successful realisation of benefits NF Doherty et al 12

provided access to interviewees and ultimately received/ commented upon the study findings.

2 The BDN has been proposed as a mechanism for explicitly linking, in a structured way, investment objectives and their associated benefits to the business, organisational and IS/IT changes required to realise the benefits (see Peppard et al., 2007).

3 A full break-down of the roles of each of the interviewees can be found in Appendix.

4 It should be noted that as ‘change’ is one of the seven key themes of PRINCE2, the inference of the Transformation Director’s comment is that PRINCE2 does not address change management, in a way that he feels is appropriate for managing such a complex portfolio of IT projects.

References

Ahn, J. and Skudlark, A. (1997). Resolving Conflict of Interests in the Process of

an Information System Implementation for Advanced Telecommunication

Services, Journal of Information Technology 12: 3–13.

Akkermans, H. and van Helden, K. (2002). Vicious and Virtuous Cycles in ERP

Implementation: A case study of interrelations between critical success

factors, European Journal of Information Systems 11: 35–46.

Angeles, R. and Nath, R. (2007). Business-to-business E-procurement: Success

factors and challenges to implementation, Supply Chain Management:

An international journal 12(2): 104–115.

Ashurst, C., Doherty, N.F. and Peppard, J. (2008). Improving the Impact of IT

Development Projects: The benefits realization capability model, European

Journal of Information Systems 17: 352–370.

Avison, D.E., Wood-Harper, A.T., Vidgen, R.T. and Wood, J.R.G. (1998).

A Further Exploration into Information Systems Development: The evolution

of multiview 2, Information Technology and People 11(2): 124–139.

BCS (British Computer Society) (2004). Challenge of Complex IT Projects,

London: BCS.

Biehl, M. (2007). Success Factors for Implementing Global Information

Systems, Communications of the ACM 50(1): 53–58.

Boiney, L.G. (1998). Reaping the Benefits of Information Technology in

Organizations: A framework guiding appropriation of group support

systems, Journal of Applied Behavioral Science 34(3): 327–346.

Bowen, P.L., Cheung, M.-Y.D. and Rohde, F.H. (2007). Enhancing IT

Governance Practices: A model and case study of an organization’s efforts,

International Journal of Accounting Information Systems 8(3): 191–221.

Bradley, G. (2006). Benefit Realisation Management – A practical guide to

achieving benefits through change, Hampshire, UK: Gower.

Bussen, W. and Myers, M. (1997). Executive Information System Failure: A New

Zealand case study, Journal of Information Management 12: 145–153.

Butler, B.S. and Gray, P.H. (2006). Reliability, Mindfulness and Information

Systems, MIS Quarterly 30(2): 211–224.

Butler, T. (1998). Towards a Hermeneutic Method for Interpretive Research in

Information Systems, Journal of Information Technology 13: 285–300.

Cerullo, M.J. (1980). Information Systems Success Factors, Journal of Systems

Management 31(12): 10–19.

Clegg, C., Axtell, C., Damodaran, L., Farbey, B., Hull, R., Lloyd-Jones, R.,

Nicholls, J., Sell, R. and Tomlinson, C. (1997). Information Technology:

A study of performance and the role of human and organizational factors,

Ergonomics 40(9): 851–871.

Clegg, C.W. (2000). Socio-technical Principles for System Design, Applied

Ergonomics 31: 463–477.

Cobb, M. (1996). Unfinished Voyages, a Follow-up to the CHAOS Report, The Standish Group.

Coombs, C.R., Doherty, N.F. and Loan-Clarke, J. (1999). Factors Affecting the

Level of Success of Community Information Systems, Journal of Management

in Medicine 13: 142–153.

Dalcher, D. and Genus, A. (2003). Avoiding IS/IT Implementation Failure,

Technology Analysis and Strategic Management 15(4): 403–407.

Daniel, L. and Wilson, H. (2003). The Role of Dynamic Capabilities in

E-business Transformation, European Journal of Information Systems

12: 282–296.

Davenport, T.H. and Markus, M.L. (1999). Rigor v Relevance Revisited:

Response to Benbaset and Zmud, MIS Quarterly 23(1): 19–23.

DeLone, W.H. and McLean, E.R. (1992). Information Systems Success: The

quest for the dependent variable, Information Systems Research 3(1):

60–95.

Doherty, N.F. and King, M. (2001). An Investigation of the Factors Affecting the

Successful Treatment of Organizational Issues in Systems Development

Projects, European Journal of Information Systems 10: 147–160.

Doherty, N.F., King, M. and Al-Mushayt, O. (2003). The Impact of Inadequacies

in the Treatment of Organizational Issues on Information Systems

Development Projects, Information and Management 41(1): 49–62.

Eason, K. (1988). Information Technology and Organizational Change, London:

Taylor & Francis.

Eason, K. (2001). Changing Perspectives on the Organisational Consequences

of Information Technology, Behaviour & Information Technology 20(5):

323–328.

Eisenhardt, K.M. (1989). Building Theories from Case Study Research,

Academy of Management Review 14: 532–550.

El Emam, K. and Koru, A.G. (2008). A Replicated Survey of IT Software Project

Failures, IEEE Software 8: 84–90. Ennals, R. (1995). Preventing Information Technology Disasters, London:

Springer.

Esteves, J. (2009). A Benefits Realisation Road-map Framework for ERP Usage

in Small and Medium-sized Enterprises, Journal of Enterprise Information

Management 22: 25–35.

Farbey, B., Land, F.F. and Targett, D. (1992). Evaluating Investments in IT,

Journal of Information Technology 7: 109–122.

Finney, S. and Corbett, M. (2007). ERP Implementation: A compilation and

analysis of critical success factors, Business Process Management Journal

13(3): 329–347.

Fortune, J. and Peters, G. (2005). Information Systems – Achieving success by

avoiding failure, New York: John Wiley & Sons, Ltd.

Fountain, J.E. (2001). Paradoxes of Public Sector Customer Service, Governance

14: 55–73.

Goh, K.H. and Kauffman, R.J. (2005). Towards a Theory of Value Latency for IT

Investments, Paper presented at the 38th Hawaii International Conference on

Systems Science, January.

Goldfinch, S. (2007). Pessimism, Computer Failure, and Information Systems

Development in the Public Sector, Public Administration Review 3: 917–929.

Goodhue, D.L., Wixom, B.H. and Watson, H.J. (2002). Realizing Business

Benefits through CRM: Hitting the right target in the right way, MIS

Quarterly Executive 1(2): 79–94.

Hardgreaves, B.C. and Armstrong, D.J. (2005). Software Process Improvement:

It’s a journey, not a destination, Communications of the ACM 48(11): 93–96.

Hartono, E., Lederer, A.L., Sethi, V. and Zhuang, Y. (2003). Key Predictors of

the Implementation of Strategic Information Systems Plans, The DATA BASE

for Advances in Information Systems 34(3): 41–53.

Hartwick, J. and Barki, H. (1994). Explaining the Role of User Participation in

Information System Use, Management Science 40(4): 440–465.

He, J. and King, W.R. (2008). The Role of User Participation in Information

Systems Development: Implications from a meta-analysis, Journal of

Management Information Systems 25(1): 301–331.

Heeks, R. (2006). Health Information Systems: Failure, success and

improvisation, International Journal of Medical Informatics 75(2): 125–137.

Hochstrasser, B. and Griffiths, C. (1991). Controlling IT Investment, London:

Chapman Hall.

Hughes, A. and Scott Morton, M.S. (2006). The Transforming Power of

Complementary Assets, MIT Sloan Management Review 47(4): 50–58.

Irani, Z., Sharif, A.M. and Love, P.E.D. (2007). Knowledge Mapping for

Information Systems Evaluation in Manufacturing, International Journal of

Production Research 45: 2435–2457.

Ji, Y., Mookerjee, V.S. and Sethi, S.P. (2005). Optimal Software Development:

A control theoretic approach, Information Systems Research 16(3): 292–306.

Ke, W. and Wei, W.K. (2008). Organizational Culture and Leadership in ERP

Implementation, Decision Support Systems 45(2): 208–218.

Kim, H.W. and Pan, S. (2006). Towards a Process Model of Information

Systems Implementation: The case of customer relationship management,

The DATA BASE for Advances in Information Systems 37: 59–76.

King, S. and Burgess, T. (2006). Beyond Critical Success Factors: A dynamic

model of enterprise system innovation, International Journal of Information

Management 26: 59–69.

The successful realisation of benefits NF Doherty et al 13

Klein, H.K. and Myers, M.D. (1999). A Set of Principles for Conducting &

Evaluating Interpretive Field Studies in Information Systems, MIS Quarterly

23(1): 67–94.

Lam, W. (2005). Investigating Success Factors in Enterprise Application

Integration: A case-driven analysis, European Journal of Information Systems

14(2): 175–187.

Larsen, K.R. (2003). A Taxonomy of Information Systems Success: Variable

analysis studies, Journal of Management Information Systems 20(2): 169–246.

Larsen, M.A. and Myers, M. (1999). When Success Turns to Failure: A package-

driven business process re-engineering project in the financial services

industry, Journal of Strategic Information Systems 8(4): 395–417.

Lee, A.S. (1999). Rigor and Relevance in MIS Research: Beyond the approach of

positivism alone, MIS Quarterly 23(1): 29–33.

Leonardi, P.M. (2007). Activating the Informational Capabilities of Information

Technology for Organizational Change, Organization Science 18(5): 813–831.

Leonardi, P.M. and Barley, S.R. (2010). What’s Under Construction Here?

Social Action, Materiality, and Power in Constructivist Studies of Technology

and Organizing, Academy of Management Annals 4(1): 1–51.

Levinson, M. (2009). Recession Causes Rising IT Project Failure Rates, CIO

Magazine, 18 June. Li, E.Y. (1997). Perceived Importance of Information Systems Success

Factors: A meta analysis of group differences, Information & Management

32(1): 15–28.

Lyytinen, K. and Newman, M. (2008). Explaining Information System Change

as a Punctuated Socio-technical Change, European Journal of Information

Systems 17: 589–613.

Marchand, D.A., Kettinger, W. and Rollins., J.D. (2000). Information

Orientation: People, technology and bottom line, Sloan Management Review

41(4) 69–80.

Markus, M.L. (2004). Technochange Management: Using IT to drive

organizational change, Journal of Information Technology 19(1): 4–20.

Miles, M.B. and Huberman, A.M. (1994). Qualitative Data Analysis, Thousand

Oaks, CA: Sage Publications.

Milis, K. and Mercken, R. (2002). Success Factors Regarding the

Implementation of ICT Investment Projects, International Journal

Production Economics 80: 105–117.

Mitra, S., Sambamurthy, V. and Westerman, G. (2011). Measuring IT

Performance and Communicating Value, MIS Quarterly Executive 10(1): 47–59. Mumford, E. (1995). Effective Systems Design and Requirements Analysis,

London: Wiley.

Myers, M.D. (1994). Dialectical Hermeneutics: A theoretical framework for

the implementation of information systems, Information Systems Journal

5(1): 51–70.

Nah, F.F.-H., Zuckweiler, K.M. and Lau, J.L.-S. (2003). ERP Implementation:

Chief information officers’ perceptions of critical success factors,

International Journal of Human-Computer Interaction 16(1): 5–22.

Nandhakumar, J. (1996). Design for Success? Critical Success Factors in

Executive Information Systems Development, European Journal of

Information Systems 5(1): 62–72.

National Audit Office (2006). Delivering Successful IT-enabled Business Change,

Report by the Comptroller and Auditor General, HC 33-1, Session 2006–2007,

November.

Nelson, R.R. (2005). Project Retrospectives: Evaluating project success, failure

and everything in between, MIS Quarterly Executive 4(3): 361–372.

Nelson, R.R. (2007). IT Project Management: Infamous failures, classic

mistakes, and best practices, MIS Quarterly Executive 6(2): 67–78. Orlikowski, W.J. (1996). Improvising Organizational Transformation over Time: A

situated change perspective, Information Systems Research 7(1): 63–92. Plant, R. and Willcocks, L. (2007). Critical Success Factors in International ERP

Implementations: A case research approach, Journal of Computer Information Systems 47(3): 60–70.

Petter, S., DeLone, W. and McLean, E. (2008). Measuring Information Systems

Success: Models, dimensions, measures, and interrelationships, European

Journal of Information Systems 17: 236–263. Peppard, J. and Ward, J. (2005). Unlocking Sustained Business Value from IT

Investments, California Management Review 10(4): 52–69. Peppard, J., Ward, J. and Daniel, E. (2007). Managing the Realization of

Business Benefits from IT Investments, MIS Quarterly Executive 6(1): 1–11. Pfeffer, J. and Sutton, R. (2000). The Knowing-Doing Gap: How Smart

Companies Turn Knowledge into Action, Boston, MA: Harvard Business

School Press.

Poon, P.P. and Wagner, C. (2001). Critical Success Factors Revisited: Success

and failure cases of information systems for senior executives, Decision

Support Systems 30(4): 393–418. Rademacher, R.A. (1989). Critical Factors for Systems Success, Journal of

Systems Management 19(June): 15–17.

Reymeni, D. and Sherwood-Smith, M. (1998). Business Benefits from

Information Systems through an Active Benefits Realization Programme,

International Journal of Project Management 16(2): 81–98. Reymeni, D. and Sherwood-Smith, M. (1999). Maximise Information Systems

Value by Continuous Participative Evaluation, Logistics Information Management 12(1/2): 145–156.

Remenyi, D., White, T. and Sherwood-Smith, M. (1997). Information

management: The Need for a post-modern approach. International Journal

of Information Management 17(1): 421–435.

Salmeron, J.L. and Herrero, I. (2005). An AHP-based Methodology to Rank

Critical Success Factors of Executive Information Systems, Computer

Standards & Interfaces 28(1): 1–12.

Sauer, C. (1993). Why Information Systems Fail: A case study approach, Henley:

Alfred Waller.

Sauer, C. and Davis, G.B. (2010). Information Systems Failure, in M.J. Bates

and M.N. Maack (eds.) Encyclopaedia of Library & Information Sciences,

New York: CRC Press, 3rd edn, pp. 2643–2652.

Sauer, C., Gemino, A. and Reich, H. (2007). The Impact of Size and

Volatility on it Project Performance, Communication of the ACM

50(11): 79–84.

Scandura, T.A. and Williams, E.A. (2000). Research Methodology in

Management: Current practices, trends and implications for future research,

Academy of Management Journal 43(6): 1248–1264. Serafeimidis, V. and Smithson, S. (2000). Information Systems Evaluation in

Practice: A case study of organizational change, Journal of Information

Technology 15(2): 93–105.

Shpilberg, D., Berez, S., Puryear, R. and Shah, S. (2007). Avoiding the

Alignment Trap in Information Technology, MIT Sloan Management

Review 49(1): 51–58.

Silverman, D. (2000). Doing Qualitative Research, Thousand Oaks, CA: Sage

Publications.

Somers, T.M. and Nelson, K. (2001). The Impact of Critical Success Factors

across the Stages of Enterprise Resource Planning Implementations, in

Proceedings of the 34th annual Hawaii International Conference on Systems

Sciences, Los Almitos, CA; Honolulu, Hawaii: IEEE Press.

Standish (2001). Extreme CHAOS, The Standish Group.

Thong, J.Y.L., Yap, C.S. and Raman, K. (1996). Top Management Support,

External Expertise and Information Systems Implementation in Small

Businesses, Information Systems Research 7(2): 248–267.

Tiwana, A. and Konsynski, B. (2010). Complementarities between

Organizational IT Architecture and Governance Structure, Information Systems Research 21(2): 288–304.

Walsham, G. (2002). Interpretive Case Studies in IS Research: Nature and

method, in M.D. Myers and D.E. Avison (eds.) Qualitative Research in

Information Systems, London: Sage Publications.

Wang, E.T.G., Shih, S.-P., Jiang, J.J. and Klein, G. (2008). The Consistency

among Facilitating Factors and ERP Implementation Success: A holistic view

of fit, Journal of Systems and Software 81: 1609–1621.

Ward, J. and Daniel, E. (2006). Benefits Management, Chichester, UK:

John Wiley & Sons.

Ward, J. and Elvin, R. (1999). A New Framework for Managing IT-enabled

Business Change, Information Systems Journal 9(3): 197–222.

Ward, J., Daniel, E. and Peppard, J. (2008). Building a Better Business Case for

IT Investments, MIS Quarterly Executive 7(1): 1–14.

Ward, J., Taylor, P. and Bond, P. (1996). Evaluation and the Realization of IS/IT

Benefits, European Journal of Information Systems 4: 214–225.

Weill, P. and Ross, J. (2005). A Matrixed Approach to Designing IT

Governance, Sloan Management Review 46(2): 26–34.

White, K.B. and Leifer, R. (1986). Information Systems Development

Success: Perspectives from the project team participants, MIS Quarterly

10(1): 215–223.

Willcocks, L. and Margetts, H. (1994). Risk Assessment and

Information Systems, European Journal of Information Systems 3(2):

127–138.

Yap, C.S., Soh, C. and Raman, K. (1992). Information Systems Success Factors

in Small Business, OMEGA 20(5): 597–609.

The successful realisation of benefits NF Doherty et al 14

About the authors Neil Doherty currently holds the Chair in Information Management in the Business School at Loughborough Univ- ersity. In addition to benefits management, his research interests include the interaction between organisational issues and technical factors in information systems development, understanding the reasons for failures of information systems projects, strategic information systems planning and E-commerce. Professor Doherty has had papers pub- lished in a range of academic journals, including: European Journal of Information Systems, Journal of Information Technology, Journal of Strategic Information Systems, Infor- mation Resources Management Journal, IEEE Transactions in Engineering Management, Journal of Business Research, European Journal of Marketing, Journal of End User Computing, Information Technology & People, Behaviour & IT and Information & Management. Doherty is currently an Associate Editor for Information Technology and People and the International Journal of Electronic Business Research.

Colin Ashurst is the FME Senior Teaching Fellow in Information Systems and Business Transformation in the Business School at the University of Durham. His research interests include IS strategy – identifying opportunities and priorities for IS investments; realising benefits from IS investments; succeeding with projects and programmes to deliver organisational change, particularly where business

innovation and change are significant; improving the pro- ductivity of knowledge work; and building the organisational capability to succeed in realising value from the IS investment portfolio. Dr. Ashurst has broad commercial experience from a range of IT management and consulting roles.

Joe Peppard holds the Chair in Information Systems at Cranfield School of Management where he is Director of the IT Leadership Programme. He is also Adjunct Professor at the University of South Australia. The focus of Professor Peppard’s research and teaching is on the area of information, systems and technology. Through his research he seeks to challenge dominant orthodoxies as he believes that these are contributing significantly to the problems that organisations have in leveraging information technol- ogies, both operationally and strategically, and ultimately in optimising the value delivered to the business. He has published widely in academic and general business and management journals. His books include Strategic Planning for Information Systems (Wiley) and Customer Relationship Management: Perspectives from the Marketplace (Butter- worth-Heinemann). In his consulting, Professor Peppard works closely with senior executives and Board members of large complex organisations in both public and private sectors advising them on IT and strategy-related matters and on how to unlock business value from their IT investments.

Table A1 Organisation A

ID Interviews

A01 Programme Manager – with responsibility for the overall programme in the SHA A02 Business Sponsor – Project 1 A03 Business Project Manager – Project 1 A04 Project Manager Projects 1&2 A05 Change Lead (two meetings) A06 SHA business lead A07 Project Manager A08 Regional Benefits lead A09 GP – an end user (2 meetings) A10 GP – an end user A11 Business Sponsor & project manager – project 2 A12 Business Sponsor Project 1 A13 SHA Benefits lead (2 meetings) A14 Benefits team member

Observational events A15e Planning workshop for the SHA benefits strategy (approximately six attendees) A16e Planning for benefits community workshop (approximately six attendees) A17e Benefits community workshops (fifty attendees) A18e Benefits community workshops (twenty-five attendees)

Follow-up and validation meetings On completion of fieldwork Separate meetings to discuss the preliminary findings were held with:–

K A13 K A06 K A11 K A13

Appendix

The roles of case organisation interviewees

The successful realisation of benefits NF Doherty et al 15

Table A2 Organisation B

ID Interviewee

B01 IT Director B02 Deputy Dean B03 Registrar B04 Deputy IT Director B04 IT Manager B05 Admissions Manager B06 Marketing Manager B07 Professor 1 B08 Professor 2 B09 Professor 3 B10 Academic 1 B11 Academic 2 B12 Academic 3 B13 Operations Director B14 Dean B15 Deputy Dean (new) B16 e-learning – Manager B17 e-learning – team member

Observational events B18e e-learning – briefing on new developments B19e University IT strategy meeting (�2) B20e University IT Users Committee B21e Business School – meetings to develop IS strategy and monitor progress of initiatives (�6) B22e CRM project planning meetings (�3) B23e Distance Learning working party meeting to explore the role of IS and development of the programme

(�4)

Follow-up and validation meetings On completion of fieldwork

Separate meetings to discuss and validate the preliminary findings were held with:– K B01 K B13

Table A3 Organisation C

ID Interviewee

C01 Director of business division (including IT) & sponsor of the Transformation Programme (two meetings) C02 IT Director and project manager for thin client desktop (plus email follow up) C03 HR/Payroll project sponsor (Director of Organisational Development) C04 HR/Payroll project manager – a member of the transformation team responsible for the overall project

(business and IT) C05 Customer Services Manager and sponsor for the CRM programme C06 Customer Services Operations Manager C07 Customer Services Supervisor C08 IT project manager for the CRM project C09 Customer Services Assistant

Observational events C11e Tour of Customer Services Centre C12e Informal discussions with Customer Services staff C13e Attendance at leadership Forum event – presentation of lessons learned from Transformation

Programme (C10) C14e Informal discussion with member of Transformation Programme team

Follow-up and validation meetings On completion of fieldwork

Separate meetings to discuss and validate the preliminary findings were held with:– K C01 K C10

The successful realisation of benefits NF Doherty et al 16

Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.