Phased adoption

Phased adoption or phased implementation is a strategy of implementing an innovation (i.e., information systems, new technologies, processes, etc.) in an organization in a phased way, so that different parts of the organization are implemented in different subsequent time slots. Phased implementation is a method of System Changeover from an existing system to a new one that takes place in stages.^[1][2][3] Other concepts that are used are: phased conversion, phased approach, phased strategy, phased introduction and staged conversion. Other methods of system changeover include direct changeover and parallel running.

Information Technology has revolutionized the way of working in organizations.^[4] With the introduction of high-tech Enterprise Resource Planning Systems (ERP), Content Management Systems (CMS), Customer and Supplier Relationship Management Systems (CRM and SRM), came the task to implement these systems in the organizations that are about to use it. The following entry will discuss just a small fraction of what has to be done or can be done when implementing such a system in the organization.

The phased approach takes the conversion one step at a time. The implementation requires a thoroughly thought out scenario for starting to use the new system. And at every milestone one has to instruct the employees and other users. The old system is taken over by the new system in predefined steps until it is totally abounded. The actual installation of the new system will be done in several ways, per module or per product and several instances can be carried out. This may be done by introducing some of the functionalities of the system before the rest or by introducing some functionalities to certain users before introducing them to all the users. This gives the users the time to cope with the changes caused by the system.

It is common to organize an implementation team that moves from department to department. By moving, the team learns and so gains expertise and knowledge, so that each subsequent implementation will be a lot faster than the first one.

The visualising technique used in this entry is a technique developed by the O&I group of the University of Utrecht.^[5] The technique is described in the following Wiki: Meta-modeling technique.

As can be seen in figure 1, phased adoption has a loop in it. Every department that is to be connected to the system is going through the same process. First based on the previous training sessions security levels are set (see ITIL) In this way every unique user has its own profile which describes, which parts of the system are visible and/or usable to that specific user. Then the document and policies are documented. All processes and procedures are described in process descriptions, can be in paper or on the intranet. Then the actual conversion is depicted. As described in the above text, certain departments and or parts of an organization may be implemented in different time slots. In figure 1 that is depicted by implementing an additional module or even a total product. HRM needs different modules of an ERP system than Finance (module) or Finance may need an additional accounting software package (Product). Tuning of the system occurs to solve existing problems. After the certain department has been conversed the loop starts over, and another department or user group may be conversed. If all of the departments or organization parts are conversed and the system is totally implemented the system is officially delivered to the organization and the implementation team may be dissolved.

Phased adoption makes it possible to introduce modules that are ready whilst programming the other future modules. This does make the implementation scenario more critical, since certain modules depend on one another. Project Management techniques can be adopted to tackle these problems. See the techniques section below.

However, the actual adoption of the system by the users can be more problematic. The system may work just fine but if it is not used it’s worthless. Users base their attitude towards the system on their first experience.^[4] As this creates an extra weight on the first interaction, the implementers should be concerned with making the first interaction especially a pleasant one.

In the technique used in this entry each CONCEPT requires a proper definition which is preferably copied from a standard glossary of which the source is given, if applicable. All CONCEPT names in the text are with capital characters. In Table 1 the concept definition list is presented.

Table 1: Concept Diagram

The Phased adoption method has certain pros, cons and risks^[8][4]

Pros:

• The conversion will be done in parts. Time is available for adjustments
• Negative influences that arise at the start are less critical
• No ‘catch-up’ period is needed.
• Time for the users to adapt is longer
• Technical staff can concentrate on part of the system or some of the users.

Cons:

• Several adjustments are needed
• Training sessions are confusing for users as they are asked to work with the new and the old system
• Several changes in documentation
• The duration of the project
• System delivery milestone is unclear
• Correctness and completeness of the dataset has to be checked several times
• A ‘fall back’ to the old system is becoming more difficult every new phase.
• The implementation may appear unclear to the employees and other users.

Risks:

