Request for Proposal

BACKGROUND AND GENERAL REQUIREMENTS

o Purpose
o General Information
o General Requirements
o Minimum Qualifications and Requirements
o The University of Tennessee
o University Organization

NEW SYSTEM REQUIREMENTS AND DESIRED FEATURES

o Introduction
o System Component Descriptions
o General System
o General Architecture Requirements
o Security Requirements
o Workflow Requirements
o Auditing Requirements
o Financial System
o Chart of Accounts Subsystem Description
o General Ledger Subsystem Description
o Grants and Contracts Subsystem Description
o Accounts Receivable Subsystem Description
o Accounts Payable Subsystem Description

o Purchasing Subsystem Description

o Equipment Inventory Subsystem Description
o Investments Subsystem Description
o Contract Processing Subsystem Description
o Budget System
o Budget Development Subsystem Description
o Salary Budget Subsystem Description
o Human Resources Management System
o Human Resources Data Management Subsystem Description
o Payroll Subsystem Description
o Time and Attendance Subsystem Description
o Insurance Subsystem Description
o Flexible Benefits Subsystem Description
o Retirement Subsystem Description

REQUEST FOR PROPOSAL (RFP) PROPOSER

INSTRUCTIONS AND INFORMATION

o RFP Schedule of Events

o Questions and Responses
o Proposal Submission Requirements
o Proposal Format and Submission Requirements
o General Proposal Format Requirements
o Proposal Sections and Format Requirements
o Proposal Transmittal Letter Format Requirements

o Proposer Qualifications, Experience and Client References

o Format Requirements
o Proposer Qualifications Format Requirements
o Proposer Experience Format Requirements
o Proposer Client Reference Format Requirements
o Technical Approach Format Requirements
o Proposer Cost Requirements
o Proposer Agreements Requirements
o Proposal Submission Requirements
o Proposal Evaluation
o Proposal Evaluation Purpose
o Proposal Evaluation Criteria
o Proposal Evaluation Process
o Proposal Evaluation Method
o Minimum Proposal Requirements
o Proposer Background and Qualifications Criteria
o Technical Architecture and Features Criteria
o Reference Checks Criteria
o Supported Functions Criteria
o Scripted Product Demonstrations Criteria
o Site Visit Criteria
o Cost, Terms and Conditions Criteria
o Contract Terms and Conditions Requirements

o Contract Requirements
o Proposer Representation
o Payment Schedule
o Clarification
o Written Clarification
o Oral Clarification
o Right to Negotiate
o Contract Award
o Contract Format
o Insurance Requirements
o Licenses Requirements
o University of Tennessee Contact Person for This RFP
o Communications Regarding the F=RFP
o Communications Type
o University Response
o Proposal Preparation Costs
o Proposal Withdrawal
o Proposal Errors
o Assignment and Subcontracting
o Right to Refuse Personnel
o Independent Price Determination
o Multiple Proposal Submissions
o Prohibited Actions

o Conflict of Interest
o RFP Amendment and Cancellation
o Right of Rejection
o Proposal Rejection
o Restriction of Rights
o Informalities
o Tennessee Records Law
o Severability
o Location and Work Space
o Software Escrow Agreement
o Special Terms and Conditions
o Interpretations and Addenda
o Contract Violation
o Contract Approval
o Hold Harmless
o Independent Contractor
o Contractor Payments
o Equal Opportunity
o Insurance Requirements
o University Liability
o Compliance with Laws
o Governing Laws
o Terms and Conditions Conflicts

o Information Requirements
o Prices
o Cancellation
o Qualified Personnel
o General Proposal Conditions
APPENDIX 1 - System Requirements
APPENDIX 2 - General Architecture Requirements
APPENDIX 3 - Security System Requirements
APPENDIX 4 - Workflow Requirements
APPENDIX 5 - Auditing Requirements
APPENDIX 6 - Chart of Accounts Subsystem Description
APPENDIX 7 - General Ledger Subsystem Description
APPENDIX 8 - Grants and Contracts Subsystem Description
APPENDIX 9 - Accounts Receivable Subsystem Description
APPENDIX 10 - Accounts Payable Subsystem Description
APPENDIX 11 - Purchasing Subsystem Description
APPENDIX 12 - Equipment Subsystem Description
APPENDIX 13 - Investments Subsystem Description
APPENDIX 14 - Contract Processing Subsystem Description
APPENDIX 15 - Budget Development Subsystem Description
APPENDIX 16 - Salary Budget Subsystem Description
APPENDIX 17 - Human Resources Data Management Subsystem Description
APPENDIX 18 - Payroll Subsystem Description
APPENDIX 19 - Time and Attendance Subsystem Description
APPENDIX 20 - Insurance Subsystem Description

APPENDIX 21 - Flexible Benefits Subsystem Description

APPENDIX 22 - Staffing Subsystem Description
APPENDIX 23 - Retirement Subsystem Description
APPENDIX 24 - Proposal Parts
APPENDIX 25 - Chart of Accounts Description

TIMELINE

DEMONSTRATION SCRIPTS

VENDOR DEMONSTRATIONS

1. Background and General Requirements

1.1 Purpose
The University of Tennessee intends to secure a contract to purchase software to
replace the University's Financial, Budgeting, and Human Resource legacy
systems. The purpose of the Request for Proposal (RFP) process is to define The
University of Tennessee's minimum requirements, solicit proposals, and gain
adequate information by which The University of Tennessee may evaluate the
software and services offered by Proposers. The RFP provides directions and
details necessary for Proposers to complete a comprehensive and competitive
proposal for meeting The University of Tennessee's Financial, Budgeting, and
Human Resource information needs. Proposers must reference the functions
defined in Appendices 1 through 23 to determine if their products meet the
requirements of The University of Tennessee.
The RFP is part of a competitive procurement process which helps serve The
University of Tennessee's best interests. It also provides Proposers with a fair
opportunity for their products and services to be considered. The process of
competitive negotiation being used in this case should not be confused with the
process of competitive sealed bidding. The latter process is usually used where the
goods and services being procured can be precisely described and price is
generally the determining factor. With competitive negotiation, however, price is
not required to be the determining factor, although it may be, and The University
of Tennessee has the flexibility to negotiate with multiple proposers to arrive at a
mutually agreeable relationship.
1.2 General Information
The successful proposer must meet the minimum requirements set forth in the

body of this document and attached appendices. The requirements are related to
and define how the University's business and administrative functions are
managed.
1.2.1 General Requirements
A. This Request for Proposal (RFP) invites qualified Proposers to submit
proposals for providing the following products and services to The University of
Tennessee (University):
1.

Comprehensive computer software to support the University's Financial,

Budgeting and Human Resource Management Systems;

2.

Appropriate and complimentary data warehousing, query, reporting,

OLAP and decision support tools;

3.

Integrated system administration facilities including navigation, security,

workflow processing, auditing and job scheduling;

4.

Comprehensive user and technical training on these systems, tools and

facilities;

5.

Ongoing technical support for these systems, tools and facilities;

6.

Ongoing software maintenance of these systems, tools and facilities;

7.

Comprehensive and complete documentation for these systems, tools and

facilities; and,

8.

Optionally, ORACLE relational database management system server

software, application development and administrative tools adequate for
the support of these systems in an environment of the size, complexity
and user base of the University.

Additional requirements and specifications for these products and services are
provided below.
B. The University reserves the right to reject any and all proposals, waive any
informalities in the proposals received and accept any proposal that, in its opinion
may be in the best interest of the University. The University is not obligated by law
or policy to accept the lowest cost proposal.
C. Proposals must be submitted (one original and thirteen copies) by 2:00 p.m.
(Eastern Time) November 14, 1998 to:
The University of Tennessee
Office of Business Services
Purchasing Department
2200 Andy Holt Avenue
ATTN: RFP # 00016
D. Any questions about the requirements of this proposal must be forwarded in
writing and forwarded via FAX to Mr. David Marks, Buyer at FAX# 423-9742973.

1.2.2 Minimum Qualifications and Requirements

Eligibility to respond to this RFP is based on the Proposer's ability to meet the
minimum qualifications and requirements listed below. Proposals that are received
and do not meet these qualifications and requirements will not be given further
consideration. The University reserves the sole right to decide whether or not
proposals meet these minimum eligibility standards:
1.

All proposals must be received on, or before, the time and date specified
in 1.2.1-D above. The original must be signed and dated by an individual
authorized to enter into a binding agreement in the name of the Proposer
and all third party vendors, if any, incorporated in the proposal.

2.

Proposers must be responsive in their submission by completely

submitting all information designated and requested within all sections of
the RFP. Proposals will be presented in a logical and precise manner.
Anything the Proposer deems essential to the successful implementation
of the proposed application software and services for which no provision
is made in the specifications should be stated in the proposal. Failure to
provide all requested information may eliminate the proposal from further
consideration.

3.

Negative or unfavorable references or site visits may be used as grounds

for rejection of a proposal.

4.

Proposers must agree to participate in a scripted demonstration of their

software product offerings at Knoxville Tennessee at a date and time
mutually agreeable to the University and the Proposer. The University
will provide the processing scenarios to be demonstrated by the Proposer
two weeks prior to the agreed upon demonstration date. All expenses for
this presentation will be borne by the Proposer.

5.

The Proposer selected must be a going business concern and must have
provided similar products and services to other educational institutions,
government agencies or organizations of comparable size and complexity
to The University of Tennessee for at least three (3) years. If requested the
selected Proposer should be able to prove a history of financial stability
and strength that would lead the University to expect the Proposer to
remain a viable business during the contract and service period. Selected
financial ratios such as liquidity ratios may be analyzed to determine the
Proposer's financial strength and may be grounds for the rejection of any
proposal.

6.

If third party software and/or third party services is included in a

proposal, the Proposer must assume contractual responsibility for the
products or services provided by the third party(s).

7.

The Proposer must be primarily a provider of computing software.

8.

All application systems software, facilities or software tools (the system)

proposed must be, as a minimum, fully operational within and compatible
with the University's planned computing infrastructure. Appendix 1
provides a list of requirements Proposers must meet.

1.3 The University of Tennessee

Founded in 1794, The University of Tennessee is dedicated to its land grant

mission of teaching, research and public service. The University is a multi-campus

comprehensive state university system that includes a central administration; four
campuses; the institutes of agriculture, public service and space; a medical center;
and an agricultural extension service in each of Tennessee's ninety-five counties.
Educational opportunities for more than 45,000 students are offered annually on
the University's four campuses at Chattanooga, Martin, Memphis, and Knoxville
and at the UT Space Institute in Tullahoma. Degrees are offered at every level
including professional degrees in dentistry, law, medicine, pharmacy, and
veterinary medicine.
The central administration (University-wide Administration) provides overall
leadership for the University system and provides supporting services such as
budgeting, financial, human resource, facilities planning, alumni and development,
graphic arts, internal auditing, legal, management consulting, and transportation
for the individual campuses and units.
The budgeting, financial, and human resource supporting services consist of
centralized consolidated budgeting, accounting, disbursements, cash management
and investing, payroll, and employee benefits administration for 22 separate budget
entities within the University.
1.3.1 University Organization
The University of Tennessee is one of two public higher education systems in
Tennessee. It is governed by a Board of Trustees appointed by the Governor of the
State. The Board meets three times a year. The responsibility for the day to day
operations of the University is vested in the University President and his staff. The
President's staff consists of an Executive Vice President and Vice President for
Business and Finance; a Senior Vice President; the General Counsel; the Treasurer;
Vice Presidents for Health Affairs; Agriculture; Development and Alumni Affairs;
the Space Institute; and Public Service, Continuing Education and University
Relations; and the Chancellors at Chattanooga, Martin, Memphis, and Knoxville
campuses.
The system proposed must support the University and its campuses and units for
financial, human resource, and budget processing. It must be scalable to provide
adequate response time and performance over the University's network, including
its dial-up connections, for these administrative systems with the following
representative attributes:

