Introduction

The quote by Brennan (2005) in the title of this paper neatly captures the underlying mindset that appears to be driving the 'The National Programme for Information Technology' (NPfIT) in the UK. In this project, there is a strong emphasis on developing and implementing a large set of IT systems. In time, the intent is that these systems will provide the technical infrastructure enabling NHS staff to deliver better care to patients. But, at least for now, the focus is on delivering the IT. This is where the budget is spent. This is what is project managed. This is what companies and people are hired to do and rewarded for doing. Put simply, this is (at present) a technology project, and indeed this is reflected in its title.

We believe this 'techno-centric mindset' may be misguided, and flies in the face of lessons learned from research and practice over the last 20 or so years. While it may be the biggest programme ever, we have doubts that this is a useful way of looking upon it. Put bluntly, we question whether the current strategy is the most appropriate way forward to achieve successful service improvements.

The overall aim of this essay is to offer a commentary on the NPfIT. We begin by briefly introducing the programme. Next, we elaborate the lessons learned from the fields of new technology and business change and spell out their potential implications for the project. In so doing, we critique what appears to be the underlying mindset and offer an alternative view, with some potential ideas for change.

Three further sets of comments help provide an orientation for this essay. First, for convenience and consistency, we will refer to the project using the title 'NPfIT'. This is consistent with the terminology used by Connecting for Health, the agency of the Department of Health formed to deliver this programme of work. We return to the issue of labelling later in the paper.

Second, we make no claim to be technical experts in IT. We are psychologists and our interest and expertise lies in the psychological and organizational aspects of new system design, implementation and use. Our competence is in the wider field of IT and business change projects. This is an area where there has been a great deal of research and practice over the last two decades or more, and we believe the lessons learned have valid application in the health service.

Third, we believe that social scientists (like us) need to be braver professionally than we often are. We acknowledge that, as social scientists, we spend large proportions of our time investigating empirically how new systems operate and perform, and making recommendations for improvement. This has the advantage that the work is grounded in valid and reliable methodologies and at the same time adds social value. But the downside is that the findings arrive after the event. It can take several years by the time empirical work has been undertaken, and the data analysed, interpreted and reported. We believe there is a further role for social scientists in undertaking predictive work as new systems and phenomena emerge, of course with the proviso that such predictions should have some basis in theory and practice. We should be clear, we are not arguing against the traditional role of social science to conduct empirical studies, rather that this 'normal activity' should be supplemented by more predictive work. Our ambition is that such predictions may provoke timely debate.

We can see no reason in principle why the lessons of the last 20 years of experience with IT and business change projects should not be applied to the NHS and we are happy to debate their relevance. As such this paper focuses on the lessons from elsewhere and their potential application to the health service.

The paper is structured in the following sections:

• A brief introduction to the NpfIT.
• A set of lessons learned from elsewhere.
• Comments on why changes of this kind are likely to be harder within the NHS than in most other organizations.
• Discussion of the implications of these ideas and actions for consideration.

The NPfIT

Established in October 2002, the NPfIT is a 10-year change programme costing around £2.4 billion (House of Commons Committee of Public Accounts, 2007). Overall governance and accountability for the programme is provided by the UK Department of Health. In April 2005, a new agency of the Department of Health called 'Connecting for Health' was formed to deliver the programme. At national level, responsibility for procurement, the development of the IT systems, and coordination of the implementation activities resides with 'The Central National Programme Team'. This team liaises with national service providers (BT, Cable & Wireless and Atos Origin) who are accountable for IT networking and support services across the UK. Owing to the complexity of the NHS, the implementation activities have been split into five geographical clusters (London, Southern Cluster, Eastern Cluster, North West & West Midlands Cluster and North East Cluster). Regional implementation directors have been appointed to lead the programme in each cluster, which comprise between five and seven strategic health authorities. These strategic health authorities work with the Central National Programme Team, other NHS organizations (e.g., local NHS trusts, primary care trusts, primary care organizations) and local service providers (CSC Alliance, The Fujitsu Alliance, BT Capital Care Alliance and Accenture¹) to deliver implementation at a local level.

The overarching 'vision' of the NPfIT is described as 'delivering better care' to patients, by equipping NHS staff with a suite of new information technologies designed to provide them with the latest information at their fingertips (Connecting for Health, 2005). These technologies include: (1) An electronic 'NHS Care Records Service' (NHS CRS) designed to improve the sharing of patients' records across the NHS; (2) 'Choose and Book', an electronic booking service developed to make it easier for patients in GP clinics to book hospital appointments; (3) An 'Electronic Transmission of Prescriptions' service (ETP); (4) A 'National Network', providing the IT infrastructure, network services and broadband connectivity; (5) 'Contact', an NHS email and directory service to enable the secure transmission of patient information; (6) 'Picture Archiving and Communication Systems' (PACS) to capture and distribute X-rays, scans and other digital images; (7) The 'Quality Management and Analysis System' (QMAS) designed to provide GP practices with feedback on their quality of patient care; (8) 'Healthspace', an online personal health organizer to enable patients to record information they feel may be relevant for health professionals such as height, weight, blood group, allergies, medications and food preferences (see Healthspace, website); and (9) 'NHS.uk', a website accessible to both patients and NHS staff with over 200,000 pages of information (see NHS England website).

