Software adoption

In computing, adoption means the transfer (conversion) between an old system and a target system in an organization (or more broadly, by anyone).

If a company works with an old software system, it may want to use a new system which is more efficient, has more work capacity, etc. So then a new system needs to be adopted, after which it can be used by users.

There are several adoption strategies that can be used to implement a system in an organization. The main strategies are big bang adoption, parallel adoption and phased adoption. "Big bang" is a metaphor for the cosmological theory of the same name, in which the start of the cosmos happened at one moment in time. This is also the case with the big bang adoption approach, in which the new system is supposed to be adopted wholesale on one date. In the case of parallel adoption, the old and the new system are run in parallel initially, so that all the users can get used to the new system, but still can do their work using the old system if they want to or need to do so. Phased adoption means that the adoption happens in several phases, so that after each phase the system is a little closer to being fully adopted by the organization.

Selecting an adoption strategy

The adoption strategy has to be selected before adoption begins, and is chosen based on the goals to be achieved and on the type of system to be implemented. The three types of adoption, Big Bang, parallel adoption and phased adoption, range from an instant switch to a strategy where users progressively start using the new system over a certain period of time (which can be weeks, months or even years).

The actual selection is done by prioritizing the goals to be achieved and then matching a strategy against it (Eason, 1988). Eason defines the following goals:

• Possible requirement of a “critical mass” to make the system work.

If a large critical mass is, or might be, needed for the system to work effectively (e.g. due to network effects), a big bang strategy might be the answer. (Rogers, 1995)

• Need for risk control, if risk is involved.

Minimising risk to the ongoing operation of the organization can be very important. Parallel and phased introductions might help to control these risks, depending on the situation.

• Need for facilitation of the change.

The organization has to be ready for the changeover. Socio-technical preparations such as training sessions and ready-made scenarios must be clear.

• Pace of change

If the new system is designed to deal with new requirements, such as business process reengineering, the speed at which the organization is changing over to the new processes or attempting to meet other new requirements.

• Local design needs

The system might need to be adjusted to the users needs. In this case, the chosen strategy must provide the opportunity to do so.

Table Eason Matrix

The actual selection of adoption strategy depends on far more factors then these goals, but they create a window to choose one of the types. Other criteria are called variables (Gallivan, 1996). Gallivan suggests that the appropriate adoption types depends on:

Innovativeness of the individuals
Attributes of the ones that are to adopt the innovation/system

The type of innovation
Is it a process or product innovation?

Attributes of the innovation itself
Preparedness, communicability and divisibility

The implementation complexity.
How complex is the implementation or what is it is extent?

These variables are of a higher level than the criteria of Eason and should be handled as such. Based on table 1 and on the mentioned higher level variables by Gallivan, one can make a selection of an appropriate strategy to choose.

Preparing an organization for adoption

Figure 1: Organization preparation Process

In order to prepare the organization for the adoption of the new system, the changes that will take place need to be determined. This is necessary to be able to have a plan or an overview of the changeover, and can be done by creating requirements for the system. Once the management has determined the requirements in a report of determined changes, they need to agree upon them to be able to move on with the change-process. If there is no agreement, the management needs to discuss the requirements again and again until they do agree. If agreement is achieved and the agreement contract is signed, the organization can take further steps. So now the test-phase can be prepared, in which the validity of the data that will be used will be checked and in which trials will be held (Eason, 1988).

In parallel, it is highly recommended that a comprehensive user adoption plan be prepared working together with the business and the affected users. This plan should consider all pre- and post- system rollout communications; user training & documentation; any internal marketing efforts that will be undertaken to drive adoption such as system branding or swag; as well as troubleshooting assistance during the rollout (i.e. extended help desk hours and/or a hotline, and identification of key contacts for each affected business area).

See also

• SAP Implementation

References

• Eason, K. (1988) Information technology and organizational change, New York: Taylor and Francis
• Gallivan, M.J., (1996) Strategies for implementing new software processes: An evaluation of a contingency framework, SIGCPR/SIGMIS ’96, Denver Colorado
• Rogers, E.M. (1995), Diffusion of innovations, New York: Free Press
• Dodson, J. (2011), 4 Stops to Navigating the Treacherous Highway of Enterprise Software Adoption, Washington

.