This is a summary of a poster session presented at the 1993 CAUSE Annual Conference held in San Diego, California, December 7-10. It is the intellectual property of the author(s) and may not be published without permission. Disseminating the material otherwise is permitted, provided that the author(s) and the original presentation of the 
paper at CAUSE93 are acknowledged. 


       SELECTION PROCESS FOR THE UNIVERSITY OF IDAHO'S 
              ADMINISTRATIVE COMPUTING SYSTEM   

By:  Ron Smith
Director of Business and Accounting Services
University of Idaho

The following will provide a methodology the University of 
Idaho used to select an administrative computing system.  The 
steps involved in the process included identification of the 
problem, the creation of a strategic direction and timeline, 
discovery of what was possible, evaluation of alternatives, 
determination of philosophies, creation of the request for 
proposal and selection and implementation.


STATEMENT OF THE PROBLEM

The university had been criticized in recent reports and 
committees for inadequacies in the present system.  Notable 
inadequacies included the following:

1.The lack of a database management system (DBMS) making the 
sharing of data elements between applications a difficult 
task.  Data such as "names" were stored in several different 
applications and not easily maintained or consistent within 
the university community.

2.The expense and difficulty of maintaining the current 
administrative software.  Because the system was based on 
numerous applications tied together with COBOL programs, any 
changes in one system may cause an unanticipated change in 
another system.

3.The legacy system were inflexible, slow and incapable of 
providing the information needed to provide management a 
basis for informed decisions on a timely basis.

4.There was a lack of many necessary and required 
applications.  Either the systems were not available or so 
inadequate that departments were required to maintain "shadow 
systems" in order to provide accurate and timely information.

5.A lack of integration and commonalty between administrative 
computer systems and academic systems caused the lack of 
information needed for tasks such as departmental 
administration and student advising.



STRATEGIC DIRECTION AND TIMELINE 

For nine months the administrative computing committee met on 
a weekly basis the charge to identify administrative 
computing needs and recommend solutions.  Membership included 
personnel from all administrative areas on campus and 
representation from the instructional and academic areas.  
The committee identified five stages to compete in order to 
accomplish its charge:

1.    Discover Stage
2.    Evaluation Stage
3.    Directional Stage
4.    Request for Proposal Development
5.    Selection and Implementation Stage

The committee set an ambitious, but achievable, timeline to 
complete the first four stages in nine months.

Discovery Stage

During the discovery stage, the committee concentrated on 
activity that would identify as many alternatives as possible 
to meet the administrative computing needs of the university.  
Activities included a review and valuation of the existing 
system, inquiries to other institutions of similar missions 
and student populations, vendor software demos and 
administrative computing conferences, invitations to UI 
faculty with expertise in applicable areas to give seminars 
on modern computing technologies and functionality required 
in an administrative system.  As a result of these efforts, 
the committee identified the committee establisheda 
philosophy that included the following:

     1.    Customer service focus
     2.    Open system architecture
     3.    use of GUI and SQL technologies
     4.    Relational Database Management system

Evaluation Stage

Using the information obtained and philosophies established 
in the discovery stage, the committee evaluated several 
alternative solutions.  The alternatives included keeping the 
current in-house developed system writing the missing 
applications, requiring the in-house applications already 
developed and purchasing a database management package, 
purchasing a database management package and buying the 
application modules from many different vendors, or 
purchasing a database management package and buying the 
majority of applications from a single vendor, and developing 
the missing modules in-house.

Alternatives were evaluated on the following goals:

     1.    Meet 90% plus of the administrative needs.
     2.    Position UI to take advantage of Client/Server 
           technology
     3.    Establish the university as a leader in use of 
           computer system solutions
.
     4.    Provide a fully integrated solution.

Directional Stage

The evaluation of results shoed the development of an in-
house system to meet all the needs of the campus required too 
many resources and would take too much development time.  The 
vendor supplied alternative appeared to be more feasible 
based on the cost of the systems and the ability to achieve 
the philosophies and goals of the committee in a timely 
manner.

Request For Proposed (RFP) Development

Using the previously identified functional requirements, 
separate software and hardware FRPs were developed that 
included the goals, direction and philosophies of the 
university along with any unique departmental requirements 
identified in the needs analysis.  Included in the philosophy 
of the RFP was the establishment and commitment of the vendor 
to enter into a long term partnership with the university.

Selection and Implementation

After evaluation of the RFPs and on site visits by all 
acceptable vendors, a software vendor was selected.  Later, 
the same evaluation process along with performance benchmarks 
were used to select a successful bidder for the hardware.

An implementation schedule was developed to take advantage of 
natural cycles during the year.  For example, the finance 
module will be brought on line at the end of a fiscal year, 
the human resources model will be "live" at the beginning of 
a calendar year, and the student module will be "live" on an 
academic year boundary.




Selection Process for the University of Idaho's 
Administrative Computing System
By:  Ron Smith
Director of Business and Ac


Date Revised: 02/27/94 (bdz)