In this paper, we argue that the vision of 'delivering better care' is at risk of being compromised by the technology-oriented approach within the NPfIT. The key assumption underpinning this approach is that the initial effort needs to focus on putting in place the underlying technical systems and infrastructure, and that the necessary organizational changes can be designed and implemented later. When both are in place, this will enable the provision of improved care and a range of benefits for both staff and patients. We believe this strategy reflects an underlying 'techno-centric mindset'. This is exemplified in the official guide to the NPfIT, which describes the implementation process as 'Bringing in the IT' (Connecting for Health, 2005). In the following section, we offer a set of lessons learned from the field of new technology and business change. This includes an explanation of why a techno-centric approach is unlikely to deliver successfully the anticipated organizational benefits.

A set of lessons learned

Our summary draws on four primary sources, an expert panel conducted in the 1990s (Clegg et al., 1997), a recent report on 'The Challenges of Complex IT Projects' prepared jointly by the Royal Academy of Engineering and the British Computer Society (2004), the wider literatures on IT and business change projects, and our own personal experiences of working with a range of organizations, practitioners and researchers.

Below we summarize six main lessons in turn, before illustrating their meaning in two brief case examples.

Performance

In his introduction to the report on 'The Challenges of Complex IT Projects' by the Royal Academy of Engineering and the British Computer Society, the chairman of the study team reported that 'a mere 16% of IT projects can be considered successful' (2004: 8). The evidence from economic analyses, case studies, public enquiries, expert panels, professional bodies, surveys and user experiences are consistent. Whatever the level of analysis (macro through to micro), the discipline (engineering through to social science) or the method of investigation (survey through to case study), the key lesson is clear – IT systems often fail to deliver against their objectives and often disappoint their users and sponsors. (See for example, Landauer, 1995; Clegg et al, 1997; Gibbs, 1997; Brynjolfsson and Hilt, 1998; Norman, 1998).

Our summary is that around 40% of such investments are complete failures, around 40% are partial successes (meeting some of their objectives), and up to 20% can be counted as complete successes.

Unsurprisingly this has been a hotly debated topic by economists in particular. In 1987 Robert Solow phrased what came to be known as the Solow paradox, that is, that 'you can see the computer age everywhere, except in the productivity statistics' (Solow, 1987). Some economists believe that productivity data are now reflecting investments in IT, especially in the USA over the last 5 years, and in part this results when companies also adopt new organization structures and processes (e.g., see Draka et al., 2006; Kling, 2006).

In the remaining lessons learned below, we try to summarize what we believe are some of the main reasons for the failures and successes of IT projects, with particular focus on the organizational issues.

Need

A major issue is concerned with whether or not the business really needs the new IT system that is being developed (Clegg, 2000). This core concern can be phrased in a number of different ways. For example: Do we really need the new system? Is this investment the best use of our resources (i.e., bearing in mind the opportunity costs)? Does the new system further our business goals? Is the business case strong and valid? Will this new system help our staff deliver a better service?

Unfortunately, we have all witnessed significant IT investments which do not meet these criteria very well. And, if these are not met, then however good the design and the implementation, it is hard to see how the investment can be effective. There can be several underlying problems here, and one major one is concerned with the lack of understanding that often exists between the IT community and senior managers, and the ways in which the broader business community has allowed the IT community to arrogate ownership of the IT domain. We return to these issues later in this essay.

A systems view

One overwhelming lesson emerging over the last 20 or more years has been the need to apply systems thinking to the domain of IT, both in a general sense and, more specifically, using the principles of socio-technical systems theory (see e.g., Cherns, 1987; McLoughlin and Harris, 1997; Checkland, 1999). In this perspective, organizations are made up of people with various competencies and motivations, pursuing sets of goals, organized in various structures and roles, using certain working practices and job designs, working within local, professional and national cultures, and using various technological systems (including IT). All these elements are in a state of dynamic interplay. In particular, the technical systems interact with, and are co-dependant on, the social (and organizational) systems. Rather than optimize one of these elements, successful system outcomes require their joint consideration and optimization. While this is very abstract, there are two logical lessons arising (in this context).

First, the introduction of a new IT system will require changes elsewhere in the organization (e.g., see Alter, 2006). Thus companies may need to change the processes they use (perhaps to make them more streamlined and simple), the working practices, the roles of the users, their skills and competencies, and/or the relationships between different professional groups. Back in the 1980s and 1990s, experts in manufacturing (such as Ingersoll Engineering) used to say 'if you automate a mess, all you get is an automated mess'. In other words, companies need to get their organization right first, and only then think of computerization. We note the reverse logic also holds – thus, if we wish to improve business processes and working practices, this may need the support of some new IT systems.

