Technological developments and increasing demand on the current ageing computerized patient administration system at a large teaching hospital trust led to the decision to implement a change project to replace the existing system with a newer, up-to-date system and roll it out throughout all departments within the trust.

The information technology (IT) department was given the responsibility for the project, and allowed to select the members of the project team that was formed. This consisted primarily of internal and external (from the software supplier) IT experts, with the inclusion of planning, contracting and finance staff.

Other departments (such as training) were delegated specific tasks but were not included in the project team.

The project team began by conducting a review of the current system and a scoping exercise for the new system. Of particular importance was to ensure that the new system was technically capable of linking to external NHS computer systems used by general practitioners and primary health care providers, that it was technically robust enough to deal with projected increase in demand, and could as a minimum provide the same level of functionality as the old system.

The project was viewed as being primarily a technical exercise, with the focus being on the technical functionality of the new system and the ease of transfer of existing records.

The project was centrally driven from the IT department, and a single trust-wide announcement was made to inform staff of the upcoming change. The only other involvement that the majority of the primary users of the patient administration system had with the project was when they were invited to attend compulsory training on the new system three to six months before the expected ‘go live’ date of the new system. This training was designed to inform them of the differences with the new system and to equip them with the new skills, procedures and expertise to use it. The training was not designed to allow feedback on the new system, despite the strong opinions that some members of staff held and wanted to feed into the project.

The project was managed through monthly project team meetings that focused on the development of software, the testing of the new system, planning and installing the new IT equipment that was necessary, the financial cost of the project and the projected cost savings associated with the benefits from the successful delivery of the project and how these would help the trust meet its financial performance targets.

At one of the project team meetings it was discovered that minute technical changes to the new system, which affected how it was to be used, would require the user training material to be rewritten, and those staff who had already been through the original training would need to be retrained. This new training programme would increase significantly the training costs for the project and threatened to put the entire project over budget. As this had not been raised as a potential risk to the project at the project initiation and planning stage (part of the ‘develop an action plan’

stage of the OD model for change in Figure 8.2), there was no ready-prepared contingency in place. Due to the difficulty of designing and delivering this training at very short notice, the training programme was not completed before the ‘go live’ date.

The new patient administration software had been successfully developed and tested by the project ‘go live’ date, and the decision was taken that, as the roll-out of the training had not been successfully completed, the old system would run in parallel for a period of time. The IT department and project team considered the project to be successfully delivered –

the new system was able to ‘go live’ on the target date, and although there was still training to complete there were no major technological issues that needed addressing. The project was considered closed and the audit department were tasked to carry out a follow-

on audit to reinforce the successful delivery of the project. Nine months after the ‘go live’ date, and more than six months after the completion of the training, staff were audited to assess the compliance with using the new system. Only 32 per cent of staff were found to be exclusively using the new system; 14 per cent of staff were using the new system for some tasks and the old system for others. The remainder (54 per cent)

were not using the new system at all. The audit was followed by a survey to learn why the usage rates for the new system were so poor. The reasons given were varied (as you would expect), but several key themes were identified:

● ‘The new system makes it harder to do my job than the old system.’

● ‘I never had the training for the new system.’

● ‘I was confused by the multiple training courses and so have kept using the old system as it is easier.’

● ‘I already know how to use the old system so why would I change?’

● ‘There is no incentive to use the new system (and no penalty for using the old system).’

● ‘The old system works perfectly well for what I need it to do.’

A workgroup was formed to look into the ‘delayed delivery’ of the expected benefits from the new patient administration system; its membership was taken from the original project team.

Questions

● Considering the OD model for change in Figure 8.2 and the stages that it proposes are necessary for the successful implementation of change:

• Which stages were done well?

• Which stages could have been done better?

• What could have been done to improve the potential for successful delivery of the project?

• Were any stages missed out entirely?

● What lessons could the trust learn from this change project?

● What would you recommend to the executive board to ensure the ultimate success of the new patient administration system?