Big bang adoption

Big bang adoption is the adoption type of the instant changeover, when everybody associated with the new system moves to the fully functioning new system on a given date (Eason, 1988).

When a new system needs to be implemented in an organization, there are three different ways to adopt this new system: The big bang adoption, phased adoption and parallel adoption.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, and meanwhile 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 nearer to be fully adopted. With the big bang adoption, the switch between using the old system and using the new system happens at one single date, the so called instant changeover of the system. Everybody starts to use the new system at the same date and the old system will not be used anymore from that moment on

The big bang adoption type is riskier than other adoption types because there are fewer learning opportunities incorporated in the approach, so quite some preparation is needed to get to the big bang (Eason, 1988). This preparation will be described below, illustrated by the process-data model of the big bang adoption.

Table of concepts

Several concepts are used in this entry. The definitions of these concepts are given in the table below to make the use of them clear.

Big bang

Once the management has decided to use the big bang method and supports the changes which are needed for this, the real changing process can start. This process exists of several steps: converting the system, releasing parts of the system and training the future users (Eason, 1988).

The activities in the process are explained in the table below, to state them clear. The concepts that are used to execute the activities are in capitals.

Convert the system

At first a planning for the whole adoption process is needed. By making a planning future users will know what will happen and when they should expect certain changes, which avoids unnecessary uncertainties and therefore creates a better working atmosphere. The planning also makes clear when the real adoption takes place and gives the future users the opportunity to get ready for this change (Eason, 1988). In the model below is shown that the activities (in the grey box) lead to outcomes (in the boxes next to the grey box) to be able to have a partial outcome: the converted system

When the planning is made and everyone knows what will be expected from them, the technical changeover can start. First the old data needs to be converted into new data to be able to work with the data in the new system (Koop, Rooimans and de Theye, 2003). Then the new data needs to be loaded into the new system, which results in the so called loaded data. This loaded data needs to be tested to check the efficiency of the data and to test the level of understanding of the future users. So off-line trials need to be executed to check if the system and the users can work together. Not only the efficiency and the understanding need to be tested, also the validity needs to be tested to make the level of data validation clear (Eason, 1988). ). If the data is not valid, the management need to determine the changes again and the organisation will have to prepare again on a different way of executing the Big bang adoption (See Adoption; Prepare an organization for adoption).

Release parts of the system

If all the data is valid, separate parts of the system can be released. The database which is converted from the old database needs to be released, so the new data is accessible. Further on the produced application needs to be released, so the new application can also be used. The infrastructure of the whole new system also needs to be released, so that it is clear what the system will look like and how everything is connected (Koop, Rooimans and de Theye, 2003). Important to note is that in this phase only separate parts are released, which don’t form the new system yet, but only parts of it. Note that all of this happens off-line, only the system developers see this, the users are still working on the old system. In the model above is shown what activities need to be executed (in the grey box) by the system controller, to get the outcomes that lead to the released parts. If the release of the parts failed, the management need to determine new changes again (See Adoption; Prepare an organization for adoption).

Train the organization in using the system

If the release of the separate parts succeeded, the next step can be taken: prepare the users. To be able to introduce the whole new system, i.e. to adopt it, all users need to be trained in working with the new system. Without huge consequences for the production level of an organization, training everyone is only possible, if there is a buffer of experienced staff, who can take over the daily work of the users that need to be trained. This means that for all the people that need to be trained, there will be staff available who can take over the work, so there won’t be an enormous delay of work. When this buffer is created, the users can be trained (Eason, 1988). The human resources department will create the buffer of experienced staff (activity in the grey box) by inviting applicants for the buffer. After this the users can be trained and the trained users can be listed, so a user preparation report can be written.

But training the future users properly is not as easy as it seems, as the FoxMeyer case illustrates (Scott, Vessey, 2000). This company used the big bang method to implement an Enterprise Resource Planning (ERP) system. Wrong trainings were given, the assumption was made that users already knew enough about it and wrong skills were taught . Also the company Dow Corning had big problems with acquiring the necessary skills during their big bang ERP implementation (Scott, Vessey, 2000). Using a new system demands various skills and knowledge, which in several cases seem to be underrated by the (change) managers.

Release of the system

When all the steps which are described above are taken, the old system will be turned down. When the old system is off-line, the new system can be loaded and then will be released. Once the new system is released there is no turning back: the big bang has taken place. The run time of this adoption type is not very long. But the precare and perhaps moreover the aftercare is in the opposite very extended. For example a fall-back scenario needs to be developed, to be able to deal with or to prevent a disastrous changeover.