2,000
500
50,000
60,000
25,000
100
2,000
5,000
100,000

enrolled users, statewide;

concurrent users, statewide;
accounts, chart of accounts;
vendors;
person payroll, including student employees;
daily requisitions and purchase orders;
daily disbursement vouchers;
new hires annually, and
employee records.

2. New System Requirements and Desired Features

This section describes the requirements and features for a comprehensive system to
assist The University of Tennessee in managing its financial, budgeting, and
human resources. Functions, both required and desirable, are described in this
section as well as in appendices 2-23. The overall technical and business
environments in which the system will function are described below.
2.1 Introduction
The system selected by the University must be functionally rich. Implementation,
particularly in terms of data entry, data access, and reporting, must be supported at
all campuses and units. Such a broad user community fosters the need for diverse
functionality. Since the current University of Tennessee systems are functionally
complex with extensive data management and reporting functions, it is essential
that functionality not be lost in the move to a new information system.
Functionality can be subdivided into four major areas: general system, financial
system, budget system, and human resources management systems. Each of these
systems includes several subsystems and many functions. The following sections
provide a brief overview of each subsystem included in the request for proposal.
Each subsystem requires a Proposer response to specific requirements which are
provided in the appendices.
Standard and ad hoc reports and a user-friendly query language are critical to the
system. Specific reporting features and needs are covered in each subsystem
description included in this document. Separate sections provide specific
requirements in terms of security, workflow, implementation and training.
2.2 System Component Descriptions
2.2.1 General System
The General System includes the architecture for the University's Financial,
Budgeting, and Human Resources Management Systems, and includes the
following requirements:
2.2.1.1 General Architecture Requirements
The University of Tennessee has certain requirements defined for systems to be
considered for the 21st Century Systems project. The basic requirements are that
the new product should be three-tier client/server technology built on a UNIX or
Windows NT system with an Oracle database (8.0 or higher). In addition, the client
pieces should have minimum maintenance requirements and have a minimum
affect on the network, that is a small bandwidth requirement. The applications
should run successfully over a modem rated as low as 28.8 baud.
The applications should provide options that compliment the way the University
conducts business. The applications should be running in production at an
institution or organization of a similar size to The University of Tennessee. The
applications should also be configured to allow enhancements and those
enhancements should work with little or no effort as the application software is
upgraded.
2.2.1.2 Security Requirements
There are several aspects to security, but all aspects address the need to restrict data

access to those who have a need to know. The three basic levels of
security are user authentication, network encryption, and information
authorization. Each of these aspects of security is important to The University of
Tennessee.
User authentication is always a challenge because there are various levels of need
for authentication, some more restrictive than others. The University must have
assurance that the person connecting to the system is who they say they
are user authentication, network encryption, and information authorization. Each of
these aspects of security is important to The University of Tennessee.
User authentication is always a challenge because there are various levels of need
for authentication, some more restrictive than others. The University must have
assurance that the person connecting to the system is who they say they are. The
University has always relied on a user ID and a related password to meet its needs.
Additional options to require password changes periodically, to restrict user
passwords, or to enhance the authentication process with add-on features should be
available.
Network encryption will also be important with some systems. It is important to
the University that an ID and password combination is not extracted from the
network. Where feasible, other data must be secure as it travels the network.
Information authorization is the most complex issue of all the security issues. This
issue covers a person's ability to use a set of processes as well as restricting them to
a subset of data and actions if needed. This task must be completed without
requiring a large staff to maintain all the security requests. The system should have
the ability to group people and processes so that a group of people can be
authorized to a group of processes. The system must restrict what data can be
viewed based on the value of a field or groups of fields. And the system must
control what action a person can perform on any given process, such as view only,
update, or add.
Security should be integrated into the application in a seamless manner. The
system should have the ability to add or take away security in a dynamic manner
without affecting the application. The maintenance interface with security should
be easy to use, and should be subject to delegation either in its entirety or on a
restricted manner to others in the organization. For example, a campus must have
the ability to assign responsibility to authorize access for that campus only.
2.2.1.3 Workflow Requirements
The University of Tennessee is working toward a reduced paper environment. A
major aspect of this effort is for new applications and systems to be handled
electronically for sharing information or for getting approvals. Any system
purchased must have a flexible and substantial process to support electronic
approval workflow.
Workflow of approvals must be based on the University's organizational structure.
Generally, University accounts determine the person or position who provides the
approval. The structure of the University will need to be predefined so all
workflow will proceed properly. Maintenance of the base structure tables should be
minimized so that only major structure changes require approval requirement
changes. Normal employee turnover should be anticipated and handled internally.

Several features for workflow are important. A proxy should be allowed based on a
time period. However, there should also be an option for unlimited proxy. There
should be an option to notify a person or position without requiring an approval for
information purposes only. Notifications should occur both through the system and
through an e-mail interface. All documents requiring approval (or simple
notification) should be found in a common location.
The workflow process must also be flexible to allow University personnel changes.
Workflow must support electronic data, but it should also allow images or other
attachments to explain or document the data further. The ability to "drill" down to
the detail for information should also be supported.
2.2.1.4 Auditing Requirements
All new or modified systems must have audit trails and Window/PC software for
data retrieval, reporting, and analysis. The audit trail should enable complete
tracing of any or all transactions, so that problems or incidents may be investigated
and resolved.
The audit trail should incorporate all information determined necessary by
management, including the old and new values of changed information and related
data, the time of the logged transaction, and the responsible user. Enabling the
tracing function should be selective and modifiable so that management should be
able to specify at any time what transactions or events are considered significant in
order to minimize performance degradation due to additional processing
requirements.
An interface should be provided to allow changes (subject to appropriate access
restrictions) to transaction logging parameters, and any such changes also should
be logged separately. Ad hoc reports should be available (subject to access
restrictions) for selected logged transactions.
2.2.2 Financial System
The University Financial System will consist of the following nine subsystems:
2.2.2.1 Chart of Accounts Subsystem Description
Overview and History
The UT Chart of Accounts provides the basic structure for accumulating and
reporting financial information. It is the basic building block of all the University's
financial system and is relied on by many other University applications including
Payroll, Equipment Inventory, Security, Sponsored Programs, and campus Student
Systems. Currently, the Chart contains approximately 31,000 active accounts
(approximately 63,000 total accounts). The existing Chart of Accounts database is
an IMS database residing on an IBM 3090 mainframe. In addition, there are
"mirror" databases residing on the mainframe in DB/2 format and on the IBM
AS/400.
There are several sources of input for the Chart of Account database. The main
source of information is the Account Changes and Establishment system (ACES),
which resides on the AS/400. It allows entry of new accounts and changes to
existing accounts. The AS/400 data is uploaded to the mainframe each afternoon
and feeds into the nightly Chart maintenance routine. Sponsored Programs
interfaces with the AS/400 system to update budgeted total direct and Facilities and
Administrative costs as their budgets are transmitted to the mainframe. Large-scale

account changes are batched and submitted to the Chart maintenance routine via
CMS.
Needs Analysis
A new Chart of Accounts system should contain all the features of the current
Chart and be expanded to contain certain features for the mutual benefit of end
users and central administration. Previous analyses of the Chart have yielded many
needs, which are outlined in the paragraphs below.
The functionality of the ACES system should be incorporated into the new system.
Copying attributes from existing accounts at establishment time allows for more
efficient use of time. Another mechanism of streamlining entry is the ability to
specify related accounts, allowing for the establishment of several accounts from
one set of attribute data. Capturing data from other databases and generating
attributes based on dependency relationships results in fewer opportunities for
inaccuracies. The real-time edits and the ability to prevent changes to certain
attributes once an account has been set up (for example, the fund group) enforces
integrity in the Chart. The ACES system also provides a paper notification process
through letters that are generated as an account is activated and this functionality
needs to be carried forward. In a new system, it would be preferable for a
notification process to be electronic. Also, the unrestricted access to view account
attributes should continue to be available.
The subsystem needs to provide the ability to create chart structures at levels above
or below the primary account level using techniques such as sub-accounts and
account groupings. Distributed account changes and entry should be available and
the system should include an on-line account request process with electronic
approval and security. Ideally, the system should provide the ability to provide
electronic or paper notification of account activation, depending on the user's
preference. This will eliminate the time delay and extra work associated with paper
documents. A fiscal year designation is needed to allow for flexibility in reporting
as historical reporting is a frequent request and year-end close-out now necessitates
the "holding" of account change requests until the previous fiscal year is closed
and all reports have been produced. The Chart should expand to include several
additional attributes currently stored in the Grant and Contract Invoicing database.
The reporting of Chart information is an important consideration. Currently,
standard Chart reports are generated and published on the Web on a regular basis.
In addition, requests for specialized account lists occur frequently. The current
method of generating specialized reports is by the use of the AS/400 query tool or
the Software AG Esperant tool against the DB/2 mirror. The new system should
either provide a query process or be accessible by a standard query tool.
2.2.2.2 General Ledger Subsystem Description
The General Ledger is the repository for the University's accounting data. The
current General Ledger is very sound and provides strong controls and support for
the centralized accounting function. The University is readily able to produce
financial statements and supporting schedules within the context of current
accounting standards for a university belonging to a governmental entity. The
replacement system should provide the same functionality and controls as the
current system but should also include the following:
1.

Distributed entry at the departmental level

2.

Projection/Speculation transactions

3.

Pre-encumbrance transactions

4.

Better Grant Management support

5.

Flexible reporting and query (available at the departmental level)

6.

Edits to control spending

7.

Expanded size of account number field

8.

Expanded size of currency fields

Support for the General ledger is separated into several areas: Transaction Input,
Edit, and Posting; Monthly Close; and Annual Close.
Transaction Input, Edit, and Posting
The proposed transaction, input, and edit requirements provide the ability to follow
an accounting transaction from its creation in a department to its ultimate posting,
thus eliminating the need for departmental shadow systems. All transactions may
be posted immediately upon successful entry. The ability to provide management
information will be enhanced by the establishment of several new transaction types
(pre-encumbrances, deposits, invoices, projection/speculation). Departmental
bookkeepers will be able to track a purchase requisition from the time the
requisition is entered at the department until a check is written for the purchase.
Another proposed feature is the enhancement of the University's current
classification codes. Expenditure object codes and revenue classification codes
both include optional user defined codes.
The input screens should include a copy feature for use during data entry, the
ability to capture data from other databases, and prompts for selected entry fields.
Other proposed features include the ability to suspend a transaction without losing
any work and the support of recurring transactions. The proposed system will
allow the entry of one side of a transfer voucher and electronically send that
transaction to the other department.
Proposed edits will occur at entry time. Edits will include valid account number,
standard field values, and funds availability (both at the account and object code
level), and University-defined business rules. Since many transaction types are
entered and edited in other systems and passed to the general ledger, the
transaction section will address all transaction types generically and include
specific requirements for transfer vouchers and journal vouchers.
Monthly Close
The proposed requirements for the monthly close specify a system which would
largely duplicate the functionality in the current system, including prompt cutoff
dates, staff benefits distribution, salary encumbrance and facilities and
administrative (F&A) cost calculations, and production of standard reports for
electronic distribution to all departments as soon as final figures are available.
Cutoff dates for entries will be controlled without impeding new month activities.
The system should support closing a period on the third working day of the