The second corollary is that no single discipline or professional group is likely to be able to provide a complete understanding of the overall system. The line managers, service deliverers and human resource people are unlikely to understand the IT and what it can do for them, while the IT people are unlikely to understand how the organization and the people in it actually work, and could work in the future, to deliver the service. In this perspective, any change programme will require the inclusion of all the necessary forms of expertise and should not be limited to, or indeed led by, IT, an issue to which we turn below.

We wish to stress a further point. Unsurprisingly, some parts of the IT community, especially those responsible for leading and managing major projects, often find such messages difficult. This is, in our view, understandable. From their perspective, we are trying to sell them additional problems and difficulties when they are already up to their necks in alligators and bullets. To ask them to think of added complexities (such as the design and implementation of new working practices, business processes, organizational structures and roles) is not what they need. Typically, they are fully challenged by the needs of a complex IT project, often as in this case, in a very differentiated and political organizational context. In essence, we end up trying to sell more problems to a community that is not trained in these issues, is not expected to resolve them, is not qualified to do so and is not rewarded for doing so. At its very baldest, they often see their job as getting the kit on the desks 'on time' and 'in budget'. But we should acknowledge that the wider business community has been largely complicit in the emergence of that role and the accompanying techno-centric mindset.

Ownership

A further strong lesson focuses on ownership. Under the initial banner of business process re-engineering, a great deal of work in the 1990s established that we should not put artificial boundaries into processes (see e.g., Hammer and Champy, 1993). Thus we shouldn't split assembly work from testing, or design from manufacture. These are logically connected processes and should be organized and managed as seamlessly as possible and without artificial organizational boundaries. For example, having different groups of employees (each with different supervision and management) responsible for assembling a product from those testing it, creates plenty of scope for conflict and poor opportunities for learning and improvement.

Indeed, there have been successful instances of business process re-engineering within the NHS in the UK. For example, Bevan (1996) describes how work in neurology and hearing departments in Leicester Royal Infirmary was reorganized so that patients could be examined, have tests, receive results, have consultations with the Doctors and other staff as necessary, and begin treatment, all within one visit to the hospital, rather then involving several visits spread over several months.

Furthermore, pull systems (whereby end customers pull products through a supply process) have proved to be much more effective than push systems (whereby products are pushed at their users) (e.g., see Goldratt and Cox, 1984).

We strongly believe the same logic applies to change programmes. Our experience is that change programmes led by IT suppliers and designers, who design a system, and then push it at its end users, are often ineffective. Handing over a new system to a group of users, and then telling them to get on with it, is unlikely deliver service benefits.

Rather, from the beginning, the end user community needs to own the change programme and pull through what it wants and needs for effective performance (Clegg and Walsh, 2004). In this perspective, the IT community is one, albeit important, part of the design process and the design team. But it doesn't own, it doesn't lead, it doesn't push and it doesn't simply hand over a system for someone else to use.

Project management

The lessons above come together in the domain of project management. In this perspective, projects are owned, led and managed by senior end users. Project teams are multi-disciplinary and include all the necessary skills to improve the work system. They focus on a working system and how the service will be delivered (i.e., including the design of new processes, working practices and roles). The role of the IT function is to support and provide professional input to the work (along with other specialists). Large projects may need to be chunked up in some way, for example using local pilot schemes so that lessons can be learned along the way.

The logical corollary is that such projects are not about IT. They are about designing new and more effective ways of delivering a service. A further key point is that the metrics which are used to monitor and evaluate progress should reflect this orientation, and we return to this issue later.

Senior management

It will be clear by now that these lessons involve a fundamental change in how we view change management projects and the role of IT. This requires fundamental changes in underlying mindsets, for senior managers in particular. Local managers and most end users are unlikely to have the power to enact changes of this order.

The views above are rather abstract. To illustrate what they mean in practice we describe two brief case examples of their use in two large UK organizations.

Case 1 – Lyons Confectionery

Lyons Confectionery make and deliver cakes to retail outlets throughout the UK, ranging from small corner shops to major supermarkets. Drivers call on the shops and deliver the company's products according to set delivery rounds. The Sales Director responsible for field sales decided he wanted to improve sales, the quality of information, and control over the process. He decided to adopt a system comprising hand-held computers for use by the delivery drivers. On these machines the drivers would be able to enter existing stock levels, amounts delivered and on-going sales, and the data would be downloaded at their depot at the end of each working day. This information was then immediately available to sales, accounts and manufacturing. The project was led and driven by the Sales Director. He involved a sample of drivers and depot managers, along with staff from sales, accounts, manufacturing and IT. He managed a process through which all the stakeholders were involved and where their needs were met. In this process, the IT manager was one key member of the team. But the project was owned and led by the senior end user who pulled the system he needed into his business. The project adopted a systems view and incorporated consideration of business processes, working practices, roles, skills and IT (Clegg and Walsh, 2004). This was one of the most successful change projects we have witnessed.

