 | |||
|
|
||
| |||
| |||
| |||
|
||||||||||||||||||||
| |
|
Home > Change management and system implementations: Nine major risks |
| |
|
|
|
|
| Book Excerpt: |
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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.
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.
Figure 15.5 Activities in system implementation suitable for business staff 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.
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.
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:
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:
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:
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:
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.
|
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
About Us | Contact Us | For Advertisers | For Business Partners | Site Index | RSS |
|
|
||
|
|||||||
