Session 4 – Systems Development Controls

1. Session 4 – Systems Development Controls • Risks in systems development • Systems development process • Systems development controls EECS4482 2016

2. “You must be the change you want to see in the world.” - Mahatma Gandhi EECS4482 2016

3. Some Statistics on Project Failures • 40% of projects are not completed • 70% of projects are behind schedule or over budget • 80% of projects fail to deliver all of the expected benefits Source: The Gartner Group EECS4482 2016

4. Runaway Project • A large private company wrote off $5 million of systems development cost when the new CEO determined that a system that had been under development for 2 years was not going to make it. This led to firing of executives, layoff, bonus cancellation and a pay freeze. EECS4482 2016

5. Runaway Project EECS4482 2016 The Heathrow Airport Terminal 5 new baggage handling system produced wrong flight status information to the baggage crew. This resulted in bags not getting loaded to the right planes. This cost the airlines $50 million in lost profit.

6. Runaway Project • After more than four years of hard work and half a billion dollars spent, Trilogy, FBI’s project to modernize its technology infrastructure, has had little impact on the Bureau's antiquated case-management system, which today remains a morass of mainframe green screens and vast stores of paper records. As Senator Judd Gregg observed, "the software, which runs the hardware, is a huge problem. EECS4482 2016

7. Reasons Organizations Fail to Achieve AIS Acquisition Objectives • Lack of senior management attention. • Shifting user needs. • Lack of standard project management and system development methodologies. • Resistance to change. • Lack of user participation. • Inadequate testing and user training. EECS4482 2016

8. Risk Factors in Systems Development • Incomplete implementation – high because of the magnitude of a typical project. EECS4482 2016

9. Risk Factors in Systems Development • Implementing unauthorized system – High because of the different stages at which authorization should be sought. • Implementing inaccurate system – high because of complexity. • Untimely implementation – high because of magnitude. EECS4482 2016

10. Systems Development Controls • A controlled systems development process is required to mitigate the risks of incomplete, inaccurate, unauthorized, untimely or inefficient systems development. • This process should be documented in a standard corporate systems development methodology that emphasizes documentation, justification, approval, review, monitoring, user involvement and testing. EECS4482 2016

11. Required Phases of Systems Development • Problem recognition • Feasibility study • System proposal • Analysis of existing system • Project planning • User requirement definition – includes application controls EECS4482 2016

12. Phases of Systems Development • System architecture – includes general controls • System design – expands application controls • Install infrastructure in development and test environments. • Programming • Testing EECS4482 2016

13. Phases of System Development • Policies and procedures • Training • Install production infrastructure • Conversion and implementation • Post-implementation review EECS4482 2016

14. 1. Recognition of a need or problem • New services may be required for customers • There may be a need to keep up with the competition • Government regulations, changing business conditions or simply the passage of time may result in the need for massive changes EECS4482 2016

15. Problem Recognition • Business area responsible • IT should be involved • Management has to approve before the next phase EECS4482 2016

16. Feasibility Study • Operational – Can the organization structure accommodate a new solution? • Technical – Does the organization have the technical reach to develop and operate the solution? • Financial – Does the organization have the financial means to develop, acquire and operate the solution? • Financial feasibility is the most important as operational and technical feasibilities affect finance. EECS4482 2016

17. Feasibility Study • A “champion” or “sponsor” is emotionally and organizationally committed to the system • Key is the manager’s and organization’s attitude toward their employees and the fit with the organizational culture EECS4482 2016

18. Feasibility Study • Business area responsible • Not applicable for regulatory related problems like HST or IFRS • IT should be involved • The system sponsor (system owner) has to approve EECS4482 2016

19. System Proposal • Business area should prepare. • Includes proposed solution. • Includes business case. • Management approval, many levels depending on $ of initial cost + annual net cost. • Annual net cost does not include increase in revenue or cost reduction that are subject to uncertainty. It is net only of the sure cost reductions. • May have to go as high as IT steering committee or even the board. EECS4482 2016

20. Business Case • Be wary of soft savings like salary savings, will position be redeployed or eliminated? • Discount for uncertainty caused by timing remoteness. • Project size increases risk of benefits not materializing. EECS4482 2016

21. Business Case • Business area should prepare. • Finance should review. • Be wary of intangible benefits, which are usually more uncertain. • Cost avoidance is more certain. • Cost reduction (operation) is less certain as it is harder to take things away than to refuse to give in the first place. EECS4482 2016

22. System Analysis • Systems analysts should perform, report to project manager. • Project manager is appointed by project sponsor who is the system sponsor. • Project manager should approve. EECS4482 2016

23. Devise a Project Plan • System sponsor appoints project manager • The project plan includes a broad plan for the entire development, as well as a specific plan for needs analysis—the next acquisition step. The project plan typically includes: • Estimated project scope. • Recommended acquisition team structure, members, and leaders. • Subsequent phases and timetables. • Required tasks. • Required personnel skills. • Sources of required information. • Estimated analysis costs. • Timetable and estimated costs for the entire acquisition and implementation. EECS4482 2016