Case 2 – A manufacturing company

This company was a major manufacturer and user of IT systems in the UK. Previously they managed their internal IT projects in a traditional way. The project manager was always a senior IT manager who would get together a team of specialists to design a new system. This team might include some end users and some time would be spent in 'capturing' end user requirements. However, the bulk of the expertise, time, money and effort was expended on IT issues. They usually started as and/or became IT projects. Once the new IT system was designed it would be handed over to the appropriate line manager who would be responsible for its operation and effectiveness. The result was often disappointing. As such the company decided to adopt a new way of thinking about and managing such projects.

They decided that for any major change project, the line manager who was to become the recipient of some new technology and way of working, would become the project manager responsible for its design and implementation. If for any reason this was not possible, then the project manager would remain with the change after its implementation and thereby become responsible for its use and effectiveness in operation. The project manager would become the line manager living with the consequences of the new system. This strategy of continuity of responsibility and ownership immediately made the individuals conscious of how the system would work, the local working practices, the impact on users, and a host of business change issues. This change in ownership led to the adoption of a systems view and proved to be the single most important change in how the company managed major projects (see Clegg and Walsh, 2004).

We must offer some caveats about the views above. We fully accept that others would summarize their versions of 'lessons learned' in different ways. We acknowledge there will be differences in emphasis, in labelling and in presentation. But, those comments notwithstanding, we do believe such summaries are worthwhile, using them as a professional lens through which we can take a different look at (in this case) the NPfIT.

Why it is likely to be harder within the NHS

It is clear from the above that successful change in this area is difficult and that rates of success are disappointingly low. The prospects for large-scale projects are daunting enough. In our view, however, it is likely to be significantly harder within the UK NHS than in most organizations, and this for a number of reasons.

First, it has been acknowledged that public sector projects face specific difficulties, including 'their high visibility, the risk averse culture of the civil service, the need to meet politically-driven timescales and in many cases, their enormous scale and complexity' (Royal Academy of Engineering and British Computer Society, 2004). The external environment surrounding the NPfIT is certainly politically charged, with the NHS being a central part of the government's change agenda. Such high visibility and high stakes are likely to make change more difficult to manage. The NHS is also a very large organization. It employs in excess of 1 million people, making it the third largest workforce in the world after the Chinese Red Army and the Indian Railway (Berry, 2004). Moreover, it is inevitably a highly differentiated environment, comprising many groups with strong professional and historical allegiances and different normative frameworks which underpin healthcare practice (Currie and Guah, 2007, in press). Internally, this can be seen as a political environment where powerful groups are vying for status, power and reward. Change in such environments is notoriously difficult.

Second, there may well be doubts over the competencies and experience within the NHS of managing changes of this kind and on this scale. One can reasonably question – Is there a track record of effective change management? Of introducing complex IT systems? Of managing the necessary organizational changes? Of learning the lessons from elsewhere? In part these difficulties are compounded by the range and scope of initiatives being undertaken within the NHS (House of Commons Committee of Public Accounts, 2007).

Third, we believe it likely that change is harder to manage in the NHS because there is no single performance metric (or set of metrics) around which everyone can coordinate their efforts and which can be used to provide coherence. In contrast, in manufacturing companies for example, indices concerned with profit, return on investment and productivity can be used in major change projects. Clearly, these are not without their difficulties, and this is not to argue that the NHS is alone in facing differentiation and political processes. Rather, we simply make the point that performance and its measurement is likely to present greater difficulties in the NHS than in most organizations.

And fourth, the nature of the IT and service delivery systems add complexity simply because they serve to cut across professional groups, existing organizational boundaries, and geographical locations.

In our view these factors come together to make the management of change harder for the NHS than for most other organizations. Recall too that the rates of success for IT implementations generally are not high. In that light, we should perhaps be sceptical of the chances of success with this new system.

Implications

In this section, we consider what we believe are the major implications of our analysis of the lessons learned from elsewhere. We elaborate three main sets of issues concerned with:

• Understanding;
• The NPfIT as a 'technical infrastructure project';
• Actions for consideration.

Understanding

First, our interpretation is that these lessons from the wider field of IT and business change help:

• Demonstrate that what we should be doing is designing and implementing new ways of working (recognizing that such changes are very often enabled by IT systems).
• Substantiate the argument that technology is one (albeit very important) part of the problem and solution.
• Elaborate the corollary that it is not possible for a single discipline or profession to have all the answers – these are systemic problems and opportunities.
• Counter two widespread problems in this field generally, that is,
  •  The false optimism that often exists whereby organizations aspire to achieve unrealistic improvements in performance through IT projects.
  •  The predominant techno-centric approaches to change.
• Demonstrate how difficult it is to design and implement new working systems.
• Explain some of the major reasons underlying the poor success rates for IT projects.

The NPfIT as a 'technical infrastructure project'