"Figure 1: Adaption to change (Eason, 1988)"
Once the system is introduced there usually is a socalled ‘initial dip phenomenon’ which happens because the users are struggling with the new system and with the connection to their daily work and the system (Eason, 1988). So what you can see in Figure 1 is that after the red line, which represents the big bang, the organizational performance goes to a bottom value, which takes a while, and after that it will increase again. This catch-up period needs to be planned, to be able to deal with these problems and difficulties.

The total process modeled in the process-data model is shown below. In this model you see the separate parts (the grey boxes) from the management preparation and the concerned activities (see also Adoption; Prepare an organization for adoption), to the next step that can be taken once there is agreement. This next step is the converting of the system with all the sub activities included and the outcomes of these activities at the right next to the grey box. The prepared management report makes it possible to make the planning. Once the system is converted the release of parts of the system (third grey box) can get started, and after this the next step (the last grey box) is the user preparation which is executed by the human resources department. The outcome of this is the buffer as explained above and the trained users list.When the users are trained a report of the user training is made, which is required for the final implementation of the system.

Techniques

There are several techniques to implement a new system. The adoption phase is only one phase of the whole implementation. Regatta (Koop, Rooimans and de Theye, 2003) is for example a method which is developed to implements systems. This method, developed by Sogeti, treats a changeover as a project and focuses several stages of this project, for example the preparation phase () of an adoption and on the acceptance of an implementation method (). SAP Implementation is another technique specialized in implementing and adopting SAP AG software, which is divided into several techniques.

Advantages and disadvantages

This sudden changeover is quite drastic. This has advantages, but because of the instant changeover there are also disadvantages (Koop, Rooimans and de Theye, 2003). The advantages of this method:

* Training is only needed for the new method, not also for the changeover period.
* User documentation does not need to be updated during the implementation process, because it happens in such a short period.
* The changeover is at one date and this date is clear for everyone.
* There are no special interfaces needed to be able to get used to the new system, because the new system is all there is.

The disadvantages on the other hand are:
*There is no time for extra additions
*The completeness and validity of the converted data is not completely proved, only in the pre-phases, but not in the whole system situation.
*Start up problems are a problematic factor
*The operation is complex, one of the main complexities is tuning all activities to happen on one moment: the big bang
*‘Fall back’-plans are hard to develop and become more impossible when the big bang has taken place
*There can be a catch up period (as explained above)
*This adoption is vulnerable because of the limited possibilities to maneuver. There is a lot of pressure because the deadline must be met.

Risks

Because of the instant changeover, everything must be done in a fixed time schedule. This is a risky operation. The organization might not be ready yet for this, an incorrect dataset might be used, or the information system can get stuck, because of a lack of experience and start up problems. Also an incapable fall-back method can be a risk in implementing a system using the Big Bang (Koop, Rooimans and de Theye, 2003).

To illustrate some other risks, two examples will be given. The first one is the company Dow Corning, which used systems that were focused on specific departments. The management decided that they wanted to become a truly global company, that would use only one information system: an Enterprise Resource Planning (ERP)-system. To adopt this new ERP-system, they used the big bang adoption type and they spent considerable time and effort reexamining its business processes. The company was prepared for the adoption and first conducted three pilot implementations, before using the new system across the global organization. Second, FoxMeyer adopted an ERP-system with ambitious warehouseautomation software, using the big bang adoption to gain competitive advantage. But FoxMeyer seemed to have an overoptimistic management with unrealistic expectations, the change was too big and to drastic.This resulted in very high work pressure to meet the deadlines for all the employees. So unrealistic expectations of the management are also a risk (Scott, Vessy, 2000).

Dow Corning monitored the progress constantly and made decisions to make sure that the deadlines would be met. This was only possible with feedback and good communication. FoxMeyer failed in having communication and attention that was necessary to be able to give fast and effective feedback. They instead tried to minimize problems by ignoring them and gave discouraging criticism, which resulted in ambiguous feedback. This hindered organizational learning, something which is very important during an organizational change. So bad communication and ambiguous feedback are also risks when adopting a system with the big bang (Scott, Vessey, 2000).

Other risks are to focus only on the outcome, not on how to achieve this outcome and underrating the learning process for users. It is very hard to plan learning or knowledge, though these are necessary to be able to execute the big bang changeover.

See also

* Adoption (software implementation)
* Phased adoption
* Parallel adoption
*
*
*
* SAP Implementation
* PRINCE2
* Agreement
* Implementation
* Planning
* Data validation

References

* Eason, K. (1988) Information technology and organizational change, Taylor & Francis.
* Koop, R., Rooimans R., and de Theye, M. (2003) Regatta: ICT-implementaties als uitdaging voor een vier-met-stuurman, S.D.U. Uitgeverij. ISBN 90-440-0575-8.
* Scott, J.E., Vessey, I. (2000) Implementing enterprise resource planning systems:the role of learning from failure, Information systems frontiers, vol.2(2), pp. 213–232.