System Implementation

1. SystemImplementation

2. Software and Hardware Acquisition Recognize Need, Appoint Committee and/or Project Manager: For large systems, the majority of the appointed committee members should be users from functional areas and end users, joined by information technology staff. Throughout the process committee members should represent their constituencies.

3. It should inform and seek advice and input from a broad spectrum of users, and from specialists such as technical support staff, Procurement, and legal staff. The committee as a whole should represent the entire business committee to be affected by the software.

4. Software and Hardware Acquisition cont… Define Procurement Process: This document is comprised of policy, practices, principles, and recommended procedures. How these apply to a specific software or hardware acquisition should be addressed with Procurement.

5. Software and Hardware Acquisition cont… Define General Needs and Develop Budget Projection: General needs should be identified based on the problems to be solved as well as what could reasonably be expected to be available in the marketplace. Care should be taken to avoid defining needs too narrowly too early in the process. Preliminary budget projections may cover only the cost of hardware/software and a general estimate of other expenses.

6. Software and Hardware Acquisition cont… Investigate the Market: Investigating the market may involve site visits, communication with other institutions using the product, vendor demonstrations, or a Request for Information (RFI). A broad base of potential vendors should be given an opportunity to participate.

7. Software and Hardware Acquisition cont… Refine the Budget and Identify a Funding Plan: Before proceeding with the project, a refined budget plan should be prepared which covers all costs of consulting, acquisition, licensing, hardware, additional staffing, implementation, testing, training, maintenance, and upgrades, for a three to five year period.

8. Consideration should also be given to costs of integration with existing systems, and to savings which may be obtained from phasing out systems that are no longer needed. Identify funding sources and obtain appropriate approvals.

9. Software and Hardware Acquisition cont… Define Detailed Needs: A thorough needs analysis of software capabilities should be conducted. For example, for a Human Resources system, this analysis should encompass the needs of functional staff (such as Human Resources), end users (such as general departmental users), and technical staff (such as IT staff responsible for maintaining the system).

10. Software and Hardware Acquisition cont… The analysis should distinguish between required and desired capabilities and should also cover such things as maintenance, support, training, upgrades, existing or proposed hardware, and the computing infrastructure. If necessary, the budget plan should be revised.

11. Software and Hardware Acquisition cont… Prepare and Issue an Request for Procurement (RFP): If not determined to be a sole source, an RFP should be prepared based on the required (and desired) capabilities identified in the needs analysis.

12. Items to be included are: life cycle costing, maintenance, service / support, availability, implementation schedule, installation/training, financial viability experience of company,

13. price (basis), the evaluation process and criteria, documentation to be provided by vendor, source code escrow(third party), example contract, options such as lease/purchase. Evaluation criteria, points and process should be identified.

14. Software and Hardware Acquisition cont… Evaluate Bids or Proposals: Evaluation methods should be summarized in the specifications, and evaluations should be conducted by a designated evaluation committee. For major acquisitions, a Procurement representative should observe and advise the evaluation committee regarding the evaluation process.

15. Software and Hardware Acquisition cont… In addition to reviewing technical and financial responses in the written proposals, activities that may occur as part of the evaluation process include: product demonstrations, site visits, contacting references, determining responsiveness (e.g. all questions answered, required submittals provided, e.t.c.). The evaluation process must be well documented.

16. Software and Hardware Acquisition cont… Negotiate Contract Language: Typically the hardware/software vendor will provide a contract to be used. A Procurement representative, and if appropriate, a committee designee will work with the Legal Office to remove or modify language which is unacceptable to the institution, and to add provisions to safeguard the institution’s interests.

17. Software and Hardware Acquisition cont… Obtain Final Approvals: Appropriate approvals should be sought and availability of funds verified. Execute the Contract: With the proper approvals, the contract should be executed.

18. Software Acquisition Dynamics Commercial-Off-The-Shelf (COTS) software is commercial available software. • The supplier might not be willing to modify and the customer has no control of the quality of the software. • The vender controls the maintenance of the software • Delivery time is immediate • Cost is less

