1. 70-358
Chapter 20, Part 2
70-358

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

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

4. 70-358

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

6. 70-358

7. Complete Problem 20.7 as another example.
70-358

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

26. 70-358

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

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

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

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

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

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

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

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

35. 70-358

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

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

38. 70-358

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

40. 70-358