Change management and system implementations: Nine major risks

Change management and system implementations have many risks. Learn nine specific areas where system implementations can go wrong.

The following excerpt about change management and systems implementations is taken from Breakthrough IT change...

management: How to get enduring change results and is printed with permission from Butterworth-Heinemann, a division of Elsevier. Copyright 2005. Click here to read all of Chapter 15, Change management and system implementations: Nine major risks.

Change management and system implementations

Technology and systems implementations are full of risks. But being aware of the potential hazards can help you avoid them -- and increase the chances for a successful system implementation. The authors of this chapter highlight nine areas susceptible to problems.

System implementation risk No. 1: End user involvement

You should have continuous business staff involvement. What can the users be expected to do? A list for the business staff appears in Figure 15.5. Note that IT staff will have to participate in these tasks too.

This is a powerful and lengthy list of things to do. What if the business managers balk at having some of these things performed by their staff. They can use many excuses. Here are some common ones.

  • There are no employees available. Then the new process is not a priority. Why are we doing the work then?
  • We do not know how to do this as we have not done it before. IT can help and the users can participate.
  • It is mostly IT work. Wrong! It is almost entirely business work that needs some limited IT involvement.

None of these are really valid. After all, if the business wants the system and new process, they have to be willing to put "skin in the game" or be part of the effort. They cannot just be spectators. They have to be participants. One reason for this is that these tasks are not appropriate for IT to do. They don't have the knowledge or experience of the business staff. They do not know their terminology. They may produce work that is not complete or acceptable.



  • Analyze the current business process and work
  • Uncover issues and problems in the current work
  • Define the new business process
  • Help to define Quick Hits from this analysis
  • Help in defining requirements
  • Define the benefits and how they will be measured
  • Participate in design and development
  • Be involved in software package evaluation and selection
  • Participate in data conversion work
  • Be involved and support policy and procedure changes and other Quick Hit activities
  • Support measurement of Quick Hits
  • Participate in testing
  • Develop the training materials
  • Develop the procedures for the new process and system
  • Train the business staff in the new process and system
  • Support the cut-over to the new process and system
  • Eliminate the old process and its vestiges including shadow systems and exceptions and workarounds
  • Change the process to fit the new system and work
  • Measure the benefits after change and implementation
  • Provide on-going training for new employees in the process and system
  • Support on-going measurement of the process and work
  • Help to prevent process deterioration

System implementation risk No. 2: Requirements definition and project scope

Scope creep and unstable requirements are big problems in almost all major systems efforts. Prevention of these things requires that there be constant user involvement. The user activities defined in Figure 15.5 provide for this.

Another method for reducing these risks is to revisit the business process and work to see if there have been changes after the requirements have been gathered. This will help keep the people involved in implementing the new process and system in touch with the people doing the work.

A third method is to ask the following questions when someone wants to make a change to requirements or add to the scope. Answering these questions will dissuade people from changes. Here is a tip. Point out that these questions will be asked every time that there is a change early in the implementation effort.

  • What is the change needed?
  • What are the benefits of the change?
  • Why did this change surface now? Why was it not detected earlier?
  • How would the benefits be measured?
  • What is the requestor willing to do to support the implementation of the change?
  • If there are multiple requests, maybe the entire effort should be stopped and the requirements revisited since the entire situation has changed substantially?
  • What if the change is not done? What will the business unit do?
  • What if the change is deferred? What will the business unit do?

As you can see, these are very pragmatic questions that deserve answers.

System implementation risk No. 3: Getting the business rules

Business rules are the detailed directions for how specific pieces of work or transactions are handled. As such, their understanding is key to whether the new system and process meet the requirements of the business and deliver the benefits.

Where are the business rules? In the process. However, many are in the program code of the existing, old system. Here is a tip. Begin to gather business rules from the IT programmers and staff who support the old system. They tend to be more familiar with them than most of the business staff since they have to know their programs. Once business rules are programmed, many users then just assume they are there and do their other work. After you have exhausted the IT staff, then go to the "king bees" and "queen bees." These people are now useful here in that they can provide the business rules as well as how and why they were created. This is your best use of these people.

System implementation risk No. 4: Process documentation and training materials

