Indiana University

Financial Aid System

Implementation: Success or Failure
 Indiana University
 Since 1998, Indiana University has been working to
retire systems, some of which are more than 20 years
old, in favour of PeopleSoft Enterprise
 Glitches were encountered during the $52 million
PeopleSoft Inc. software implementation at the major
eight-campus Midwestern university system in 2004
 About 5% (3000 students) were denied Financial Aid
that was already pledged
 Origin of problem

 Caused by interface issues between the loan systems at

lending institutions and the PeopleSoft application.
 More “sensitive” to exceptions than the legacy system
was
 Although the system is centralized, it had to take into
account variables throughout the different campuses,
including the differences between part-time and fulltime
students or multiple lenders.
Half Full
 Half Full
Norma Holland
 States that glitches aren’t the “result of the system
proper”
 Apparently surfaced only “at those places where fine-
tuning was needed to align the university’s business
processes to the system specifications and functionality”
 Start of Classes limited the time for comprehensive
testing and staff training
PeopleSoft Spokesperson Steve Swasey:
 “Indiana is a happy customer, and they’re saying its an
internal issue and not with the software”
 “Complex roll-out and we are working closely with
them”
 “Will continue to support them all throughout the
implementation”
Half Empty
 Half Empty
 System – an amalgamation of software, processes, and
people
 Work processes aligned to the system processes and that
users be trained in a timely manner - far ahead of the
delivery of the technology
 “Run away triggers” for system testing and end user
training should have been implemented.
 Interface testing should have been investigated as part of
the planning process
 Scope parsing - chunking a big module into smaller,
progressive scope modules not done.
 3000 students who have been negatively impacted have
not been taken into account, when stating the university
as a “Happy customer”
 Making a Difference. . .
 System Analysis

 Prototyping

 End User Development

 System Testing

 Training

 Different forms of Conversion between systems

 Post Implementation Review

10-8
Systems Analysis
 An in-depth study of end user information needs
 That produces functional requirements that are used as
the basis for the design of a new information system
 Detailed study of the information needs of a company
and end users.
 The activities, resources, and products of one or more of
the present information systems being used.
 The information system capabilities required to meet
information needs of users and stakeholders
 End users are important members of the development
team

10-9
Prototyping
 The rapid development and testing of working models
 Used in design phase
 Especially useful when end user requirements are hard
to define
 Can be used for small and large systems
 But if system is large, usually prototype just parts
 Develop quickly
 Refine until acceptable

10-10
End User Development
 ISprofessional plays a consulting role
 End user does his/her own application development

 Contrast in traditional life cycle:

◦ End user is customer
◦ IS profession does development

10-11
Systems Implementation
 Hardware and software acquisition
 Software development
 Testing of programs and procedures
 Conversion of data resources
 Conversion alternatives
 Education and training of end users and specialists who
will operate a new system

10-12
Implementation Process

10-13
System Testing
 Testing and debugging software
 Testing website performance
 Testing new hardware
 Review of prototypes of displays, reports and other
output

10-14
Training
 End users must be trained to operate new system
 Educate managers and end users in how the new
technology impacts the company’s business operations
and management

10-15
Conversion

10-16
Direct Conversion
 Turn off old system; Turn on new system

 Direct is least expensive method ; Riskiest method

 Inthe case of Indiana University, direct conversion was

implemented .
 So compatibility issues could not be taken into account.

10-17
Post-implementation
review
 Ensure new system meets the business objectives

 Periodic review or audit

10-18
Violated project management
best practices
 Poor or no due diligence.
 No user training.
 Absence of system status alerts.
 System interface problems were ignored.
 The complex project wasn’t broken down into
progressively delivered smaller chunks.
Thank You