Much emphasis in the NPfIT is placed on the need to put in place technical systems and a technical infrastructure. In our view this is a seductively plausible approach. It carries with it several distinct advantages for the project management team. In particular, it reduces the size and complexity of the problem. It serves to focus on the IT and related matters and to exclude (at least for now) some very difficult organizational issues concerning the redesign of working practices, processes and roles. The main task becomes that of 'Bringing in the IT' and this can be interpreted as primarily a technical issue needing strong project management (because of its size and complexity). The team can thereby leave the other parts of the problem to others and to a later agenda, probably to be funded in a different project. We interpret this as a classic complexity-reduction strategy.

This separation of the technical (to be dealt with now) and the social issues (to be dealt with later) can also be construed as a useful rhetorical device for legitimizing a techno-centric approach. While the sponsors and developers confirm that the end game is to provide a system which supports a new set of working practices which will provide a better service, to facilitate this, in the short term, the technology must be put in place.

Confirmation of the validity of these concerns is provided by the recent review of the programme as conducted by the Public Accounts Committee of the House of Commons. Three of the main conclusions and recommendations of their report are quoted below: We are concerned that leadership of the Programme has focused too narrowly on the delivery of the IT systems, at the expense of proper consideration of how best to use IT within a broader process of business change (House of Commons Committee of Public Accounts, 2007: 6). The Department needs to improve the way it communicates with NHS staff, especially clinicians. .... It should ask the heads of the clinical professions, such as the Chief Medical Officer, to review the extent of clinical involvement in the specification of the systems, and to report on whether they are satisfied that the systems have been adequately specified to meet the needs of clinicians (op. cit.: p. 6). At the present rate of progress it is unlikely that significant clinical benefits will be delivered by the end of the contract period (op. cit: p. 6).

We stress that two alternatives to the prevalent techno-centric approach to change are possible. The project could have designed the social system first, designing the organizational processes and working practices that are required, streamlining and simplifying them where necessary, and then developing a set of IT systems to support the new ways of working. Or indeed, the project could have attempted to deal with both sets of issues at the same time (i.e., according to a classic 'sociotechnical' perspective). Either of these choices would have required a different approach, for example with different targets, metrics and project team membership.

Neither of these alternatives appears to have been adopted. From its inception this appears to have been framed as an IT project, staffed by IT experts, owned and led by IT specialists and comprising IT delivery work packages and contracts. It has become a classic IT project.

Of course, this is not unusual in the context of large change programmes. For example, the past 15 years have witnessed the phenomenal uptake of Enterprise Resource Planning (ERP) systems, with 70% of Fortune 1000 companies implementing them in some form (Shepherd, 2006). ERP systems are marketed as an opportunity to replace differentiated legacy systems, with a single system comprising integrated software modules designed to manage all of an enterprise's data and business processes. However, despite the high expectations that usually accompany their implementation, projects are, on average, 178% over budget, take two and a half times as long as intended and deliver only about 30% of their promised benefit (Krumbholz et al., 2000).

In response to these problems, some researchers have argued for 'vanilla' ERP implementations, where organizations re-engineer their business processes to fit the technology (e.g., Parr and Shanks, 2000). However, this techno-centric approach, where the technology becomes the determinant of process change, is at odds with Hammer and Champy's original conception of IT as a critical enabler (see Willcocks and Grint, 1997). Furthermore, evidence suggests that technology-led ERP projects, which adopt the processes embedded within the software, result in gaps in the required functionality (Scott and Kaindl, 2000) and do not necessarily deliver organizational benefits (Laursen and Myers, 1999).

Returning to the current emphasis within the NPfIT on the technology, there are some important pros and cons to this approach and we think these need careful elaboration.

Pros

We list here what we see as the major advantages of the current emphasis on the provision of technical systems:

• It simplifies the goals and the scope of the problem domain. It allows people to focus on a limited set of problems (equivalent to the classic problem of 'getting kit on desks'). It also helps make responsibilities clear.
• Initially it may well speed up the process since difficult decisions about the provision of service delivery through organizational changes can be made later once the technical systems are in place.
• It is what professional project managers often do – that is, they manage IT projects. As such they can draw on a wealth of previous experience. It fits the brief people were usually hired to undertake. If the underlying mindset, thinking and language are about IT, then we hire IT people to do IT. That is what they then do – we should not be surprised!
• It may also help get the developers off the hook later. In this logic, if overall service delivery is not improved, then it isn't the developers' fault. They can claim they gave the user community the infrastructure that the users said they wanted (because they did the necessary requirements capture). The users either don't or won't use it. Blame the end users. The developers can claim they met their contractual obligations.
• This may well be the only way this can be done. Because the health service is so big, so complex and so differentiated, it would take forever to get the various end-user communities to lead and agree a project of this kind. As such the IT is used as a Trojan horse to force through some changes in working practices and processes.

We note, in passing, that with the exception of the last point, all the above represent direct advantages for the project team and the IT community, and none can be construed as significant advantages for the end-user community or their clients (the patients).

