Big bang adoption

At first, a plan for the whole adoption process is needed. The plan allows future users to know what will happen and when they should expect certain changes, which avoids unnecessary uncertainties and therefore creates a better working atmosphere. The plan also makes clear when the real adoption takes place and gives the future users the opportunity to get ready for this change.[1] The model below shows 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 plan is made and everyone knows what is expected from them, the technical changeover can start. First the old data needs to be converted into a form which is able to work with the data in the new system (Koop, Rooimans and de Theye, 2003). Then this 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. Off-line trials need to be executed to check whether the system and the users can work together. Not only do the efficiency and the understanding need to be tested, but the validity needs to be tested to make the level of data validation clear.[1] If the data is not valid, the management need to determine the changes again and the organisation will have to prepare a different way of executing the Big bang adoption.

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. Next, 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). In this phase only separate parts are released, which don't form the new system yet, but only parts of it. All of this happens off-line: only the system developers see this, while the users are still working on the old system. The model above shows 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).

If the release of the separate parts succeeded, the next step will be to 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.[1] The human resources department will create the buffer of experienced staff (activity in the grey box) by inviting applicants for the buffer. Then the users can be trained and the trained users can be listed, so a user preparation report can be written.

Poor training can have bad outcomes for an organization, as the FoxMeyer case illustrates (Scott, Vessey, 2000). This company used the big bang method to implement an Enterprise Resource Planning (ERP) system. Wrong training was given, the assumption was made that users already knew enough about it and the wrong skills were taught. Dow Corning also 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 underestimated by those managing the switchover.

The 1986 the London Stock Exchange closed on Friday night and the computers were all switched on the following Monday morning.[4][5] It has been alleged that this caused large losses.

Dow Corning formerly 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.(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.(Scott, Vessey, 2000)

Another risky strategy is 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.

FoxMeyer adopted an ERP-system with ambitious warehouse automation 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 too 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).

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).