Chapter 17 System Implementation
Chapter 17
System Implementation
Chapter Overview
This chapter introduces students to many of the activities carried out during implementation, including coding, testing, installation, documentation, user training, and support for a system after it is installed. While most systems development texts do not include much material on implementation, the authors remedy this situation by providing material on relevant management issues, including change management, organizational politics, and implementation success. The authors also include a discussion of implementation failure, something few systems developments texts discuss, despite the high rate of information systems failure. The discussion of failure is presented in the context of factors the analyst (and project manager) can control in an attempt to ensure success.
One of Chapter 17’s goals is to show the student that implementation is neither simple nor mechanical. Throughout the textbook, the authors emphasize that systems development is a change process. For many users, the most obvious evidence of change comes during implementation. Once a new system has been coded, tested, and installed, the systems development team does not simply walk away. The organizational members left with the new system, the users, need a solid understanding of how the new system fits into their work lives and how the system can support them in their day-to-day work activities. User documentation, training, and continuing support are all parts of providing this solid understanding to users. In some organizations, other specialists in the IS department, such as technical communicators, trainers, local experts, and help desk employees, are available to help the analyst complete this part of the implementation process. In other organizations, the analyst will do most of this work alone. In the latter case, the importance of user documentation, training, and support should not be overlooked. The success of a system implementation effort depends on what the users think of the system and their inclination to use it well. The training and support efforts have a definite effect on user attitudes and inclinations.
In the “Electronic Commerce Application: System Implementation and Operation For Pine Valley Furniture’s WebStore” section, the authors apply the concepts presented in this chapter to the implementation process conducted at PVF’s WebStore. The authors discuss the preparation of test cases and the alpha and beta testing process for the WebStore.
Instructional Objectives
Specific student learning objectives are included at the beginning of the chapter. From an instructor's point of view, the objectives of this chapter are to:
1. Discuss with students the subprocesses that make up system implementation.
2. Teach students about the many different types of testing that occur in implementation and when each one is appropriate.
3. Show students how to prepare a test plan for an information system.
4. Have students distinguish among four installation strategies: direct, parallel, single location, and phased installation and know when to use each one.
5. Explain the differences between system and user documentation, emphasizing that system documentation occurs throughout the SDLC.
6. Provide students with the information necessary for them to write task-oriented user documentation.
7. Demonstrate the many different modes available for training users, including tutorials, courses, self-training, electronic performance support systems, and other types of embedded training.
8. Show students how to prepare a training plan for an information system.
9. Explain to students the issues associated with user support, whether internal or external to the organization.
10. Teach students about the factor and political models of implementation and how to use such models to help ensure implementation success.
Classroom Ideas
1. Most of your students have probably completed programming courses and are familiar with both coding and testing. Ask your students to think about coding and testing in the context of what they have learned about systems development. What methods can they suggest that would help manage coding and testing in an on-going systems development project, as opposed to a series of isolated programming class projects?
2. Have your students generate a test plan for one or more of the various systems development projects presented in the text; for example, Hoosier Burger’s food ordering system or inventory control system. Have students consider Mosley’s seven types of testing, as well as user acceptance testing. Alternatively, have students develop a testing plan (at a general level) for a major packaged software release, such as a new version of a popular DBMS (e.g. Microsoft Access or Oracle) or a major application system, such as SAP.
3. Present a series of information system implementation scenarios. Have your students determine which strategy--direct, parallel, single location, or phased--works for each scenario and why.
4. Have your students identify the aspects of the factor and political models of implementation they should consider for the Hoosier Burger and Pine Valley Furniture systems presented in the text. Ask your students to generate lists of what they believe could go wrong during implementation for either company. These lists should accompany suggestions for addressing these potential problems.
5. Ask students to read the Kling and Iacono and Markus papers cited in the chapter, as well as other relevant works of these authors. Have students prepare in-depth analyses of political models of systems implementation in the form of papers or class presentations. What risks do analysts, project managers, and organizational management run if they ignore political considerations?
6. Have your students discuss the “The Future Programmer” box on page 574 of the text. Do they agree with the predictions stated in this quote? Ask students to find supporting or contradicting information to this quote. Ask the students to predict the success factors for a programmer in 2010.
7. Many students have not seen very sophisticated program and system testing environments. It is likely that they have used some form of a debugger, but they probably have not seen or used more thorough testing systems. Have your students investigate various commercial testing tools and present their findings to the class.
8. A video segment, Managing User Expectations, is available to supplement your lecture on this chapter. This video segment is approximately 12 minutes long. Notes on using this and other video segments available to adopters of this text are included in a separate section of this instructor’s manual. See the Preface to this instructor’s manual for information on how to obtain copies of the video segments produced for use with the third edition of Modern Systems Analysis and Design.
9. Use Tables 17-5 and 17-6 and Figures 17-6, 17-7, and 17-8 to demonstrate the differences between system and user documentation. Encourage your students to think about being a user, not a developer or IS specialist, in which one’s focus is on doing the job, not using the software. Bring in a user’s manual for a common product (e.g., a TV, VCR, or microwave oven) and have your students analyze the features of this manual that make it a good or bad manual.
10. Several examples of documentation are provided in the chapter. Ask your students to bring in other examples. Some students will have access to documentation prepared for customized applications developed for a variety of purposes and computer platforms. Ask your students to present their documentation to the class. Your students should show at least the table of contents and samples from different sections of the documentation.
11. Use Table 17-7 and Figure 17-11 as the starting point for a discussion on the various training modes. Prepare an example that utilizes several modes, so students can see how training varies by mode. For example, how would training for an order processing system operator look if the training were a tutorial? If it were a formal course? If it were provided by a local expert (e.g., the operator at the next station)? If it were embedded in the order processing software?
12. Have students create a test plan for the order processing system training program mentioned in Classroom Idea 11, using all training modes listed in the question.
13. Have students include a detailed training plan in the user documentation they turn in as part of their semester projects. Have at least one group (or student) present its training plan in class.
14. Ask your students to compare and contrast the different types of user support discussed in the chapter. For a particular system or job, which types of support would they, as users, prefer and why? Use this in-class discussion to develop recommendations on when to use the different forms of user support.
15. Invite an IS professional from a local organization to your class to discuss how his organization manages user documentation, training, and support. Ask this guest to discuss such topics as: how documentation is tested, who manages updates and distribution of updated documentation, how is updating documentation coordinated with updating the software, what training methods does the organization employ, who conducts the training and how are trainers trained, how much does the organization spend on information systems training as a percentage of the total IS budget or IS development budgets, how much does the organization spend on information systems support as a percentage of the total IS budget, how have the help desk and information center functions changed over time, and what is his experience with EPSS?
Answers to Key Terms
Suggested answers are provided below. These answers are presented top-down, left to right.
11. Inspections / 10. Information center5. Desk checking / 18. Stub testing
7. Electronic performance support system (EPSS) / 16. Phased installation
23. User documentation / 20. System testing
6. Direct installation / 14. Internal documentation
22. Unit testing / 21. Support
12. Installation / 3. Beta testing
8. External documentation / 17. Single location installation
1. Acceptance testing / 2. Alpha testing
19. System documentation / 9. Help desk
15. Parallel installation / 4. Computing infrastructure
13. Integration testing
Answers to Review Questions
1. The deliverables from coding, testing, and installation are: (1) from coding, code and program documentation; (2) from testing, test scenarios and test data, and the results of program and system testing; (3) from installation, user guides, user training plans, and installation and conversion plans.
2. The testing process involves testing code for errors and functionality. The testing process, guided by a detailed testing plan, can begin as soon as modules are coded and proceeds in parallel with the rest of the coding process. Modules are tested individually and then as parts of larger programs and parts of larger systems.
3. Structured walkthroughs for code are organized but informal reviews of code, led by a project manager or chief programmer, where the code’s author presents what has been written to a panel of reviewers. Their purpose is to find errors. Walkthroughs are different from code inspections in that walkthroughs focus on logic while inspections focus on finding well-known errors peculiar to the particular programming language in which the code was written.
4. The four approaches to installation are direct, parallel, single location, and phased. With the direct approach, the old system is turned off, and the new one is turned on. In the parallel approach, both systems are run until management decides the old system can be turned off. In single location, the system is tried out in a pilot project at one location and then implemented elsewhere if the pilot is successful. With the phased approach, the new system is brought on-line gradually, usually function by function. Parallel is usually the most expensive due to the redundant costs, and direct is usually the most risky due to the potential hazards if the new system fails. An organization decides on which approach to use depending on the scope and complexity of the change and the organization’s risk aversion.
5. Conventional wisdom is that implementation success depends on user participation and managerial support.
6. Several factors are important to the successful implementation of a system, including management support, the involvement of users, and user expectations. Additionally, commitment to the project, commitment to change, and extent of project definition and planning are important. Commitment to the project refers to managing the project so that the problem being solved is well understood and the target system actually solves the problem. Commitment to change means being willing to change behaviors and procedures. Project definition and planning means more extensive planning is more effective than less extensive. Lucas (1997) identified two methods for determining if implementation has been successful: the user’s satisfaction with the system and the extent to which the system is used. Factors influencing the extent to which the system is used include user’s personal stake, system characteristics, user demographics, organization support, performance, and satisfaction. Descriptions of these factors are provided on page 601 in the text.
7. As mentioned in the previous question, Lucas identified two methods for determining if an implementation has been successful: the user’s satisfaction with the system and the extent to which the system is used. Lucas further identified six factors that influence the extent to which a system is used; these are user’s personal stake, system characteristics, user demographics, organization support, performance, and satisfaction. Figure 17-13 illustrates the relationships these factors have to each other. An analyst will have more control over certain factors (system characteristics and level of support); however, the analyst will not have direct control over the demographics of the user, personal stake in the system, management support, or problem urgency. This model points out that the analyst should balance the factors that she cannot change with those factors that she can change.
8. Political models of the implementation process take into account the unequal levels of resources and power that exist in implementation situations. These power and resource differentials can explain why certain implementation processes turned out the way they did. Political models recognize that people tend to be parochial, putting the interests of themselves, their friends, and their departments ahead of the interests of the organization as a whole. Political models can explain implementation in a way that factor models cannot, given the different perspectives and assumptions of both types of models. Like any competing model, political models can provide insights that factors models cannot.