Adoption (software implementation)

From Wikipedia, the free encyclopedia
Jump to: navigation, search

Adoption deals with the transfer (conversion) between an old system to a target system in an organization. So 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, where after it can be used.

There are several types of adoption that can be used to implement a system. The types ‘big bang’, ‘parallel adoption’ and ‘phased adoption’ form the main types that are used to adopt a system. The big bang relates to the cosmological theory (Big bang) where the start of the cosmos happened at one moment in time. This is also the case with the big bang adoption type where the new system is adopted on one date. In case of parallel adoption the old and the new system are running parallel so all the users can get used to the new system, but still can do their work using the old system. Phased adoption means that the adoption will happen in several phases, so after each phase the system is a little closer to be fully adopted by the organization

Define the wanted type of adoption[edit]

The adoption type has to be defined in front of the adoption phase and will be 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, are ranging from an instant switch to a strategy where users progressively start using the new system over a certain period of time (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 existence of needed “critical mass” to make the system work.

If a large critical mass is needed for the system to work a big bang strategy might seem the answer. (Rogers, 1995)

  • Need for risk control, if risk is involved.

Minimising risk to operation of the organization is key. Parallel and phased introduction might control this risk.

  • 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 over

The speed of in which the organization is changing over to the new system.

  • Local design needs

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

Table Eason Matrix

Eason matrix.gif

The actual selection of adoption type 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 then 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.

Prepare an organization for adoption[edit]

Org prep.gif
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).

See also[edit]


  • 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