Cons

We list here what seem to us the major disadvantages of the existing mindset and approach.

• This approach and the underlying mindset focus the project thus far almost exclusively on the technology. Given there is a long history of failed technology-driven projects, this seems to us a high-risk strategy.
• A further risk arises in that it is not clear how the developing infrastructure will shape and influence subsequent processes and working practices. Thus it may be that the new infrastructure provides excellent support for a new streamlined and optimal set of processes. But it may not. Has the work been done in matching the technical and social arrangements?
• Furthermore, the delay in dealing with the organizational aspects of the system means that these aspects may not get funded or managed, let alone optimized. Psychologically it keeps the two worlds apart – it reduces the chances of joined-up thinking. And it reduces the chances of improved services. In particular, how, in the current project configuration, will this project get to a set of working practices, processes and role designs that will deliver service improvements? Who will be responsible for designing and implementing the new working arrangements? How will these changes be funded and resourced? Organizational changes of this kind do not occur spontaneously, even in small and relative simple organizations. They certainly will not occur spontaneously in something as complex as the NHS.
• There is the danger that the longer term outcome is a mish-mash of relatively unplanned variations in how such services are delivered using the underlying IT systems. These are unlikely to be optimal.
• There is the danger that the users of the new systems become disillusioned. For example, in a recent online survey of 3092 doctors undertaken for, and reported in, The Times newspaper, 91% of doctors responded 'No' to the question – 'Do you think the new computer system will improve the NHS?' (Hawkes, 2007). Similarly, a survey of 4451 nurses undertaken on behalf of the Royal College of Nursing found that only 56% of nurses thought The NPfIT (in particular the care records service) would improve the level of clinical care, and just 49% thought it would improve their working life (Royal College of Nursing, 2006).
• Overall, it seems to us that this project does not match well with the lessons learned from 20 years experience of IT and business change projects. It makes us sceptical that the new system will deliver the anticipated benefits and thereby provide a reasonable return on what, in any language, must be seen as a significant national investment.

Finally, we note here that the disadvantages identified above seem likely to be experienced by the end user and wider community (as opposed to the developers). Thus we appear to be in a position where the advantages of the existing approach appear to accrue to the IT project team (see above), while the disadvantages appear to accrue mainly to the end users of the service. This seems to us a poor recipe for successful change.

Actions for consideration

In this section, we try to identify the kinds of action that follow from the alternative mindset and approach we have elaborated based on our interpretation of lessons learned. We believe these ideas may help improve the chances of success of this project and are thereby worthy of serious consideration.

A new mindset?

There's no such thing as an IT project, merely business change projects mediated by people and ICT (Norton, 2006).

This quote from Professor Jim Norton captures an alternative perspective to the one that appears to be driving and dominating the NPfIT. It is a view entirely consistent with the lessons learned above. In this view we should not be focusing on the IT. Rather, we should be concerned with service delivery and how that can be improved through changes to working practices, business processes and work organization. These are likely to need streamlining and simplifying and to be enabled and supported by IT. (See also the recent report by the British Computer Society Health and Informatics Forum, 2006.)

Above all then, we should consider adopting a new mindset. Such a service delivery project requires a systemic approach. It is about developing new ways of working, processes, roles, structures and IT. We note in passing that it might help signal a change in thinking if the labelling for the project was changed and if we moved on from calling it 'The National Programme for IT'. Why not a National Programme for Service Delivery?

Leadership and ownership

The provision of improved services (and thereby this project) needs to be owned and led by senior end-users, who need to be pulling through the new working practices that they need to deliver better services. The IT community needs to work with the end-user communities to deliver what they want and what they need to support the new working arrangements. These responsibilities lie with senior end users who need to take ownership of these projects. The logical corollary is that the project team membership should be multi-disciplinary, including all the forms of expertise and experience necessary to design and deliver effective systems of patient care.

There is a further point. We argued in the final bullet point under the Pros associated with the existing approach, that one justification for framing this as an IT project could be made using the argument that the end user communities are so large and differentiated that it would take them too long to get their act together to lead and organize a new working system. We are not expert enough in the NHS and its working to assess how reasonable might be this view. But it does seem fundamentally depressing. However, if true, the implication is surely not that we spend billions of pounds on a new IT system that seems at risk of failing to deliver the promised benefits. Rather we should be spending time and energy in understanding and changing how we structure and organize service delivery.

New metrics

In parallel with a change in underlying mindset, leadership and ownership, we may well need to establish a new set of performance metrics to guide the project. Neely et al. (1995) have criticized performance measurement systems in manufacturing on a number of grounds, including: (1) the lack of a balanced approach (focusing too much on cost and time indicators, rather than quality, responsiveness and flexibility); (2) the emphasis on short-term thinking and focus; (3) the lack of systems thinking; and, (4) the lack of connection with strategy. Arguably, all of these criticisms can be leveled at classic techno-centric IT projects. For example, the performance of IT suppliers is measured against their ability to deliver on budget and on time – these are the central criteria on which they are judged. In the short term these are considered more important than quality, which is not systematically evaluated. We note too that the key metrics here are about the IT and not about service delivery. Again, if the underlying mindset is about IT, then people are usually managed and chased using IT related metrics. And of course, given the widespread failure of IT projects, this is often done very aggressively.