• Complexity of the implementation
• Prone to make mistakes
• Fall back impossible in later phases

The following sections are supplemental to the entry about adoption (software implementation) and are specific to phased adoption:

The configuration and specification of the hardware in place used by the legacy system and to run the new system is delivered in the hardware specifications. The hardware configuration is tested to assure proper functioning. This is reported in the hardware configuration report. The configuration and specification of the software in place, i.e., the legacy system and the future new system is made clear to assure proper functioning once the system is installed.^[9] The act of specifying the system already installed is key to the implementation. Which parts or even total systems will be taken over by the new system? All this is reported in the software installation and software test reports. The actual installation of the software of the new system is also done here in a confined area to support the training sessions described in the following section.

The system training will teach users the keystrokes and transactions required to run the system.^[6] The pilot exercises the systems and tests the users understanding of the system. The project team creates a skeletal business case test environment which takes the business processes from the beginning, when a customer order is received, to the end, when the customer order is shipped. Training as such is not enough for adopting an information system. The users have learning needs.^[4] Known learning needs are the emotional guidance. Users need to make emotional steps in order to make cognitive steps. If they fear the system due to its difficult handling they may not be able to understand the cognitive steps needed to successfully carry out the tasks.

In the implementation field several techniques are used. A well-known method, and specifically oriented on the implementation field, is the Regatta method by Sogeti. Other techniques are the SAP Implementation method, which is adapted to implementing SAP systems. Systems are installed in several different ways. Different organizations may have their own methods, When implementing a system, it is considered a project and thus must be handled as such. Well known theories and methods are used in the field such as the PRINCE2 method with all of its underlying techniques, such as a PERT diagram, Gantt chart and critical path methods.

The EMR implementation at the University Physicians Group (UPG) in Staten Island and Brooklyn, New York.

The University Physicians Group in New York went with a complete technical installation of an EMR (Electronic Medical Record) software package. The UPG found that some vendors of the EMR package recommended a rolling out that would be done all-at-one, also called the Big Bang. But they found out that the Big Bang would have overwhelmed the physicians and staff due to the following factors:

• Ongoing workload during the key lessons prevented them to fully pay attention.
• Urgent need to complete some records caused the users to fall back to the old system
• Information overload on the physicians side.
• No time to play around with the system.
• 100% availability was not assured by the vendor.

Thus they chose a phased approach: “Hence, a phased adoption to us, offered the greatest chance of success, staff adoption, and opportunity for the expected return-on-investment once the system was completely adopted.” (J. Hyman, M.D.)

There also was a group who were somewhat reluctant about any new systems. By introducing the system to certain early adopters the late majority would be able to get to know the system.^[10] As it was introduced phased through the organisation. Per loop (see figure 5, A) the UPG was introduced to the system.

As an example, think of a supermarket. In this supermarket the checkout system is being upgraded to a newer version. Imagine that only the checkout counters of the vegetable section are changed over to the new system, while the other counters carry on with the old system. If the new system does not work properly, it would not matter because only a small portion of the supermarket has been computerised. If it does work, staff can take turns working on the vegetable counters to get some practice using the new system.

After the vegetables section is working perfectly, the meat section might be next, then the confectionery section, and so on. Eventually all the various counters in the supermarket system would have been phased in, and everything would be running. This takes a long time as there are two systems working until the changeover is completed. However, the supermarket is never in danger of having to close and the staff are all able to get plenty of training in operating the new system, so it is a much friendlier method.

• PRINCE2
• Regatta method by Sogeti
• Parallel adoption
• ERP
• SRM
• CRM
• Software package

• Gallivan, M.J., (1996) Strategies for implementing new software processes: An evaluation of a contingency framework, SIGCPR/SIGMIS ’96, Denver Colorado
• Rooimans, R., Theye, M. de, & Koop, R. (2003). Regatta: ICT-implementaties als uitdaging voor een vier-met-stuurman. The Hague: Ten Hagen en Stam Uitgevers.