following month.
The standard reports at the account level should include:
1.

A general ledger (beginning balance, activity, ending balance)

2.

An outstanding purchase list

3.

A financial summary by object/revenue/classification code

4.

An outstanding encumbrance listing

5.

A management report similar to the ledger which includes projected

expenditures

Actual payroll detail should be printed on the ledger for those accounts that want
it. Campus business offices should be able to electronically access the Monthly
Treasurer's Report, with balance sheet and supporting schedules for each entity. In
addition, a query tool should be provided for accessing information and storing in
alternative formats (such as a spreadsheet). More convenient distribution and
control over number of copies, destination, etc. should be available for all reports.
Historical records should be available in electronic format (e.g. optical disk).
Annual Close
The proposed annual close requirements provide for streamlined operations. Some
features will facilitate the preparation of closing entries. Cutoff dates for entries
will be controlled by individual transaction type and fund group without impeding
new fiscal year activities. Closing entries will be generated to zero encumbrances
and pre-encumbrances, record un-billed accounts receivable, establish accounts
payable, distribute staff benefits by function, and close revenue and expense to the
appropriate fund balance. Reversing entries will be generated automatically as
needed.
Preparation of financial reports should be greatly enhanced. The annual Treasurer's
report should be produced ready for publishing. Additionally, the requirements
provide for generating a complete set of statements for each campus/entity and
special statements for auxiliary enterprises. The requirements also recognize other
year-end cutoffs for situations requiring an alternate fiscal year such as federal
fiscal year.
2.2.2.3 Grants and Contracts Subsystem Description
Overview
The proposed Grant and Contract (G&C) subsystem accounting, invoicing, and
management requirements are intended to enable the University to invoice, track,
and collect sponsors' funding, fulfill governmental, agency, and award financial
requirements, provide effective financial management information to principal
investigators (PI's) and financial personnel, and close project accounts in a timely
manner. As external funding becomes increasingly critical to fulfilling the research
mission, it is important that the University have all the tools necessary to enable its
faculty to successfully compete for these funds. Also, the University must be
accountable to the increasing demands from sponsors and governmental entities for
financial information.

To accomplish these goals, the University's Grant and Contract subsystem should
include the following characteristics. First, it should be an integral part of the
computerized financial system. Second, it should be automated for prompt
preparation of financial reports and invoices, improved flexibility, and improved
communications and response time with bookkeepers, Project Investigator's (PI's),
and sponsors. The subsystem must be capable of electronic invoicing and financial
communication to be responsive to the 21st century environment for sponsored
research. Third, G&C accounting should be flexible to efficiently handle the
hundreds of agency and award-specific financial requirements that do not match
the University's single computerized invoicing method. Fourth, it should be
sophisticated and flexible to keep pace with the increasing burden of governmental
and agency regulations.
Requirements
The G & C subsystem requirements described in this document are divided in the
following areas: (1) account setup, (2) invoicing and financial reporting, (3)
accounts receivable and collection, (4) facilities and administrative costs and cost
sharing, (5) direct cost sharing, (6) letters of credit, (7) effort certification, (8) other
inquiry and reporting, and (9) account closeout.
Producing draft invoices for online revision using various standard and userdefined formats will provide needed flexibility in meeting proscribed agency
formats. This will eliminate the need for manual invoice preparation which is
extensive under the current system. Another feature with similar benefits is the
flexibility to produce automated invoices which exactly meet the terms of the
award. This includes cost reimbursable, fixed or varying amounts on recurring
intervals or specified dates, retainage, and various alternative computations for
F&A costs and cost sharing and direct cost sharing. Requirements regarding
accounts receivable include generating collection letters and statements of account,
providing for flexible aging criteria, allowing for notations of collection efforts,
and automatically posting the accounts receivable entry when an invoice is
released.
The requirements listed for F&A costs provide benefits to end users as well as staff
involved in invoice preparation. Direct cost sharing requires a sophisticated system
to meet the variety of award terms frequently encountered. The ability to cost share
a percentage or flat dollar amount of individual or groups of object codes or the
total expenditures to one or many accounts is one such need. To provide current
and accurate information to end users, the calculation of F&A costs, F&A cost
sharing, and direct cost sharing should be available in real time for sub-accounts or
expenditure accounts and accumulated to balance accounts.
Reporting and inquiry requirements are driven by the needs of many distributed
users. The most important report is a modified expenditure ledger or project
spreadsheet. This report should include all the financial activity related to the
project either in detail for the bookkeeper or in summary for the PI. Another
important report contains detailed information about deficit balances and
recommended action. In addition to the standard reports that can be produced
currently, the system should provide an easy-to-use, flexible query capability. A
compensation effort certification system is necessary to comply with Federal
regulations. In addition to the current features, the new effort certification system
should include features designed to support cost sharing activities.
2.2.2.4 Accounts Receivable Subsystem Description
The Accounts Receivable subsystem records all transactions that are deposited into

the University's bank accounts on a daily basis. It also records any transfers
between bank accounts, debits, and credits that would hit the accounts for any
reason other than a deposit. It includes all wire payments, ACH's, Returned
Checks, and any change to a departmental account. The existing subsystem resides
on the Entrex system and is located in Andy Holt Tower, Knoxville, Tennessee.
The cash receipt requirements provide a methodology to allow departments to
prepare deposit transmittal documents on-line and allow the Central Cashier to
create a cash voucher, CV, by selecting deposits which have been entered without
redundant data entry. The ability of departments to create and track bank deposits
is enhanced by several subsystem features. These features include an on-line edit
for open and valid account numbers at data entry time, entry screens designed to
retain default values based on user security, an edit that requires the amount of the
deposit to equal the account distribution amount, retention of a rejected deposit for
subsequent correction, as well as several helps for the Central Cashier to assist in
the creation of a cash voucher. Also, CV's automatically relieve deposits.
Certain reporting features include the University defined deposit transmittal
document, a bank deposit slip, and related list of checks included in the deposit; as
well as any currently produced cash voucher reports. On-line inquiries include the
ability to follow a deposit from its original entry in the department to its ultimate
posting as a cash voucher.
There are other features used to manage departmental accounts receivable and
returned checks accounts receivable. These features include the ability to create
and post an accounts receivable record on-line, the ability to match an accounts
receivable with a receipt and a browse list of outstanding receivables to help the
departmental user match a receipt to a receivable.
Every department is required by University policy to deposit any monies received
within three working days.
2.2.2.5 Accounts Payable Subsystem Description
The Accounts Payable subsystem (APS) currently allows for entry of over 500,000
invoices, travel reimbursement requests, petty cash reimbursements, etc by users in
the Business Offices of University of Tennessee System. The APS interfaces with
several other systems including Human Resource Information System, Purchasing
subsystem and Financial System. The APS is currently located in the Stokely
Management Center.
The APS can be used to enter payables, batch groups of payables according to
type, and release for check writing. It can also be used to locate and show the
status of any payment that has been entered into the system. Other features include
on-line canceling of checks, on-line viewing/retrieval of invoice and payment
information, and on-line entry and editing of data.
A new subsystem should include, but not be limited to, the ability to provide online entry and edit of data at the departmental level. Electronic approvals and the
flexibility to determine the timing for posting of pre-encumbrances and actual
check writing should also be provided.
2.2.2.6 Purchasing Subsystem Description
The existing Purchasing subsystem resides at The University of Tennessee,
Knoxville campus in the Stokely Management Center on an IBM 370 mainframe
computer. The subsystem presently provides service to University campuses

located at Knoxville, Memphis, Chattanooga, Martin, and Tullahoma. The

subsystem is used to process in excess of 17,000 requisitions, 7,600 request for
quotations/request for proposals and the issuance of over 20,000 purchase orders
annually. The subsystem supports a current vendor base of over 97,000 vendors
and maintains over 1,000 ship to and invoice codes. The subsystem also provides
for commodity codes. As part of the Inventory Management subsystem (IMS), the
Purchasing subsystem interfaces with the Accounts Payable and other financial
systems. An electronic requisitioning application (remreq) with over 1,000
requisitions processed annually also resides on the subsystem.
Viewing and entering by multiple users at remote locations simultaneously is also a
function of the existing subsystem. The current subsystem allows a user to view
the text of a purchase order, see history of payment made against a purchase order
and how much has been de-obligated against the purchase order. It also allows the
user to track a requisition from receipt in the Purchasing Department to purchase
order entry. It allows RFQ entry, bid tabulation and the tracking of bid information
and vendor information.
Auxiliary and supplemental to the IMS Purchasing subsystem, the various campus
purchasing departments maintain other purchasing database applications that are
resident on their respective campus personal computer resources. The information
contained in these databases are relevant and used in support of the purchasing
functions. The following list is an example of the types of data bases maintained at
the various campus purchasing departments: bidder's lists; vendor records with
phone and fax numbers; contract systems with details about specific contracts;
chart of accounts, statement of award; state reports; and commodity code
classifications. These databases are specific to the various campus purchasing
departments and cannot currently be accessed through the IMS system.
2.2.2.7 Equipment Inventory Subsystem Description
Overview and History
The University of Tennessee Equipment Inventory subsystem (EIS) provides the
official records of equipment inventory for accumulating and reporting financial
information. The subsystem was restructured and programmed in RPG and CL
languages in 1989 and placed into production on the IBM AS/400 that resides in
Andy Holt Tower in Knoxville, Tennessee. The Equipment Inventory subsystem is
accessible by different methods of communication using 5250 emulation. The
Controller's Office Equipment Records Section is responsible for maintaining and
controlling the detailed equipment inventory records.
The AS/400 database interacts with the code support databases (for code
translations), the Chart of Accounts database, and other databases to validate entry
data. Controller's Office personnel enter data into the AS/400 system via online
screens. Departmental and campus personnel enter data directly into a suspense
(holding) file that is reviewed by Controller's Office personnel and then released
into the EIS. Data entered into the subsystem creates a composite file and a
component file. The composite file contains basic information about the equipment
such as tag number and location and the component file contains additional
information such as purchase order number and vendor. Currently, the EIS contains
78,999 active inventory records totaling $431,612,706.47 and 82,120 inactive
inventory records totaling $176,063,442.91. The EIS contains inquiries into the
database via several attributes of the equipment and a reporting subsystem to
process the monthly reports and yearly inventories in accordance with state and
federal government regulations.

