70-358 Chapter 20, Part 2 70-358

Gantt Chart A Gantt chart is a project scheduling technique that divides each project into activities with estimated start and completing times.   A Gantt chart is a bar chart with project activities on the left and time across the top. For each activity, a bar of expected time is drawn. As activities are completed, the bar is filled in. The Gantt chart makes it easy to eyeball the chart and understand the current status of a project. But the chart does not show the relationship between activities like the PERT chart does. 70-358

Figure 20-3 page 625 is an example of a Gantt chart. 70-358

70-358

Another one, using slightly different info re the bird house project as provided above for the other PERT example, is provided below. 70-358

70-358

Complete Problem 20.7 as another example. 70-358

CONSIDERATION OF BEHAVIOURABLE ASPECTS OF CHANGE Proceeding with systems development involves consideration of the impact of the change on the organization including those that work within it. It is a common occurrence to have development negatively impacted by resistance of employees involved. There are potentially significant costs associated with this and thus it is important to consider as part of any project involving significant change. The text provides guidance to understand and hopefully minimize such problems. 70-358

The best system will fail without the support of the people it serves and thus the behavioural aspects of change are crucial. You need to be aware of and sensitive to the types of behavioral problems that can result from change. Employees will tend to view change as good if they believe it will affect them positively and vice versa. 70-358

Why Behavioural Problems Occur To minimize adverse behavioural reactions, one must first understand why resistance takes place. Some of the more important factors include the following:   Personal characteristics and background. Generally speaking, the younger and more highly educated people are, the more likely they are to accept change. Manner in which change is introduced. Resistance is often a reaction to the methods of instituting change rather than to change itself. 70-358

Experience with prior changes Experience with prior changes. Employees who had a bad experience with prior changes are more reluctant to cooperate when future changes occur. Top-management support. Employees who sense a lack of top-management support for change wonder why they themselves should endorse it.   Biases and natural resistance to change. People with emotional attachments to their duties or coworkers may not want to change if those elements are affected. 70-358

Disruptive nature of the change process Disruptive nature of the change process. Requests for information and interviews are distracting and place additional burdens on people. These disturbances can create negative feelings toward the change that prompted them to occur. Fear. Many people fear the unknown and the uncertainty accompanying change. They also fear losing their jobs, losing respect or status, failure, technology and automation.   70-358

How People Resist AIS Changes Major resistance often takes one of three forms: aggression, projection or avoidance. 70-358

Aggression is behavior that is usually intended to destroy, cripple, or weaken the system’s effectiveness. It may take the form of increased error rates, disruptions, or deliberate sabotage.   Projection involves blaming the new system for any and every unpleasant occurrence. To preserve the integrity of the system, these criticisms must be controlled or answered. Dealing with problems through avoidance is a common human trait. One way for employees to deal with a new AIS is to avoid using it in the hope that the problem can be ignored or that it will eventually go away. 70-358

Preventing Behavioural Problems People’s reactions to change can be improved by observing the following guidelines:   Meet users’ needs. It is essential that the form, content and volume of system output be designed to satisfy user needs. Keep communication lines open. Managers and users should be fully informed of system changes as soon as possible. - What changes are being made? - Why? - How it will benefit them? - Who to contact with questions? 70-358

Maintain a safe and open atmosphere Maintain a safe and open atmosphere. It is imperative that everyone affected by systems development have an attitude of trust and cooperation. If employees become hostile, it’s an uphill battle you probably won’t win. Obtain management support. When possible, a powerful champion, who can provide resources for the system and motivate others to assist and cooperate with systems development, should be appointed. 70-358

Allay fears. The organization should provide assurances that no major job losses or responsibility shifts will occur. If that is not going to be the case, then the organization needs to mitigate the impact on employees affected so that other employees will remain supportive. Solicit user participation. Those who will use or be affected by the system should participate in its development by providing data, making suggestions and helping make decisions. 70-358