The underlying point here is that people are often strongly driven in their behaviours and priorities by the metrics that are used to evaluate and manage them. In a recent article in The Times newspaper, the practice lead for Fujitsu (one of the three local service providers for the NPfIT) argues for the need to refocus on the vision of the NPfIT, lamenting that 'short term challenges have distracted us from the goal' and that 'the project is heading towards an IT upgrade' (Rollerson, 2007). If the strategic goal of the NPfIT is to put a new technical infrastructure in place then evaluating suppliers' performance against cost and time metrics would make sense. However, if the strategic vision remains the delivery of better patient care, then a more balanced performance measurement system is required, incorporating new metrics that fit this new mindset for the project. Thus, for example, if the project is about providing new working practices and processes to enable improved service delivery, then the metrics should include the performance of the practices and processes, along with the quality, timing and costs of service delivery.

Reflect and plan

In the immediate future we believe senior user managers in the NHS need to ask some simple but challenging questions, reflect on the answers, and then put plans in place to act upon the results. Some major questions are presented in Table 1. Of course, these are not the only questions they need to consider, but we think these are some of the key ones that can be used to identify and drive immediate actions.

Table 1 - Questions that senior user managers need to ask and act upon.

Full table

Concluding remarks

We have summarized what we believe are the major lessons learned from a wide range of experience in the field of IT and business change. We have written these from a psychological and organizational perspective (as social scientists). It does not appear that the NPfIT matches up well against these ideas and as such we are sceptical of the chances of success for this project. Above all, the existing mindset reveals an inappropriate focus on this as an IT project. It was almost certainly framed in this way from the beginning.

We should add that we do not attach any particular blame for this to the current key actors in this project. Put very crudely, if you start with something defined as a 'plumbing problem', then hire some plumbers, then measure and reward them for plumbing work, we should not blame them when they plumb.

In our view a new mindset is worthy of serious consideration, involving an emphasis on designing and implementing new working systems capable of improved service delivery. In this new view, the project needs to be owned and led by senior end users. This new approach would entail a change in mindset, leadership, ownership, metrics and labelling.

Notes

¹ Accenture pulled out of the programme on the 28th of September 2006.

References