19. Software Acquisition Dynamics… Modified-Off-The –Shelf (MOTS) The supplier is willing to modify the software according to customer requirements Customer is in control of maintaining the customized part Delivery time depends on the modification requirements Cost depends on the modification requirement

20. Software Acquisition Dynamics… Full developed software Customer has full control of maintenance and quality of the software The cost could be high Delivery time long Could follow water fall method of analysis, design, code and test. Or extreme programming of developing by iterations (incremental) whereby a subset of the requirements is developed in each iteration. Method of development depends on project

21. Outsourcing Software Development Can outsource software development • when the services are not available in-house. • If it is cheaper • If high quality software is required • Lack of resources

22. Challenges of Outsourcing Could lose control over the software, risk is high due to competition Do not build internal competence Development costs could exceed the budget Time schedule could be overrun The outcome might not meet expectations Some projects could be canceled before end of development period Customer might not take active part in development

23. Challenges of Outsourcing cont… Focus of client could be more on administrative activities rather than technical issues Creeping scope - customer keeps adding and changing scope and functionality Team working on many projects at a time Introducing new and sophisticated technical solutions rather than simple and proven technology Performance levels poorly set, qualitative rather than quantitative No user involvement –important for usability and functionality of the product

24. Challenges of Outsourcing cont… Lack of discipline of the development team – reverting to ad hoc development Unrealistic expectation form the client – having an impossible schedule and/or being unaware of the limitations of the technology being used Lack of effective communication channels – unable to reach the right people in a timely manner Conflicts in the team The above problems can be avoided by proper software acquisition management

25. Implementation Phase • Conduct System Test • Testing of software packages, custom built programs, and any existing programs that comprise the new system to ensure they work together • Task involves Analysts, owners, users and builders

26. Implementation Phase…. • System Analysts- communicates test problems and issues with project team members • System owners and Users – determine if project is operating correctly • System builders – involved in system testing • System tests may result in program modification

27. Implementation Phase…. • Prepare conversion plan • Using design Specification for new system, system analyst prepares a detailed conversion plan • Plan identifies, databases to install, end-user training and documentation to develop and conversion strategy from old system to new system. • Tasks facilitated by project manager

28. Implementation Phase…. Installation strategies for conversion plan • Abrupt cut-over / Direct: On a specific date old system is converted and new system starts to operate; • High risk approach as system may encounter major problems not yet known, • No transition costs • Is necessary when policy changes or if system can only be implemented at a given date

29. Implementation Phase…. • Parallel Conversion: Both Old and New system are operated at the same time period • Allows detection and solving of problems in new system. Final cut-over may be abrupt or gradual. • Strategy minimizes risk of major flaws in new system • Costs incurred in running two systems over the period. • Increased demand on computing resources

30. Implementation Phase…. • Location Conversion: If the system is to be used in several geographical locations, it is converted at one location first. Once approved in one site, it’s then rolled to the rest. (done either thro’ abrupt or parallel conversion) Others can be cut-over. First site usually called beta test site • Staged Conversion: It’s a variation on the abrupt and parallel conversions. • Each successive version of the new system is converted as it is developed. Can be done either thro’ abrupt, parallel, or location strategy.

31. Abrupt cutover Parallel conversion Location conversion Staged conversion Implementation Phase….

32. Implementation Phase…. • The Conversion plan typically includes a systems acceptance test plan; • Systems Acceptance test is the final system test performed by end users using real data over extended period. It’s extensive test and covers 3 levels; • Verification testing (Alpha testing) :- running system in simulated environment using simulated data. The simulation looks for errors and omissions regarding end-user and design specifications as earlier specified but may have not been fulfilled during construction.

33. Implementation Phase…. • Validation testing (beta testing):- runs system in live environment using real data. Several things are tested here as follows: • Systems performance - is throughput and response time for processing adequate to meet normal processing workload?; If not programs can be written to improve efficiency or hardware may be replaced or upgraded