Needs Analysis
A new Equipment Inventory subsystem should contain all the features of the
current inventory and be expanded to contain certain features for the mutual
benefit of end users and central administration. These features are outlined in the
following paragraphs. The functionality of the EIS should be incorporated into a
windows-based environment. Pull-down menus allow users to be consistent in
accessing data using different connections to the system. This will also increase the
ease of data retrieval, data entry, and data correction. All programs within the
inventory subsystem need to be integrated so updates in one program change the
related fields in other programs within the EIS. The new EIS also needs to capture
data from other databases and generate attributes based on related fields. For
example, equipment gift records processed in the Development Office database
needs to be captured and recorded in the equipment system.
The current method of generating specialized reports through an AS/400 query
tool. The new system must provide a query process or be accessible by a standard
query tool. Year-end equipment inventory reports and year-end equipment
reporting for financial statements are crucial to the new system.
The new subsystem also needs to provide electronic forms and electronic
approvals.
2.2.2.8 Investments Subsystem Description
The University's Investment subsystem is comprised of two distinct software
programs: TrustProcessor for administration and reporting on charitable remainder
trusts held by the University, and the University's internally developed Investment
subsystem for monitoring, valuing, and controlling University invested assets
except cash management assets. (The cash management program does not
currently use a software system other than PC applications which provide the
subsidiary records for the general ledger control accounts.) These two programs
are stand-alone with only reformatted output files interfacing the University's
financial accounting system.
The TrustProcessor program maintains a file of all investments held in the
University's trust funds. All security trading as well as trust distributions, expenses
and income are entered into the TrustProcessor. Calendar year-end trust tax
reporting and filing requirements are satisfied with the TrustProcessor program.
Redundancy exists between data entry in the University Financial System,
Investment subsystem, and TrustProcessor. The TrustProcessor program does not
need to interface with the Financial System at this time. The TrustProcessor system
does need to interface with the Investment System to avoid duplication of data
entry. The University has purchased the import data module for this system, and
interfacing the two systems would require reformatting of data into TrustProcessor
format. The University will continue to use TrustProcessor to meet its trust
administration and reporting requirements.
The University's Investment subsystem monitors all invested asset gifting, buying,
selling, and income reporting. However, this subsystem needs enhancements to
provide needed control features in areas such as custodian/trustee asset totals,
manager billings, and policy compliance. As pointed out in the previous section,
redundancy exists in the entry of data between this subsystem and TrustProcessor,
and between this subsystem and the University's Financial System. System
interfaces needed with the new financial accounting system are in the areas of:

1.

General Ledger

2.

CV's

3.

JV's

4.

DV's

5.

Chart of Accounts

The University Investment subsystem also needs interface capabilities with the
custodian, First Tennessee Bank, for trade, income, etc. data.
Past searches for suitable software have been unsuccessful in a large part because
of the limited functionality needed and difference between commercial portfolio
management processes and University processes. Other universities surveyed have
out-sourced this function or use internally developed systems.
Another subsystem of the Investment subsystem maintains the record of the
number of shares owned by each endowment fund invested in the University's
Consolidated Investment Pool, calculates the number of shares
purchased/redeemed, the equivalent shares for the next quarterly income
distribution, and distributes the income quarterly. This subsystem needs to
interface with the new Financial System in the following areas:
1.

Chart of Accounts

2.

JV's

2.2.2.9 Contract Processing Subsystem Description

The Contract Tracking subsystem (CTS) currently provides electronic tracking of
approximately 6,000 contracts which are processed each year by and for The
University of Tennessee. Currently the CTS is stand alone and does not interface
with any other accounting system, procedure or departmental function. The
subsystem resides on an IBM AS400 located in Andy Holt Tower, Knoxville,
Tennessee. The tracking information can be viewed and entered by multiple users
at remote locations.
The CTS tracks several types of contracts, including, but not limited to sponsored
research, patents, personal service contracts, leases, loan agreements, royalties,
endowments, wills, charitable remainder trusts, University designations as
beneficiary of life insurance policies, licensing agreements, tax deferred annuities,
endowment contracts, scholarships, health care contracts, gift property,
memorandum of agreements, and trademarks. The CTS does not include contracts
issued by Purchasing.
The CTS can be used to track the location of a contract in the review process, its
reviewing status, and the office where it is filed when completely executed. The
subsystem provides the review history for each contract including specific
information concerning the contract, the processing person, the date the contract
was processed, and the dates and the name of the person reviewing and/or
approving the contract.
The CTS allows a user to display contract information by budget entity, agency,
departmental account number, or date range. In addition, reports based on user

queries are available. The Treasurer's Office is the main source for these types of
reports.
A new subsystem should also include contracts issued by Risk Management, price
agreements, and an interface with the sponsored research system to eliminate
duplicate entry functions.
Additional enhancement to the subsystem should include:
1.

Templates for developing standard UT contracts

2.

A summary of text and payment terms for all contracts

3.

Scanning capability for the entire contract

4.

Payable and receivable information

5.

Interface with the University's general ledger

6.

Encumbrance for contracts

7.

Electronic approval path processing

8.

Access and update security similar to the current financial/HRIS system

2.2.3 Budget System