1. Alter, S. (2006). The Work System Method: Connecting People, Processes and IT for Business Results, Larkspur, CA: Work System Press.
2. Berry, M. (2004). Facing NHS Problems Head-on, Personnel Today [WWW document] http://www.personneltoday.com/Articles/2004/08/10/25041/facing-nhs-problems-head-on.html (accessed 6th April 2007).
3. Bevan, H. (1996). Managing Today while Creating Tomorrow: The paradox of a re-engineering journey. Working article HWP 9630, Henley Management Group, Henley, UK.
4. Brennan, S. (2005). The NHS IT Project: The Biggest Computer Programme in the World...Ever', Oxford: Radcliffe Publishing Ltd.
5. British Computer Society Health Informatics Forum (2006). The Way Forward for NHS Health Informatics, London: British Computer Society.
6. Brynjolfsson, E. and Hilt, L.M. (1998). Beyond the Productivity Paradox, Communications of the ACM 41(8): 49–55. | Article | ISI |
7. Checkland, P. (1999). Systems Thinking, Systems Practice: Includes a 30 year Retrospective, Chichester: John Wiley & Sons.
8. Cherns, A. (1987). Principles of Socio-technical Design Revisited, Human Relations 40: 153–162. | Article | ISI |
9. Clegg, C.W. (2000). Sociotechnical Principles for System Design, Applied Ergonomics 31: 463–477. | Article | PubMed | ISI | ChemPort |
10. Clegg, C.W., Axtell, C., Damodaran, L., Farbey, B., Hull, R., LloydJones, 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. | Article | ISI |
11. Clegg, C.W. and Walsh, S. (2004). Change Management: Time for a change? European Journal of Work and Organizational Psychology 13(2): 217–239. | Article |
12. Connecting for Health (2005). A Guide to the National Programme for Information Technology [PDF document] http://www.connectingforhealth.nhs.uk/publications/brochures/npfit_brochure_ap_05_final.pdf (accessed 6th April 2007).
13. Currie, W.L. and Guah, M.W. (2007). A National Program for IT in the Organizational Field of Healthcare: A example of conflicting institutional logics, Journal of Information Technology 22(3), in press.
14. Draka, M., Sadun, R. and Van Reenen, J. (2006). Productivity and ICT: A review of the evidence. Discussion paper No. 749, Centre for Economic Performance, London School of Economics, London.
15. Goldratt, E.M. and Cox, J. (1984). The Goal. New York: North River Press.
16. Gibbs, W.W. (1997). Taking Computers to Task, Scientific American 277(July): 64–71.
17. Hammer, M. and Champy, J. (1993). Re-engineering the Corporation: A Manifesto for Business Revolution. London: Nicholas Brierley Publishing.
18. Hawkes, N. (2007). Disillusioned Doctors Say Labour Decade of Reform has Failed NHS, The Times. 19th February [WWW document] http://www.timesonline.co.uk/tol/news/uk/health/article1403738.ece (accessed 6th April 2007).
19. Healthspace, [WWW document] https://www.healthspace.nhs.uk/ (accessed 6th April 2007).
20. House of Commons Committee of Public Accounts (2007). Department of Health: The National Programme for IT in the NHS, London: The Stationery Office Ltd.
21. Kling, A. (2006). Solow Paradox Revisited. [WWW document] http://econlog.econlib.org/archives/2006/01/solow_paradox_r.html (accessed 09.04.2007).
22. Krumbholz, M., Galliers, J., Coulianos, N. and Maiden, N.A.M. (2000). Implementing Enterprise Resource Planning Packages in Different Corporate and National Cultures, Journal of Information Technology 15(4): 267–279. | Article | ISI |
23. Landauer, T.K. (1995). The Trouble With Computers, Cambridge, MA: MIT Press.
24. Laursen, M.A. and Myers, M.D. (1999). When Success Turns into Failure: A package driven business process re-engineering project in the financial services industry, Journal of Strategic Information Systems 8: 395–417. | Article |
25. McLoughlin, I. and Harris, M. (1997). Innovation, Organizational Change and Technology, London: International Thomson Business Press.
26. NHS England, [WWW document] www.nhs.uk (accessed 6th April 2007).
27. Neely, A., Gregory, M. and Platts, K. (1995). Performance Measurement Systems Design: A Literature Review and Research Agenda, International Journal of Operations and Production Management 15(4): 80–116.
28. Norman, D. (1998). The Post Disciplinary Revolution [WWW document] http://www.jnd.org/dn.mss/hfes-id-talk.htm (accessed 30th June, 2002).
29. Norton, J. (2006). Quoted in The Way Forward for NHS Health Informatics, A report on behalf of the British Computer Society (BCS) by the BCS Health Informatics Forum Strategic Panel, 15.12.2006.
30. Parr, A. and Shanks, G. (2000). A Model of ERP Implementation, Journal of Information Technology 15: 289–303. | Article | ISI |
31. Rollerson, A. (2007). Lost? The Times. 6th February, http://www.telegraph.co.uk/core/Slideshow/slideshowContentFrameFragXL.jhtml?xml=/news/2007/02/12/nhs/nhspix.xml&site=_-_by_Andrew_Rollerson_.286_Feb_2007.29 (accessed 6th April 2007).
32. Royal Academy of Engineering and British Computer Society (2004). The Challenges of Complex IT Projects – The report of a working group from The Royal Academy of Engineering and The British Computer Society, London.
33. Royal College of Nursing (2006). Nurses and NHS IT developments – Results of an online survey by Nursix.com on behalf of the Royal College of Nursing [PDF document] http://www.rcn.org.uk/publications/pdf/nurses_and_NHS_IT_developments_survey_2006.pdf (accessed 6th April 2007).
34. Scott, J.A. and Kaindl, L. (2000). Enhancing Functionality in an Enterprise Software Package, Information & Management 37(3): 111–122. | Article | ISI |
35. Shepherd, C. (2006). Constructing Enterprise Resource Planning: A thoroughgoing interpretivist perspective on technological change, Journal of Occupational and Organizational Psychology 79: 357–376. | Article | ISI |
36. Solow, R.M. (1987). We'd Better Watch Out, New York Times, July 12th, Book Review.
37. Willcocks, L. and Grint, K. (1997). Reinventing the Organization? Towards a critique of business process re-engineering, in I. McLoughlin and M. Harris (eds.) Innovation, Organizational Change and Technology, London: International Thompson Business Press, pp. 87–110.

Acknowledgements

The authors would like to thank Frank Land, Malcolm Peltu and Tom Stewart for their advice and comments on earlier drafts of this paper.

About the authors

Chris Clegg is Professor of Organisational Psychology at Leeds University Business School where he is helping set up the Centre for Organisational Strategy, Learning and Change. Since 1998 he has been Co-Director of the Rolls-Royce University Technology Partnership for Design. Previously he worked in the Institute of Work Psychology at the University of Sheffield. His main interests are in the areas of job design, new technology and the management of change. He is a Fellow of the British Psychological Society, the British Computer Society and the Royal Society of Arts.

Craig Shepherd is a research fellow at Leeds University Business School within the Centre for Organisational Strategy, Learning and Change. Previously, he worked at the University of Sheffield in the Institute of Work Psychology, and, prior to that, as an information technology consultant for Shell. His main interests are in the areas of new technology and the management of change.