34. Implementation Phase…. • Peak workload processing performance- can the system handle workload during peak processing periods? If not, improved hardware and / or software may be needed to increase efficiency or processing; consider doing some of less critical processing during nonpeak periods. • Human engineering test :- is the system as easy to learn and use as anticipated? If not, is it adequate? Can enhancements to human engineering be deferred until after the system has been placed into operation.

35. Implementation Phase…. • Methods and procedure test :- during conversion, the methods and procedures for new system will be put to their first real test. Methods and procedures may have to be modified if they prove to be awkward and inefficient from users opinion. • Backup and recovery testing:- all backup and recovery procedures should be tested. This includes simulating data loss disaster to find and error in recovery procedures.

36. Implementation Phase…. • Audit testing – certifies that the system is free of errors and is ready to be placed into operation. Audit not required by all organization, but many firms use independent audit or quality assurance staff that certify systems acceptability and documentation before the system is placed into final operation.

37. Implementation Phase…. • Install Databases • To place system into operation you need fully loaded databases. Hence installation of databases • Purpose of the task is to populate the new system’s databases with existing data from old system. • System builders are required in this activity i.e. programmers write special programs to extract data from existing databases and populate new databases

38. Implementation Phase…. System analysts and designers only perform role of calculating database sizes and time required to perform installation. Main output restructured existing data populated in new system.

39. Implementation Phase…. Train Users Change to new system requires system users to be trained and documentation provided to guide through the new system. One on One or Group training may be conducted. Group training encouraged System analysts provide end-user documentation and training for system users but must be supported by system owners

40. Implementation Phase…. • Conversion to New System • After conversion, the ownership of the system is transferred from analysts and programmers to the end users. • Analysts completes task by carefully carrying out the conversion plan. • This involves completing a systems audit • Task involves System owners, users, analysts, designers and builders. Project

41. Implementation Phase…. • manager oversees the conversion plan • System owners provide feedback regarding their experiences with the overall project. • System users provide feedback on actual use of the new system. • The feedback may be used by system analysts, designers and builders to correct shortcomings. Thus an operational system is placed into production process of business.

42. Post Implementation Review A Post-Implementation Review should be scheduled some time after the solution has been deployed. Typical periods range from 6 weeks to 6 months, depending on the type of solution and its environment. The PIR is intended to be an assessment and review of the final working solution.

43. There should have been at least one full processing and reporting cycle completed. It should not be performed while the initial snags are still being dealt with or while users are still being trained, coached and generally getting used to its operation.

44. Post Implementation Review… There is often a difference of opinion as to who should perform the Post-Implementation Review. Usually, members of the project team will want to complete the review as a natural extension of their responsibility to deliver optimum benefit from the solution. They understand what was required, what was changed, how it was achieved, how things are supposed to work, how to fix problems, etc.

45. There is a converse argument that the review should be performed by an independent team. This reduces the risk that any errors or omissions of the project team might equally be overlooked in their review.

46. Post Implementation Review… A solution is to do both. An independent audit team, working in consultation with the business users and project team, could examine whether the results are satisfactory. The project team might then reconvene to consider that input and also to examine how to generate further value from the solution. A cost/benefit analysis of the system should be done.

47. Post Implementation Review… Post Implementation should include such questions as: Is the required functionality available? Have users received adequate training and coaching to take advantage of the new facilities? Are staffing levels and skill sets appropriate for the actual workloads? Are staff displaying appropriate attitudes to get the best out of the system (confidence in its capabilities, belief in its purpose, willingness to make it work, etc)? Are third parties such as customers and suppliers satisfied with the service?

48. Post Implementation Review… Is data integrity being maintained within the system and in relation to other integrated or interfaced systems? Are systems controls being applied correctly? Is the system able to process transactions at an adequate speed? Does the system have the capacity to deal with the actual peak loadings as encountered and foreseen? Are staff following operational procedures including backup, recovery, security and disaster recovery?

49. Post Implementation Review… These questions will be investigated through a combination of investigative techniques including interviews, examination of documentation, performance statistics, hands-on tests and checks, etc. Implications and potential remedial options would then be assessed and evaluated. The findings and recommended actions would be prepared, normally in the form of a report or presentation.

50. SYSTEMS SUPPORT