Provide honest feedback Provide honest feedback. To avoid misunderstandings, users should be told which suggestions are being used and how, which suggestions are not being used and why, and which ones will be incorporated at a later date. Make sure users understand the system. Effective use or support cannot be obtained if users are confused about or do not understand the system. Don’t underestimate training needs. 70-358

Humanize the system. System acceptance is unlikely if individuals believe the computer is controlling them or has usurped their positions. Describe new challenges and opportunities. System developers should emphasize important and challenging tasks that can be performed with the new system.  Reexamine performance evaluation. Users’ performance standards and criteria should be reevaluated to ensure that they are satisfactory in view of changes brought on by the new system. 70-358

Test the system’s integrity Test the system’s integrity. The system should be properly tested prior to implementation to minimize initial bad impressions. Avoid emotionalism. When logic views with emotion, it rarely stands a chance. Emotional issues related to change should be allowed to cool, handled in a non-confrontational manner, or sidestepped.   Present the system in the proper context. Users are vitally interested in how system changes affect them personally. 70-358

Control users’ expectations Control users’ expectations. A system is sold too well if users have unrealistic expectations of its capabilities and performance. Be realistic when describing the merits of the system. Keep the system simple. Avoid complex systems that cause radical changes. Make the change seem as simple as possible by conforming to existing organizational procedures. 70-358

FOCUS 20-4 on page 629 provides an example of the resistance to change that the U.S. Department of Defense experienced in trying to update its information systems. 70-358

SYSTEMS ANALYSIS As we saw in Figure 20-1, the first phase in the systems development life cycle is Systems Analysis. The work done (or not done) at this point often determines the success of the project. As we have seen earlier, regularly projects have to go backwards to redo work that was not properly done with resulting delays and increased costs. 70-358

Individual projects may be planned, coordinated, and scheduled in the entity’s master plan for systems development or alternatively may arise on an as needed basis. At some point there must be documentation of the indicated needs and management must approve proceeding with analysis of each potential project. 70-358

The five steps in the analysis phase and their objectives are shown in Figure 20-4 on page 631. 70-358

70-358

Initial Investigation An initial investigation is conducted to screen projects. During the initial investigation, the exact nature of the problem(s) under review must be determined (sometimes what is thought to be the cause of the problem is not the real source). The project’s scope (what it should and should not seek to accomplish) also must be determined. 70-358

If a project is approved, a proposal to conduct systems analysis is prepared. The project is assigned a priority and added to the master plan (the proposal will be modified as more information becomes available). At the point in time the project proceeds, the development team will begin a survey of the existing AIS. 70-358

As an illustration, column 1 of Table 20-3 on page 632 provides an example representative of the information in a proposal to conduct systems analysis. 70-358

Systems Survey During the systems survey, an extensive study of the current AIS is undertaken. This is usually not a small exercise and in larger projects may take months to complete. 70-358

The objectives of a systems survey are as follows: Gain a thorough understanding of company operations, policies, and procedures; data and information flow; AIS strengths and weaknesses; and available hardware, software and personnel.  Make preliminary assessments of current and future processing needs, and determine the extent and nature of the changes needed. 70-358

Develop working relationships with users and build support for the AIS. Collect data that identify user needs, conduct a feasibility analysis and make recommendations to management.   70-358

Data can be gathered from: Employees. Documentation such as organization charts and procedure manuals. External sources such as: Consultants Customers Suppliers Industry associations Government agencies 70-358

The advantages and disadvantages of four common methods of gathering data are summarized here and in Table 20-4 on page 632. 70-358

70-358

Will be updated regularly if project continues Feasibility Study: A feasibility study is completed using the information collected to date. Will be updated regularly if project continues Consideration of factors such as: - technical feasibility - financial feasibility 70-358

Information Needs and Systems Requirements: If the project appears to be feasible then the information needs and systems requirements will be detailed. See Table 20-6 for some of the considerations that may be documented re systems requirements. 70-358

70-358

Systems Analysis Report: The final step in Systems Analysis is to summarize all the work completed to date in a report that will probably go to the Information Systems Steering Committee for approval or not to proceed to the Conceptual Design phase and for assignment of a priority among other approved projects. 70-358

70-358