24. Project Plan • Should include a GANTT chart that depicts the required tasks by phase, who do what and when, and how much resources, and what deliverables. • This is an extremely useful tool for monitoring project progress. EECS4482 2016

25. GANTT Chart EECS4482 2016

26. PERT Chart • This tool shows project activity dependencies. Useful to assess the impact of failed or late activities. • PERT stands for project evaluation and review technique. • This chart displays the critical path, i.e., the path of predecessor dependent activities that will take the longest duration. Any delay in an activity on this path will delay the project. EECS4482 2016

27. Sample PERT Chart EECS4482 2016

28. Project Plan • Project manager prepares. • Reviewed by business areas and CIO. • Approved by project sponsor. EECS4482 2016

29. Effective Project Management • A risk management program to identify and handle risks associated with each project. • Division of the project into manageable chunks, often called phases. Phases should be subdivided into steps, and steps into tasks. • Documentation and approval of work accomplished in one phase before working on the next phase. EECS4482 2016

30. User Requirements • Detailed and in writing, prepared by user representatives. • Should include application controls. • IT department should review. • Should define the system’s processing logic • Signed off by IT department (including security) and stakeholders. EECS4482 2016

31. Requirements documentation • This is a detail-oriented stage • Types of information prepared includes: • Info required • Functions required • Input protocols • Reports • Screen layouts EECS4482 2016

32. System Architecture • Define system boundary. • Define infrastructure, hardware, system software. • Will system be Internet enabled? • Network diagrams EECS4482 2016

33. System Architecture • What locations will system operate in and support? • Focuses on infrastructure • Responsibility of the IT department, signed off by project manager, business areas and IT security. • Should include general controls. EECS4482 2016

34. System Design • Design system logic, input requirements and output to meet user requirements in the context of the system architecture. • Includes file layout, database design, report layout, system narrative, entity relationship diagram, and system flowcharts. • Focuses on system functions. EECS4482 2016

35. System Design • Based on user requirements so can be carried out concurrently with architecture. • Entity relationship diagrams used to show relationship between entities (tables) for database design. • Detailed narrative points that expand user requirements, e.g., providing the detailed formulae for construction cost calculation. EECS4482 2016

36. System Design • Performed by designers. • Expand application controls in terms of audit trail and how controls are exercised by the system and people. • Reviewed and signed off by user representatives, project manager, IT security and programming manager. EECS4482 2016

37. Flowchart EECS4482 2016

38. Entity-Relationship (E-R) Diagram EECS4482 2016 AIS, 2014

39. Programming • Considered to be a technical process that creates a functional system based on documented requirements • There is also a creative element involved in successful programming EECS4482 2016

40. Testing • Types of testing: • Unit • String • System integration • Acceptance • Testing may be done by programmers, quality assurance personnel or users EECS4482 2016

41. Testing • Unit testing – one program at a time, done by programmer, done in personal libraries and development environment. • String testing – several related programs together, done by programmers and peers, in the development library (environment). • Integration testing – Entire system or a major part of a system, done by independent testers, in the test library and environment. Signed off by user areas, project manager, IT security. EECS4482 2016

42. Policies and Procedures • User procedures • Accounting procedures • Computer Operations procedures • Update disaster recovery plan EECS4482 2016

43. User Acceptance Testing • User acceptance testing – Entire system + procedures + user interfaces + user environment + system capacity, done by user representatives. This is the most comprehensive level and the last gate in testing. Includes testing for compliance with policies. Will repeat the more important functions tested in system integration testing. Signed off by project sponsor, project manager and IT security. • Performed in the staging library and environment (live simulation). EECS4482 2016

44. Training • Training plan • Training material • Classroom sessions • Self-helped training EECS4482 2016

45. Conversion and implementation • Conversion planning • Conversion testing • Conversion • Conversion verification EECS4482 2016

46. Conversion and implementation • Several conversion and implementation methods • Parallel • Direct cutover • Pilot study • Phased EECS4482 2016

47. Parallel Approach • Runs the new system and old system concurrently. • Safest but costliest. • Not practical for real time systems. EECS4482 2016

48. Pilot Approach • Implements the new system on selected business units to test the water. • Retail outlets may use it on one store.- • If the water is OK, full scale implementation. EECS4482 2016

49. Phase Approach • Implement the new system by functions. • Gradual implementation. • May be less practical for integrated systems. EECS4482 2016

50. Direct Cut-over • Full scale implementation. • Quickest but riskiest. • OK if fallback is readily available. • Increasingly popular because of increasing use of e-commerce or integrated systems and increasing IT power to facilitate quick fallback. EECS4482 2016