It has already been pointed out that these are properly the domain of the business staff. IT employees can work with the business staff to get these documents started. Here are some additional guidelines.

  • Assemble and organize documents from past IT projects and implementations that can be used as models. There is nothing wrong copying or following what has worked before if it is relevant.
  • Have people develop procedures using the method of successive refinement. That is, the employees develop successively more detailed outlines. This will lead to reduced risk since you know the status of the documentation at any one time.
  • Have other business staff review end products for language, tone, politics, and content. These are the best people to do reviews.

System implementation risk No. 5: System interfaces and integration

This is an area of major concern. Most new systems do not operate in a vacuum. They have to interface to surviving parts of the old system or to other systems. Some of the problems with interfaces are:

  • Systems change over time so that interfaces have to be monitored and maintained.
  • Systems were written at different times by different people so that there are likely to be differences in meaning, format, creation, and other attributes of data elements.

System interfaces have to be designed in terms of content, timing, frequency, validation of interface, backup if there is a problem, recovery if there is a problem, and format. Thus, you want to gather interface information early in requirements. Similar comments apply to system integration. Design of integration of systems and how to test the integration are key ingredients to systems success. This is so important that system integration should be pulled out as a separate subproject.

System implementation risk No. 6: Data conversion

Converting data from the old system to the new has been a real curse and problem for us over the years. Some of the problems are:

  • There is missing data
  • The data elements of the new system are more comprehensive than that of the old
  • The data elements of the new system have meanings different from that of the old
  • The data in the old system is of questionable validity and accuracy
  • Data quality is bad in the old system

As with interfaces, you want to start analyzing the current data early. Then you want to map in to the data elements of the new system. You also have to make provision for data cleanup. In more than one systems effort, this was ignored and the result was that the entire system implementation was held up while the data was cleaned up for conversion.

There are some critical activities and areas to address in data conversion, including:

  • What is the quality and nature of the current data?
  • How does the data in the old system map into or relate to that in the new system?
  • What data is missing?
  • What will be done about the missing data? There are several options: live without it, add it to the old system and then convert it, or add it to the new system.
  • What will be the conversion approach?
  • What is the timing of the conversion? If you convert too early, then the data in the old system that is still in production has changed.

System implementation risk No. 7: User acceptance of change

In traditional system implementation user acceptance of change is a milestone left to the end. The dream is that people who had resisted change will see the new system. The light will then come on. Then the users will wholeheartedly endorse the new process and system. In your dreams!

A more realistic approach is to get as many different users involved in the system implementation. Also, you want the users to acknowledge the problems in the current process and system. Then they can be involved in the implementation of Quick Hits. With these steps you achieve user acceptance. User acceptance does not come overnight.

Moreover, just because a business manager accepts the system does not mean that the lower level business staff do. They may just continue to do things the old way even after implementation and acceptance. This brings up the major questions of "what is acceptance?" and "what does acceptance mean if the lower level users do not accept it?"

System implementation risk No. 8: Benefits attainment

Attaining benefits is a major concern that has been pointed out in this and previous chapters. The ingredients of achieving benefits are the following:

  • Initial definition of benefits
  • Definition of how benefits will be measured
  • Determination of what will happen when the benefits are achieved
  • Implementation of the new process as well as the new system
  • Measurement of the actual benefit
  • Decision on what to do with the benefits

These are important. Just because you get benefits, if you do nothing with them, then there are really no benefits.

Another guideline is that all benefits must be translated into tangible benefits. That is, you should not allow fuzzy benefits. Systems projects are often cursed with fuzzy benefits. Let's take an example of how to do the conversion from fuzzy to tangible. Suppose that the new system is much easier to use and is more "user friendly." What does this mean in the real world? Training time should be less. Documentation should be simpler and faster to develop. There should be greater throughput of work. The time to do the work may be less. These are all tangible.

Now remember our discussion of benefits for the new process. You measured not just the new process, but also what would happen if the old process were to continue to live. There would be more deterioration. Keep this in mind when measuring benefits.

System implementation risk No. 9: Process measurement

Many organizations implement new systems and then perform a postimplementation review. If this is successful and the business unit is not unhappy, measurement often stops. There is no provision of on-going measurement in IT systems implementation. Big mistake! Remember that the system and process can deteriorate individually and collectively. Thus, there must be the on-going process measurement that was discussed in Chapters 13 and 14.

Continue reading this chapter about change management and system implementations.

Dig Deeper on MDM best practices