The University Budget System will consist of the following two subsystems:
2.2.3.1 Budget Development Subsystem Description
The current Budget Development subsystem (BDS) is used to prepare the
authorized budget at the beginning of each fiscal year. Two campuses submit their
budget information electronically. However, most campuses and units provide hard
copy, detailed unrestricted current funds, by account number and object codes, to
the Central Office. This information is then keypunched into the BDS. In both
instances, visual edit checks are performed to ensure the data submitted is correct.
All pre-budget preparation is performed outside the current development system
with each campus/unit utilizing internally developed techniques. Budget
adjustments made during the year are handled through budget revisions that update
the Financial Accounting System once approved. Each year the system presents
three formal budgets to the UT Board of Trustees for approval based on July,
October, and April information.
The new Budget Development subsystem should be an on-line subsystem that
allows electronic updates to the General Ledger once proper approvals are
obtained. The new subsystem should also be capable of linking to the Salary
Budget subsystem to obtain personnel and staff benefits budget information.
Budget modeling capabilities will be one new feature the University will look for
in a new system. If such functionality is not available, then campus/units will need
the capability of downloading information to PC and/or other hardware options. If
budget development must be accomplished "outside the system" then the
University must have a means to upload budget submissions. Other features which
are desirable in any new system are the abilities to: (1) access historical
information beginning with the July budget data and subsequent budget revisions
(a minimum at month's end), (2) distinguish recurring budget adjustments from

non-recurring adjustments, (3) adjust budgets daily, and (4) link accounts with
similar purposes (income to expenditure to fund balance for educational and
general, auxiliary enterprises, and restricted accounts; multiple income and
expenditure accounts for reporting at the Dean or Vice Chancellor level). Excellent
report generating tools are a requirement for any system.
2.2.3.2 Salary Budget Subsystem Description
The Salary Budget subsystem (SBS) currently provides campuses and units with
an on-line mechanism to develop a personnel budget, including filled and unfilled
positions and lump sum allocations for the beginning of each fiscal year. In
addition, the subsystem is used to work with mid-year salary increases. The SBS
works with all employee categories (student, faculty, exempt, non-exempt and
other academic) and employee designations (regular, term, student) for both
unrestricted and restricted funds. Currently, both salary and associated staff
benefits costs are calculated by the subsystem with the information being available
at the position level. Management reports are available in summary and detail by
employee, providing position counts, salary, and staff benefit information by fund
type and function. Average salary information by employee category is also
available.
In addition to performing the current features, a new system will need to provide
for continuous budgeting and be capable of maintaining current data for the current
fiscal year, as well as actual expenditure information from the prior year, while
developing budget information for use in the upcoming year. The new system
should also be capable of performing "what-if" analysis for use in preparing budget
information and subsequent budget adjustments, if necessary.
Any new system will need to have a Position Tracking subsystem that is capable of
linking salary budget, payroll information, and personnel functions that are
position driven. Historical data will need to be maintained by the system.
2.2.4 Human Resources Management System
The University's Human Resources Management System will consist of the
following seven subsystems:
2.2.4.1 Human Resources Data Management Subsystem Description
The current Human Resources Information System (HRIS) provides for the
capturing and maintenance of pertinent data about employees and other individuals
who have current or past relationships with The University of Tennessee. The other
individuals include volunteers as well as retired and deceased employees.
Primarily through paper and form-based updates, changes in employee information
are initiated, approved as required, entered and reported in the form of turnaround
documents and online display. As a result, the HRIS databases are a repository of
current information about these individuals and serve as a basis for processing and
retrieval by numerous subsystems and reporting tools.
A new Human Resources Data Management subsystem (HRDM), in terms of data
management and reporting, should permit online entry and update of data by the
employee or by University departments as appropriate, with features of electronic
approval and reporting of activities. The update process should be based on an
event and should present screens containing data related to that event. The event
driven work flow and screen presentation should be user-friendly and as flexible as
possible. The subsystem should exchange electronic data with internal and external
subsystems in order to minimize redundancy. The subsystem should provide all

necessary functionality to insure integrity of data and to provide point-in-time

recovery. The subsystem should provide for maintaining historical data.
The reporting component of the subsystem should have user options for online
viewing or local printing and provide the following:
1.

Scheduled user-defined reports on demand

2.

Standard reports with selection parameters

3.

A friendly end-user query tool which provides for downloading and/or

point-in-time reporting

2.2.4.2 Payroll Subsystem Description

The primary function of the Payroll subsystem is to generate and maintain the
payroll-related data for all employees of the University. This includes the
collection of time, generation of checks and advices, distribution of payroll
materials, and retention of all historical data.
Currently the University's Payroll subsystem supports seven separate payroll
cycles generating in excess of 160 payrolls and 450,000 checks/advices per year.
Total gross pay for 1997 was approximately $620 million. The checks, advices,
and related reports are separated and distributed to each campus. Each campus
payroll office must in turn separate the material by department for local
distribution.
All input to the payroll processes are paper-based with the exception of scheduled
pay and deductions. Historical payment and leave activity information may only be
accessed through batch processes due to the nature of the storage.
Individual processes performed in support of each payroll include:
1.

Time collection

2.

Leave collection

3.

Adjustment collection

4.

Gross pay calculations

5.

Gross-to-net calculations

6.

Deduction/Contribution reporting and remittance

7.

Direct Deposit

8.

Financial Interface

9.

Departmental Report Distribution

10. Maintenance of Payroll History

A new payroll processing subsystem should allow for the decentralized, online
entry of all payroll input as well as remote access to reports, payment history, and

checks and advices. This access should allow online viewing with an optional print
feature.
2.2.4.3 Time and Attendance Subsystem Description
The primary purpose of the Time, Attendance and Special Payments subsystem is
to capture, record and provide to the payroll process all leave, time worked, and
special payments for University employees on a periodic basis. Currently the hours
for biweekly employees are captured through paper, diskette, and external time
reporting systems. In some cases the external time system data must be manually
re-entered into University systems. The leave and pay adjustments for monthly
employees are captured through paper reporting originating at the departmental
level.
A new subsystem should provide for the efficient decentralized on-line entry of
data and the ability to interface with external systems to reduce redundant entry.
Historical data should be maintained and readily accessible for ad-hoc reporting. A
new subsystem should interface with HRIS data to validate data at entry time and
provide for the consistent application of university policies and campus
procedures. Expanded leave reporting and tracking is required for management
review and analysis.
2.2.4.4 Insurance Subsystem Description
The University provides employees and other participants various insurance
programs including, but not limited to: State Medical Plans, Dental, Long Term
Disability, Federal, Interns and Resident and Optional Life. The current University
of Tennessee Insurance subsystem (IS) provides management of insurance
information containing eligibility data, employee and dependent demographic data,
enrollment, coverage and coverage periods, premium history and deductions,
reductions and adjustments internal and external to the payroll system. The
subsystem also provides employee and dependent notification, editing rules,
statistical and accounting reconciliation, and other ad hoc reporting information.
The IS maintains interfaces with HRIS, Payroll, Chart of Accounts and the State of
Tennessee Insurance System (TIS).
Employee eligibility and demographic information are system driven and
submitted by batch processing to TIS. Enrollments are paper driven with
processing by batch and online input. Additional input is often received from state
offices, insurance providers, federal government, and various companies. The
inputs from these sources are processed by batch and online entry. The UniversityWide Payroll Office is the main source of all online entry.
The future IS or enhancements should provide multiple security levels/views to
make insurance enrollment and changes directly accessible for employees and
departments. This interactive subsystem must have the ability to: distribute online
input, improve education and communication, drive payroll deductions/reductions
and contributions, process refunds, maintain coverages and providers, automate
notification/billing procedures, exchange electronic data and premium remittance,
maintain additional data (such as beneficiary information), manage coverage
specific rules, regulations and reporting requirements, and interface with multiple
insurance companies and State and Federal agencies.
2.2.4.5 Flexible Benefits Subsystem Description
The Flexible Benefits subsystem is the primary tool used in administering the
University's medical and dependent care flexible spending account plans. Annual

contract and reimbursement claim information is maintained. The payroll process

accesses this system to determine the proper reductions and reimbursements each
time a payroll is generated.
Staffing entails a broad range of functions at The University of Tennessee. The
most familiar function is the advertising of vacancies and the recruitment and
referral of qualified applicants. Currently in this area, each campus/unit operates
independently of the others. An integrated applicant to employment process is
essential for any new system.
In the case of new hires, the selected applicant should be employed without reentering information previously required through the applicant process. There
should be a tracking mechanism for each set of hiring data from the department
through the payroll process. In a new Staffing subsystem, approval at all levels
should be managed electronically.
In addition to the employment process, the staffing function includes responsibility
for compensation issues such as maintenance of job titles, job descriptions, job
evaluations, salary rate reviews, and salary ranges. All campuses/units share the
same job titles, job class numbers, and generic job descriptions. A user should be
able to access an employee's job title and job class number from the HRMS
Staffing subsystem, and a centralized repository for job titles, job class numbers,
and generic job descriptions should be available. Information should also be
available regarding specific position descriptions and salary range by position.
Other staffing functions include the release of an employee's final paycheck, the
authorization for issuing ID cards, unemployment compensation, workers'
compensation, performance management, benefits enrollment, career development,
staff training, Family Medical Leave records and Americans with Disabilities Act
(ADA) compliance. These functions should be fully automated in any new
subsystem.
Numerous reports are currently generated in the staffing area. These reports should
be easily continued by the HR office or by the department. Status reports of
applicants and employees are an essential component of any new subsystem.
Position tracking is an important aspect of a new Staffing subsystem. Position
tracking can be used as a management tool for planning, budgeting, staffing, and
trend analysis. In addition, position tracking can provide real-time information for
departmental decision making and validation of personnel requisitions.
The position tracking component should be driven and managed by both the
human resources offices and the financial offices. In either case, a position tracking
subsystem must be integrated with the Human Resources Management System.
A new Staffing subsystem would enable the human resources offices to share
pertinent information in a centralized location. The subsystem, however, should be
flexible enough to allow each campus to have campus-specific fields. On-line
requisitions, requisition management, and an automated employment process
would be a part of this subsystem.
The Staffing subsystem should provide an automated career development
component, compensation management system, performance management system,
employee health management system, and an exit process. The new subsystem will
also include on-line entry and update of personnel actions.
Most importantly, a new Staffing subsystem should allow the full automation and

integration of data to create management information. The integration would

involve not only the information within the staffing function, but would integrate
with all other systems, such as finance, data management, benefits administration,
time and attendance, payroll, and salary budget.
2.2.4.7 Retirement Subsystem Description
The Retirement/ Tax Deferred Income subsystem currently provides archived and
current retirement and tax deferred data for all 15,000+ employees of The
University of Tennessee statewide. At present, UT maintains information on seven
different retirement plans and four different TDI plans. The subsystem resides on
an IBM AS400 and is located in Andy Holt Tower, Knoxville, Tennessee. The
AS400 is updated monthly through the electronic interface with the mainframe, on
which HRIS is located, as well as various other sources such as the Tennessee
Consolidated Retirement System (TCRS) and the Optional Retirement Program
(ORP) vendors.
The Retirement subsystem includes information concerning enrollment,
contributions, service, salary, changes in job status, demographics, and
terminations and/or retirement. These data are used to provide estimates of
retirement benefits, plan selection, financial planning tools and reports as
requested.
The tax-deferred program is available to all employees (including student
employees) bringing the number of possible participants to over 25,000. The
subsystem for this program maintains a history of tax-deferred contributions and
flexible benefits to provide accurate, allowable maximum deferrals according to
IRS regulations. Since UT offers four plans, it is critical to incorporate all
combinations to provide maximums for all plans under various scenarios. This
subsystem is also used to monitor and correct over deferrals before the end of the
tax year.
A new retirement and tax deferred income subsystem would, at a minimum,
include all current functions while extending more robust update and accessibility
capabilities. The new subsystem will interface with the new payroll and campus
unique subsystems and outside vendor systems, while providing more accessible,
historic tracking of each employee. Security is critical due to the confidentiality of
the information available.
3. Request for Proposal (RFP) Proposer
Instructions and Information
This section provides the information required to complete a competitive proposal
for the Financial, Budget, and Human Resource Management Systems.
3.1 RFP Schedule of Events
The following RFP schedule of events represents the University's best estimate of
the schedule that will be followed. Unless otherwise specified, the time of the day
for the following events will be between 8:00 a.m. and 5:00 p.m., Eastern Time.
Event

Date

University Issues RFP

Oct. 14, 1998

Deadline for Written Questions and Clarification Requests

Oct. 28, 1998

Written responses to Proposers

Nov. 4, 1998

Time

University opens Proposals

Nov. 11, 1998

Proposal Evaluation Begins

Nov. 12, 1998

3.2 Questions and Responses

To ensure accurate communication in respect to this RFP, the University will
accept questions from Proposers. This will provide Proposers the opportunity to
seek clarification any matters pertaining to the RFP requirements as well as
enhance their understanding of the University's software and computing needs.
3.2.1 Questions
Specific questions concerning the RFP should be submitted in writing by 5:00 p.m.
on October 28, 1998. Refer to Sections 3.6.8, 3.6.9, 3.6.10 and 3.6.11 of this
document for instructions regarding communications about this RFP, including a
contact person and address. All questions must be directed to the following contact
person.
Mr. David Marks
The University of Tennessee
Office of Business Services
Purchasing Department
2200 Andy Holt Avenue
ATTN: RFP # 00016
3.2.2 Responses
Written responses to all pertinent questions will be prepared by the University and
each Proposer will receive a complete set. This will ensure accurate, consistent
responses to all Proposers.
3.3 Proposal Submission Requirements
All proposals must adhere to the following submission requirements:
1.

Proposals must be submitted no later than 2:00 p.m. on November 11,

1998. Failure to submit a proposal as required before the deadline will
result in the proposal being disqualified and returned unopened.

2.

Cost and technical proposals shall be submitted in separate sealed

envelopes and must be identified by filling-out and placing the enclosed
"Sealed Proposal" label on the outside of the envelope in the lower left
corner. Technical proposals will consist of parts 1-6 as defined in section
3.4.2 of this RFP document. The bottom portion of the label must be
completed. If the label provided cannot be used, the RFP number, date
and time of RFP opening and the Proposer's name and address must
appear on the outside of the envelope or box containing the proposal. The
cost proposal shall include all costs proposed for the scope of the services
and deliverables required by this RFP and no cost information can be part
of your technical proposal submission. If the Proposer fails to detail all
cost information for the requirements of the RFP, the University may
determine the proposal to be non-responsive and reject it. Cost proposals
will not be opened at the RFP opening.

3.

It is the Proposer's responsibility to assure that the entire written proposal

is delivered at the proper time and to the address specified in this RFP.
Proposers assume the risk of the method of dispatch chosen. The

University of Tennessee assumes no responsibility for delays caused by

any delivery service. Postmarking by the due date will not substitute for
actual proposal receipt by the University. Late proposals will not be
accepted nor will additional time be granted to any potential Proposer.
Proposals may not be delivered orally, by facsimile transmission, or by
other telecommunication or electronic means.
3.4 Proposal Format and Submission Requirements
3.4.1 General Proposal Format Requirements
Proposals should provide a straightforward and concise description of the
Proposer's capabilities to satisfy the requirements of this RFP. Emphasis should be
on completeness and clarity of content. However, anything the Proposer deems
essential to the successful implementation of the requirements of this RFP (not
included in the University's specifications or requirements) may be included in the
proposal.
Proposers must follow all formats and address all portions of the RFP and provide
all information requested. Proposers may retype or duplicate any portion of this
RFP for use in responding to the RFP, provided that the proposal clearly addresses
all of the University's information requirements. Appendices 1-23 must be
completed as included in this RFP. Proposals must be prepared on standard 8-1/2"
x 11" paper. Foldouts containing charts, spread sheets, and oversize exhibits are
permissible. All responses, as well as any referenced material presented, must be
written in English.
For convenience in preparing a response, a disk containing a response outline is
included with the RFP. This disk is in a WordPerfect (version 7.0) format. Included
on this disk is an outline for a response including Appendices 1-23. Proposers may
use the disk file to prepare response, but all proposals must be submitted on paper.
Electronic files will not be accepted. It is essential that no changes be made to
Appendices 1-23 other than the addition of explanatory notes as described in the
instructions included with them. Any change or deletion of any item in the
appendices may disqualify a proposal.
Proposals must not contain extraneous information. All information presented in a
proposal must be relevant and in response to a requirement of this RFP, must be
clearly labeled and, if not incorporated into the body of the proposal itself, must be
referenced to the appropriate place within the body of the proposal. Any
information not meeting these criteria will be deemed extraneous and will not be
considered in the evaluation process.
3.4.2 Proposal Sections and Format Requirements
The proposal must be separated into the following parts:
Part 1. Proposal Transmittal Letter: general background information about the
Proposer. (See section 3.4.2.1 of this document for details.)
Part 2. Functional Responses: functional product information. (See Appendices 123 of this document.)
Part 3. Proposer Qualifications: information about the Proposer's qualifications for
providing the requested deliverables of the RFP. (See section 3.4.2.2.1 of this

document for details.)

Part 4. Proposer Experience: information about the Proposer's experience in
providing the requested deliverables of the RFP. (See section 3.4.2.2.2 of this
document for details.)
Part 5. Proposer Client References: information about the Proposer's client
references. (See section 3.4.2.2.3 of this document for details.)
Part 6. Technical Approach: detail of the Proposer's approach for accomplishing
the work requested. (See section 3.4.2.3 for details.)
Part 7. Cost: detailed, line item cost for each deliverable and implementation
consulting hourly rates. (See section 3.4.2.4 for details.)
Appendix 24 is the response form to be used for this proposal. It repeats the
instructions on how to respond to each of the above parts. If there is insufficient
space available for a given response, indicate in the space provided that there is an
attached response and provide a page number where the response can be found in
the attachment. The completed Appendix 24 (with any attachments) should be
attached to the completed Appendices 1-23 and returned as described in section 3.3
Proposer must submit the original and thirteen copies of all parts described in
Appendix 24.
3.4.2.1 Proposal Transmittal Letter Format Requirements
The proposal must include a written transmittal and offer of the proposal in the
form of a standard business letter as Part 1 of the response. The proposal
transmittal letter signatory must be a company officer empowered to bind the
Proposer to the provisions of this RFP and any contract awarded pursuant to it. If
said individual is not the company president, the letter must attach evidence
indicating authority to bind the company. The proposal transmittal letter will
reference and respond to the information requested in this section (section 3.4.2.1).
The letter will clearly:
1.

State that the proposal remains valid for at least one hundred eighty (180)
days subsequent to its submission date.

2.

Provide the complete legal entity name and Tax Identification Number of
the firm submitting the proposal or the complete name and Social Security
Number of the individual submitting the proposal.

3.

Provide the name, mailing address, telephone number, fax number and Email address of the individual the University should contact regarding the
proposal.

4.

State whether the Proposer or any individual who will perform work
under the contract has a possible conflict of interest (e.g., employment by
The University of Tennessee or State of Tennessee) and, if so, the nature
of that conflict. The University reserves the right to cancel an award if
any interest disclosed from any source either gives the appearance of a
conflict of interest or cause speculation as to the objectivity of the offer.
Such determination regarding any questions of conflict of interest will be

within the sole discretion of The University of Tennessee.

3.4.2.2 Proposer Qualifications, Experience and Client References Format
Requirements
Proposals will provide in Parts 3-5 information to evidence the Proposer's
qualifications to deliver the services sought under this RFP, Proposer's experience
with providing such systems, and client references.
3.4.2.2.1 Proposer Qualifications Format Requirements
The information to evidence the Proposer's qualifications to deliver the services
sought under this RFP must be provided in part 3 of the proposal and include the
following items:
1.

A brief, descriptive statement indicating the Proposer's qualifications to

deliver the services sought under this RFP.

2.

A brief description of the Proposer's background and organizational

history including:
A. Years in business.
B. Location of offices.
C. Whether there have been any mergers, acquisitions, or sales of
the Proposer company within the last ten (10) years, and if so, an
explanation providing relevant details.
D. Form of business (i.e., individual, sole proprietor, corporation,
nonprofit corporation, partnership, joint venture, limited liability
company, et cetera).

3.

An organizational chart highlighting key persons who will work with

University officials in providing the deliverables called for in the RFP.
This chart should illustrate the lines of authority and designate the
individual responsible for the delivery of each functional component of
the RFP.

4.

A personnel roster and brief resumes of key people who will work with
the University to deliver each service functional component of the RFP.
The roster should include each individual's title, education, current
position with the Proposer, and employment history.

5.

A statement as to whether the Proposing organization or any of its

employees, agents, independent contractors, or subcontractors who will
directly perform services for The University of Tennessee under a contract
have been convicted of, pled guilty to, or pled nolo contendere to any
felony; and if so, an explanation providing relevant details.

6.

A statement as to whether there is any pending litigation against the

Proposer; and if such litigation exists, an attached opinion from counsel as
to whether the pending litigation will impair the Proposer's performance
in a contract under this RFP.

7.

Documentation of financial responsibility, financial stability, and

sufficient financial resources to provide the scope of services to the

University in the volume projected and within the time frames required.
This documentation will include:
A. A description of the Proposer organization's size, longevity, and
client base.
B. A statement as to whether, in the last ten (10) years, the Proposer
has filed (or had filed against it) any bankruptcy or insolvency
proceeding, whether voluntary or involuntary, or undergone the
appointment of a receiver, trustee, or assignee for the benefit of
creditors; and if so, an explanation providing relevant details.
C. Other pertinent financial information by which The University of
Tennessee may reasonably formulate an opinion about the
relative stability and financial strength of the Proposer. This
information must include the most recent audited financial
statement, or in lieu of such, a banking reference and a credit
rating by a rating service.
3.4.2.2.2 Proposer Experience Format Requirements
Proposers must have experience in furnishing similar services of similar
complexity as requested in this RFP to higher education institutions or other
service organizations of comparable size. The following information must be
provided in part 4 of the proposal to evidence the Proposer's experience in
delivering services as those specified in this RFP:
1.

A brief statement of how long the Proposer has been performing the
services requested through this RFP.

2.

A list, if any, of all current contractual relationships with the State of

Tennessee, Tennessee Board of Regents, and The University of Tennessee
which have been completed within the previous five year period. This
listing should include the contract number, contract term, and procuring
state agency or University department or campus (i.e., UT Knoxville, UT
Chattanooga, etc.) for each reference.

3.4.2.2.3 Proposer Client Reference Format Requirements

Proposer client references must be for Financial, Budget, and Human Resource
Management Systems of similar complexity as requested in this RFP within other
higher education institutions or organizations of comparable size to The University
of Tennessee. Proposals will provide the following information in part 5 of the
proposal:
1.

A client list, including the name of the organization and the version of
your software in production at that organization, as subpart 5.1.

2.

Customer references (as subpart 5.2) for similar Financial, Budget, and
Human Resource Management System projects representing three of the
Proposer's larger accounts currently being serviced and three projects
previously completed. For each reference, include the following
information:

A. The organization's name and business address.

B. The name, title, and telephone number of the organizational
contact person.
C. A brief description of the service provided and the period of
service.
Negative or unfavorable references may be used as grounds for rejection.
3.4.2.3 Technical Approach Format Requirements
Proposer's technical approach must use the client/server model for Financial,
Budget, and Human Resource Management Systems and support Oracle as a
database option. Proposer's technical approach should reflect general trends in
technology and display an interest in continual improvement. The following
information must be provided in part 6 of the proposal:
1.

An "Executive Summary" of the current technologies used by the

proposed systems including client/server types and relational databases
supported, as subpart 6.1.

2.

A comprehensive description of the proposed systems including: release

and version, a list and description of the subsystems (i.e., chart of
accounts, grants, and contracts, payroll, etc.), a list and description of
batch processes and reports included in the system, a description of the
navigation between screens, and a description of how security works
(including how security is maintained), as subpart 6.2.

3.

A description of future technical directions intended for the next release

and beyond, including a short reason why each technology is being
pursued to be part of the proposed product and any company policy or
practice that provides technical directions, as subpart 6.3.

4.

A description of the documentation to be included with the proposed

systems including the medium (i.e. CD ROM, hard copy, etc.) and
number of copies, as subpart 6.4.

5.

A description of the training programs available for the proposed systems.

Indicate all training that is included in the proposal as well as additional
training, locations, and associated costs, as subpart 6.5. (Training
opportunities from sources other than the proposing company should be
included with the name of the training organization provided.)

6.

The types of interfacing and customization techniques available and

recommended with the proposed products, as subpart 6.5. (Both batch and
real-time interfaces should be described including how data entering the
system passes through all the edits required of the on-line data entry.)

7.

A description of data conversion or migration options and

recommendations, including software used, training required, and
estimated effort, as subpart 6.7.

8.

A description of system administration software available with the

proposal and any additional software recommended as a means of
maintaining and running the systems including (but not limited to)

middle-ware, end-user reporting tools, and system administration tools, as

subpart 6.8.
9.

A description of any other items not specified in the above requests which
are required to install, customize, maintain, and run the proposed systems,
as subpart 6.9.

3.4.2.4 Proposer Cost Requirements

Proposers must submit a cost proposal in a separate sealed envelope separate from
the technical parts of the proposal. See section 3.3 for additional information
concerning submission of the cost proposal.
Proposers must provide a comprehensive itemized cost description as part 7 of the
proposal, captioned "Cost." Proposer will itemize costs in accordance with the
deliverables requested in section 3.5.12 of this RFP. If an item is not listed in the
deliverables section for which and additional cost would be incurred, Proposer
must add a line item entitled "Other Costs" and identify the item and the
corresponding cost that would be incurred by the University. The other cost must
also be itemized and be included in the Proposer's submission.
3.4.2.5 Proposer Agreements Requirements
Although highly discouraged, any required agreement (such as license agreements,
etc.) or other information from the Proposer which the University has to review
must be received with the proposal. No agreement will be considered after the
proposal close date.
3.4.3 Proposal Submission Requirement
The Proposer must fully comply with the informational requirements of this RFP
by furnishing a proposal in compliance with the requirements in section 3. Failure
to comply with the RFP information requirements including separate cost and
technical proposal submission requirements may be grounds for proposal rejection.
3.5 Proposal Evaluation
3.5.1 Proposal Evaluation Purpose
The evaluation process used is designed to award the procurement to the proposal
that offers the best combination of attributes based upon the evaluation criteria, as
opposed to the proposal with the least cost.
3.5.2 Proposal Evaluation Criteria
The criteria to be used in Phases I and II of the evaluation will be as follows:
1.

Proposer Background and Qualifications

2.

Technical Architecture and Features

3.

Reference Checks

4.

Supported Functions

5.

Scripted Product Demonstrations

6.

Site Visits

7.

Proposed Cost, Terms and Conditions

3.5.3 Proposal Evaluation Process

The evaluation of the proposals will be a 3-step process:
Step 1: An evaluation team will study the proposals to determine which proposers
meet the minimum requirements set forth in this RFP. Any proposal not meeting
the minimum requirements will be eliminated from further consideration at this
point.
Step 2: Proposals that meet the minimum requirements will be subject to Phase I of
the evaluation. Phase I will consist of evaluating each proposal based on criteria
1B4 (Proposer background and qualifications, technical architecture and features,
Proposer reference checks, and supported functions). Proposals that successfully
complete Phase I will be considered in Phase II of the selection process.
Step 3: Phase II will consist of evaluating and assigning scores to each proposal
based on the evaluation criteria.
3.5.4 Proposal Evaluation Method
Detailed evaluation criteria and questions have been developed for each of the
seven evaluation areas. These criteria will be consistently applied in the evaluation
of every proposal meeting the minimum requirements. A sealed folder with a
description of the evaluation process to be followed will be filed with the Director
of Purchasing before proposals are opened for evaluation and will be available for
review after a successful vendor is selected.
3.5.5 Minimum Proposal Requirements
Minimum requirements have been established that each proposal must meet in
order to be included in the evaluation process (see Appendix 1). Any proposal not
meeting these minimum requirements will be eliminated from consideration during
step 1 of the evaluation process.
3.5.6 Proposer Background and Qualifications Criteria
The Proposer must be able to provide evidence that it is financially stable and has
been in the business of providing financial, budgeting, and human resource
software systems for at least three years.
The University will evaluate this section based on its assessment of the Proposer's
strengths in this area above the minimum requirements.
3.5.7 Technical Architecture and Features Criteria
This section will evaluate the compliance of the Proposer's products with the
specified architectural requirements of The University of Tennessee.
The University will evaluate this section based on its assessment of the proposer's

strengths in this area above the minimum requirements.

3.5.8 Reference Checks Criteria
Each Proposer will identify at least three institutions (or service organizations) that
are currently using the Proposer's financial, budgeting, and human resource
systems in a production mode. The version of the software in use at the referenced
institutions or organizations should be identified. The references provided should
be of comparable size and complexity to The University of Tennessee and be
willing to be contacted by the University. It is preferable that the references be
other universities. Reference checks may be made to any or all of the
institutions/organizations provided by the proposer as well as to any institution
using that Proposer's software.
Reference checks will be accomplished through pre-arranged telephone conference
involving the reference institution/organization and the full evaluation team. One
member of the evaluation team will lead the discussion and ask questions. Each
reference will be asked a predetermined list of questions.
3.5.9 Supported Functions Criteria
A list of desired functions has been identified for each component of the
University's requested Financial, Budgeting, and Human Resource Management
Systems. (Appendices 2-23) Proposers must provide a response indicating whether
or not their products meet each function by checking "Yes", "No", or "Next
release" for each item. "Yes" means the function is included in the current release
of the out-of-the box product (including third party products if the are included in
the bid). This can include table set-ups and user-defined fields built into the
software. "No" means the function is not in the current release of the product. "No"
also includes any changes or additions to application code or Oracle tables,
including writing any SQL queries for which the University is responsible in order
to have the function. "Next release" means the function will be provided in the next
release of the product provided it is deliverable within six months of the proposal
due date.
Each function will have a pre-determined weight assigned by the University. The
score for each function will be determined by multiplying the pre-assigned weight
for that function by the Proposer's response. The total score for each area will be
determined by summing the scores for each function in that section.
3.5.10 Scripted Product Demonstrations Criteria
The top Proposers will be invited to demonstrate their systems at The University of
Tennessee. This demonstration will be a "scripted", interactive demonstration with
University staff present having an opportunity to work with the system. Of
particular interest to the evaluation team will be the ease of use and how well the
software performs the required functions.
Scripts will be written for various scenarios that the University deems to be
critical. These scripts will follow a standard format. Proposers will be presented
the scenarios two weeks prior to their scheduled demonstrations. All
demonstrations will be scored by the evaluation team based on a predetermined set
of questions. Team members will scoring each question on a 1 to 5 basis.
All demonstrations will be held in Knoxville and be attended by the evaluation
team and other selected University staff.

3.5.11 Site Visit Criteria

Each Proposer will identify at least three institutions (or service organizations) that
are currently using the Proposer's financial, budget, and human resource systems in
a production mode. The version of the software in use at each
institution/organization should be identified. These references should be of
comparable size and complexity to The University of Tennessee and may be used
by the University for site visits. It is preferable that the references be universities.
Site visits may be made to any or all of the institutions/organizations provided by
the Proposer as well as to other institutions using that Proposer's software. All site
visits will be made without representatives from the Proposer present.
3.5.12 Cost, Terms and Conditions Criteria
The Proposer should provide detailed pricing and cost information that can be
summarized to category totals. Detailed prices within each category should be
provided were there are options to include or exclude components priced from the
overall proposal. It should be noted when one category is inclusive of another in
the prices quoted.
The categories are:
Application system software
Complimentary query and reporting tools
Integrated system administration facilities
Implementation consulting support
User and technical training
Ongoing technical support
Software maintenance
Documentation
ORACLE RDBMS and related tools
Any other cost
All software license fees -- whether for application software, database or
development and DSS tools -- must be either for the unrestricted enterprise use of
the University (e.g. any number of servers, operating systems or end users) or the
pricing algorithm must be fully explained, the pricing basis specified, and all
incremental cost rates quoted. Preference will be give those specifying enterprise
licenses.
Prices quoted for implementation and consulting support should be on a per hour
basis, exclusive of travel and related living expenses. Categories of implementation
support should be identified based on the background and qualifications of the
consultants providing the support, and priced separately. The Proposer should
estimate the number and mix of consultants needed to support the implementation
of these systems. Prices for training should also be included.
The University of Tennessee reserves the right to separately award the
implementation and consulting portions of the bid.
3.6 Contract Terms and Conditions Requirements
3.6.1 Contract Requirements
The Proposer must be willing to contract with The University of Tennessee in
accord with the University's terms and conditions and other requirements specified
in this RFP. Submission of alternate terms, conditions, or agreements may be

deemed an unsolicited counter offer and be used as grounds for rejection.

3.6.1.1 Proposer Representation
The University will evaluate, rank each proposal, and base an award according to
the representations provided by each respondent. Should the successful proposer
fail to deliver a system(s) or personal services based on the Proposer's
representations to include, but not limited to , the functionality claims (including
the responses to the questions in appendices 1-23) or delivery periods, the Proposer
will be held in default by the University. A Proposer held in default under these
circumstances will be responsible for any additional installation, programming, or
transitioning costs incurred by the University and the costs for any alternate
system(s) and personal services procured by the University.
3.6.1.2 Payment Schedule
A schedule of payments will be negotiated with the successful Proposer. Payment
will be based on performance of the successful Proposer and correspond to
installation and acceptance milestones that are to be negotiated. In no case shall
any payment be made simply upon contract execution.
3.6.2 Clarification
3.6.2.1 Written Clarification
The University of Tennessee reserves the right, at its sole discretion, to request
clarifications of proposals or to conduct discussions for the purpose of clarification
with any or all Proposers. The purpose of any such discussions will be to ensure
full understanding of the proposal. Discussions will be limited to specific sections
of the proposal identified by the University and, if held, will be after initial
evaluation of the proposals. If clarifications are made as a result of such
discussion, the Proposer will put such clarifications in writing. If clarifications are
requested after the Proposal Evaluation Team has scored a subject proposal, the
evaluators may re-score the RFP based on written clarification received from the
Proposer. Refusal to respond to the University's request for clarifications may be
considered non-responsive and be used as grounds for rejection of the proposal.
3.6.2.2 Oral Clarification
If requested, the Proposer will make an oral presentation and demonstration to the
Proposal Evaluation Team and other designated University representatives at the
UT Knoxville campus. All expenses (except for providing space) for the
presentation will be borne by the Proposer. Information gathered from this
presentation may be used to re-score a Proposer's RFP response. Refusal to
respond to the University's request for clarification may be considered nonresponsive and be used as grounds for rejection of the proposal.
3.6.3 Right to Negotiate
Upon evaluation of the RFP, The University of Tennessee has the right to enter into
negotiations with multiple Proposer(s) (not necessarily the Proposer with the
lowest deliverable cost submission) that appear to have submitted a proposal that
meet the needs and requirements of the University. Negotiations could include, but
not be limited to, price and the terms and conditions of this RFP. However, issues
may arise that the University may not negotiate due to state fiscal policies, state
laws, or University policies and an impasse could arise. If for any reason a
Proposer(s) and the University cannot arrive at a mutual agreement that would

result in the issuance of a contract, the University reserves the right to terminate
negotiations, to reject the proposal, and to continue negotiations with other
responsive Proposers that may lead to the issuance and award of a contract(s).
3.6.4 Contract Award
The University of Tennessee reserves the right to issue any resulting contract/order
to the firm whose proposal in the University's judgment most nearly conforms to
the University's requirements, and will best serve the needs of the University as
described herein. The University also reserves the right to award a contract to other
than the lowest cost Proposer if the interests of the University are best served. In
determining the award, the University will consider price, service, financial
capability, compliance with specification/intent and terms and conditions, ability to
perform the requirements of the contract, and any other criteria necessary to
determine the best proposal meeting the University's requirements. The University
reserves the right to waive all technicalities in selecting or rejecting any or all
proposals which satisfy or fail to satisfy respectively, the University's best
interests. The University of Tennessee reserves the right to make an award without
further discussion of any proposal. Therefore, each proposal submitted should
reflect the Proposer's most favorable terms and offer.
3.6.5 Contract Format
This RFP document, the terms and conditions of this RFP and your proposal
submission will be the basis and format of any contract issued as a result of this
RFP. No separate contract document is requested or required.
3.6.6 Insurance Requirements
The successful Proposer will file with the Purchasing Department of The
University of Tennessee, prior to commencing of this contract (or work), an
appropriate certificate of insurance, in duplicate, evidencing compliance with the
insurance requirements contained in the proposal. The certificate of insurance will
name The University of Tennessee as an additional insured under the required
policies of liability insurance set forth in the insurance requirements of these
specifications. The insurance required hereunder naming The University of
Tennessee as an additional insured shall be primary insurance to any and all
insurance that might be in force for the benefit of the University.
The successful Proposer who provides products and services to The University of
Tennessee will provide the University with satisfactory evidence of the following
insurance coverage:
1.

Workers' compensation and industrial disease insurance in the statutory

amounts, and employer's liability in the amount of $500,000.

2.

General liability insurance or comprehensive general liability insurance,

including contractual liability, products/completed operation, and
contractor's broad form liability in an amount equal to $1,000,000
combined single limits of liability.

3.

Automobile liability insurance, including non-owned and hired

automobiles, in an amount equal to $500,000.

Combined single limits of liability: Such insurance will be written by insurers

acceptable to The University of Tennessee and be licensed to conduct business in
the State of Tennessee. The certificate of insurance will indicate whether the policy

or policies of insurance are written on a claims-made or occurrence basis.

3.6.7 License Requirements
Before a contract pursuant to this RFP is signed, the Proposer must hold all
necessary, applicable business and professional licenses. The University of
Tennessee may require any or all Proposers to submit evidence of proper license.
3.6.8 University of Tennessee Contact Person for This RFP
Mr. David Marks
The University of Tennessee
Office of Business Services
2200 Andy Holt Avenue
Knoxville, TN 37996
Phone: (423) 974-0900
FAX: (423) 974-2973
The University has assigned the following RFP number to specifically identify this
RFP - it should be referenced in all communications regarding the RFP:
RFP NUMBER: 00016
3.6.9 Communications Regarding the RFP
Upon release of the RFP, all Proposer communication concerning this procurement
must be directed to the RFP Contact. Unauthorized communications concerning
this procurement with other University employees may result in disqualification.
3.6.10 Communications Type
All communications should be in writing to the RFP contact. Any oral
communications will be considered unofficial and non-binding on The University
of Tennessee. Written questions and requests for clarification must cite the RFP
number. All written requests must be received in accordance with the deadline
specified in the RFP schedule of events.
3.6.11 University Response
The University of Tennessee will respond to written questions and requests for
clarification in writing which will become an amendment to the RFP. Only written
responses to written communications will be considered official and binding upon
the University. The University reserves the right, at its sole discretion, to determine
appropriate and adequate responses to questions and requests for clarification.
3.6.12 Proposal Preparation Costs
The University of Tennessee will not pay any costs associated with the preparation,
submission, or presentation of any proposal.
3.6.13 Proposal Withdrawal
A Proposer may withdraw a submitted proposal at any time up to the deadline for
submitting proposals. To withdraw a proposal, the Proposer must submit a written
request, signed by an authorized representative, to the RFP contact before the

deadline for submitting proposals. After withdrawing a previously submitted

proposal, the Proposer may submit another proposal at any time up to the deadline
for submitting proposals.
3.6.14 Proposal Errors
Proposers are liable for all errors or omissions contained in their proposal.
Proposers will not be allowed to alter proposal documents after the deadline for
proposal submission.
3.6.15 Assignment and Subcontracting
The contractor may not subcontract, transfer or assign any portion of the contract
without prior written approval from The University of Tennessee. Not withstanding
the use of approved subcontractors, the Proposer, if awarded a contract under this
RFP, will be the prime contractor and will be responsible for all work performed
by any subcontractor.
3.6.16 Right to Refuse Personnel
The University of Tennessee reserves the right to refuse, at its sole discretion, any
subcontractors or any personnel provided by the prime contractor or its
subcontractors.
3.6.17 Independent Price Determination
A proposal will be disqualified and rejected if the price in the proposal was not
arrived at independently without collusion, consultation, communication, or
agreement as to any matter relating to such prices with any Proposer, a University
of Tennessee employee, or any competitor.
3.6.18 Multiple Proposal Submissions
The Proposer is prohibited from submitting more than one proposal. Submission of
more than one proposal will result in the disqualification of the Proposer. The
Proposer is prohibited from submitting multiple proposals in a different form (i.e.,
as a prime contractor and as a subcontractor to another prime contractor).
Submission of multiple proposals in a different form may result in the
disqualification of all Proposers associated with a multiple proposal.
3.6.19 Prohibited Actions
Should any prohibited action stated in this RFP be detected any time during the
term of the contract, such action will be considered a material breach and grounds
for contract termination.
3.6.20 Conflict of Interest
If a contract is issued, the contractor will avoid at all times any conflict of interests
between his or her duties and responsibilities as a contractor and his or her interest
outside the scope of any current or future contract. The following, but not limited
to, principles define the general parameters of a conflict of interest prohibited by
The University of Tennessee:
1.

A contractor's outside interests will not interfere with or compromise his

or her judgment and objectivity with respect to his or her responsibilities

to the University.
2.

A contractor will not make or influence University decisions or use

University resources in a manner that results in:
A. Financial gain outside any current or future contracts for either
the contractor or his or her relatives or
B. Unfair advantage to or favored treatment for a third party outside
the University.

3.

A contractor's outside financial interests will not affect the design,

conduct, or reporting of research. The contractor must certify that he or
she has no conflict of interests and has disclosed in writing the following:
A. Any partners or employees of the contractor who are also
employees of The University of Tennessee.
B. Any relatives of the contractor's partner or employees who work
for The University of Tennessee.
C. Any outside interest that may interfere with or compromise his
or her judgment and objectivity with respect to his or her
responsibilities to The University of Tennessee.

3.6.21 RFP Amendment and Cancellation

The University of Tennessee reserves the unilateral right to amend this RFP in
writing at any time. The University reserves the right to cancel or reissue the RFP
at its sole discretion. Proposers will respond to the final written RFP and any
exhibits, attachments, and amendments.
3.6.22 Right of Rejection
The University of Tennessee reserves the right, at its sole discretion, to reject any
and all proposals or to cancel this RFP in its entirety.
3.6.23 Proposal Rejection
Any proposal received which does not meet the requirements of this RFP may be
considered to be non-responsive, and the proposal may be rejected. Proposers must
comply with all of the terms of this RFP and all applicable State laws and
regulations. The University of Tennessee may reject any proposal that does not
comply with all of the terms, conditions, and performance requirements of this
RFP.
3.6.24 Restriction of Rights
Proposers may not restrict the rights of The University of Tennessee or otherwise
qualify their proposals. If a Proposer does so, the University may determine the
proposal to be a non-responsive counter offer, and the proposal may be rejected.
3.6.25 Informalities
The University of Tennessee reserves the right, at its sole discretion, to waive

informalities in proposals provided such action is in the best interest of the

University. Where the University waives minor informalities in proposals, such
waiver does not modify the RFP requirements or excuse the Proposer from full
compliance with the RFP. Notwithstanding any minor informality, the University
may hold any Proposer to strict compliance with the RFP.
3.6.26 Tennessee Records Law
DISCLOSURE OF PROPOSAL CONTENTS: All proposals and other materials
submitted in response to this RFP procurement process become the property of The
University of Tennessee. Selection or rejection of a response does not affect this
right. All proposal information, including detailed price and cost information, will
be held in confidence during the evaluation process and prior to the award
recommendation. Upon the completion of the review and evaluation of all
proposals submitted in response to this RFP, all proposals and associated materials
will become public documents of The University of Tennessee and open for review
by the public in accordance with Tennessee Code Annotated, Section 10-7-504(a)
(7). By submitting a proposal, the Proposer acknowledges and accepts that the full
contents of the proposal and associated documents will become a public record
open to public inspection. The wishes of any Proposer marking a proposal, any part
of a proposal, or associated materials as proprietary and/or confidential will be
neither accepted nor honored.
3.6.27 Severability
If any provision of this RFP is declared by a court to be illegal or in conflict with
any law, the validity of the remaining terms and provisions will not be affected;
and, the rights and obligations of The University of Tennessee and Proposers will
be construed and enforced as if the RFP did not contain the particular provision
held to be invalid.
3.6.28 Location and Work Space
The work under this RFP is to be performed, completed, and managed at
Knoxville, Tennessee. The University will provide work space for the Contractor.
All work performed on the University's premises will be completed during the
University's standard business hours (Monday through Friday, 8:00 a.m. - 5:00
p.m.) unless otherwise agreed upon in advance.
3.6.29 Software Escrow Agreement
If software is included in the Proposer's response, the Proposer will provide an
Escrow Agreement Agency Agreement whereby the firm will make available to
The University of Tennessee all program source codes for software in the event of
noncompliance by failure, firm ceases to exist, firm drops the product, or firm
ceases to support the product.
3.6.30 Special Terms and Conditions
The terms and conditions as listed in this section will govern the RFP process and
will be incorporated into any contract issued by The University of Tennessee. The
University of Tennessee General Bid Conditions (known as General Proposal
Conditions), will be applicable and incorporated into any contract issued by the
University. When reviewing the terms and conditions, all references made to
'request for quotations' are deleted and should be interpreted as 'request for
Proposal'; all references made to 'bidders' are deleted and should be interpreted as

'Proposers.'
3.6.30.1 Interpretations and Addenda
If during the RFP submission period, a firm finds discrepancies, ambiguities,
omissions, or is in doubt as to the meaning or intent of the proposal request, the
buyer should be notified on or before October 28, 1998. All such necessary
clarifications, information, interpretations or amendments, will be answered in the
form of written addenda and issued simultaneously to all holders of complete sets
of documents. No request for interpretation or clarification will be received or
answered after October 28, 1998. Buyer will not be responsive for oral
interpretations or instructions during proposal request period. All addenda are
incorporated, by reference, into the contract. Failure of any Proposer to receive any
addenda will not relieve the Proposer of any obligation with respect to the
proposal.
3.6.30.2 Contract Violation
If the contractor fails to perform properly its obligations under any contract issues
as a result of this RFP or violates any term of any contract issued as a result of this
RFP, the University will have the right to terminate any contract issued as a result
of this RFP immediately and withhold payments in excess of fair compensation for
completed services. The contractor will not be relieved of liability to the University
for damages sustained by breach of any contract issued as a result of this RFP by
the contractor.
3.6.30.3 Contract Approval
The University of Tennessee will not be bound by a contract issued as a result of
this RFP until it is approved by the appropriate University official(s). Any contract
issued as a result of this RFP may be modified only by a written amendment which
has been executed and approved by the appropriate parties.
3.6.30.4 Hold Harmless
The selected firm will defend at the firm's expense, indemnify and hold harmless
The University of Tennessee and its employees, including the Board of Trustees,
from and against any and all liability damages, losses, expenses, claims, demands,
suits, actions, judgments, bodily injuries or sicknesses to any person, or damage
destructive or loss of use of any property arising out of or related to the services
provided by the contractor or caused by the contractor's negligence or from any
operation conducted by the contractor in rendering service to The University of
Tennessee.
3.6.30.5 Independent Contractor
The firm selected will be deemed to be an independent contractor and will not,
under any circumstances be considered an employee, servant or agent of The
University of Tennessee. Neither the firm nor its employees have any authority to
bind the University in any respect.
3.6.30.6 Contractor Payments
The contractor warrants that no part of the total contract amount will be paid
directly or indirectly to an employee or official of the State of Tennessee as wages,
compensation, or gifts in exchange for acting as officer, agent, employee,

subcontractor or consultant to firm in connection with any work contemplated or

performed relative to this contract, and that no employee or official of the State of
Tennessee holds a controlling interest in the firm. If the firm is an individual, the
individual certifies that he or she is not presently employed by The University of
Tennessee or any other agency or institution of the State of Tennessee; that he or
she has not retired from or terminated such employment within the past six
months; and that he or she will not be so employed during the term of this contract.
3.6.30.7 Equal Opportunity
No person on the grounds of disability, age, race, color, religion, sex, national
origin, veteran status or any other classification protected by Federal and/or
Tennessee State constitutional and/or statutory law will be excluded from
participation in, or be denied benefits of, or otherwise subjected to discrimination
in the performance of this contract. The firm will, upon request, show proof of
such nondiscrimination, and will post in conspicuous places, available to all
employees and applicants, notice of nondiscrimination.
3.6.30.8 Insurance Requirements
The firm, being an independent contractor, agrees to carry adequate public liability
and other appropriate forms of insurance, and to pay all taxes incident to this
contract. Proposers are required to maintain comprehensive general liability
insurance including product liability coverage. Any purchase order(s) issued by
The University of Tennessee are contingent on the maintenance of current liability
coverage as described in the RFP document.
3.6.30.9 University Liability
The University of Tennessee will have no liability except as specifically provided
in this contract.
3.6.30.10 Compliance with Laws
The firm will comply with all applicable Federal and State laws and regulations in
the performance of this Contract.
3.6.30.11 Governing Laws
This contract will be governed by the laws of the State of Tennessee, which
provide that The University of Tennessee liability coverage is solely under the
terms and limits of the Tennessee Claims Commission Act.
3.6.30.12 Terms and Conditions Conflicts
In the event there are any conflicts between the general proposal conditions and the
special proposal conditions, the special proposal conditions will take precedence.
3.6.30.13 Information Requirements
Proposers must submit with their proposals adequate information to establish their
ability to satisfactorily furnish the items on this contract. The University of
Tennessee may require of the successful Proposer sufficient information to
establish financial responsibility; that he has adequate facilities and personnel; plus
any other information which may be requested by the University which it deems

necessary to establish the successful Proposer's ability to do this work.

3.6.30.14 Prices
Prices quoted must be firm for the duration of the contract and its extensions, if
any, except The University of Tennessee will be advised of and receive the benefit
of any and all general price reductions to the Proposer's other customers or price
reductions due to general market forces occurring at any time during the effective
period of the contract. Written notice will be made to the Purchasing Department
not later than (10) days prior to the effective date of the price reduction. The price
decrease will be identical to or greater than the general decrease extended to the
contractor's other customers. Price decrease will become effective immediately and
will apply to all orders which have yet to be filled or delivered.
3.6.30.15 Cancellation
Notwithstanding any other cancellation provision, this contract may be canceled in
whole or in part by The University of Tennessee by giving thirty (30) days prior
notice in writing to the other party. In addition, the University is required by State
law to purchase its requirements from state contractors if their prices are less than
those prices obtained by The University of Tennessee. If during the term of this
contract a State contract is issued which has lower prices, the University reserves
the right to cancel all or part of this contract.
3.6.30.16 Qualified Personnel
The successful Proposer will be responsible for furnishing qualified, responsible,
professional personnel who can perform the requirements of this contract.
3.6.30.17 General Proposal Conditions
The University of Tennessee General Proposal Conditions as attached are also
applicable to any contract issued as a result of this RFP.

Request for Proposal Evaluation Team

Neal Wormsley, Chair
Sylvia Davis
Janet Hickman
John Jarrard
Les Mathews
Mike McNeil
Sara Phillips
Sally Townsend