Get documents about "RFP Template
Document Sample
RFP No. MSO0037
0500 TABLE OF CONTENTS
1.0 INTRODUCTION .................................................................... 3
1.1 PURPOSE OF REQUEST FOR PROPOSAL .............................................................. 3
1.2 BUSINESS GOALS ...................................................................................... 3
1.3 PROJECT SCOPE ........................................................................................ 3
2.0 DESCRIPTION OF EXISTING SYSTEM(S) ........................................ 5
2.1 BUSINESS CONTEXT.................................................................................... 5
2.2 CURRENT SYSTEM ...................................................................................... 5
3.0 REQUIREMENTS INFORMATION ................................................... 6
3.1 ORGANIZATION OF REQUIREMENTS .................................................................. 6
3.2 QUALIFIERS FOR FUNCTIONAL AND TECHNICAL REQUIREMENTS ................................. 6
4.0 FUNCTIONAL REQUIREMENTS ..................................................... 7
4.1 RESPONDING TO FUNCTIONAL REQUIREMENTS .................................................... 7
4.2 TABLE OF FUNCTIONAL REQUIREMENTS ............................................................. 7
5.0 TECHNICAL REQUIREMENTS .....................................................25
5.1 TECHNOLOGY ENVIRONMENT AT THE CITY OF AUSTIN........................................... 25
5.2 RESPONDING TO TECHNICAL REQUIREMENTS .................................................... 25
5.3 TABLE OF TECHNICAL REQUIREMENTS – ALL SOLUTIONS ...................................... 25
5.4 TABLE OF TECHNICAL REQUIREMENTS - CLIENT-SERVER OR INTERNALLY HOSTED SOLUTION 32
5.5 TABLE OF TECHNICAL REQUIREMENTS – ASP SOLUTION ......................................... 37
5.6 EXTERNAL INTERFACES - RESPONDING TO EXTERNAL INTERFACES ........................... 38
5.7 NAME OF SYSTEM - INTERFACE ..................................................................... 38
6.0 IMPLEMENTATION REQUIREMENTS ..............................................40
6.1 RESPONDING TO IMPLEMENTATION REQUIREMENTS ............................................. 40
6.2 LIST OF IMPLEMENTATION REQUIREMENTS........................................................ 40
7.0 PROPOSAL PREPARATION AND EVALUATION ...................................41
7.1 EVALUATION CRITERIA: ............................................................................. 41
7.2 PRODUCT AND PROOF OF CONCEPT DEMONSTRATION........................................... 41
7.3 VENDOR QUALIFICATIONS .......................................................................... 42
7.4 MANDATORY SUBMITTALS ........................................................................... 42
7.5 PROPOSAL FORMAT ................................................................................... 43
7.6 PROPOSAL ACCEPTANCE PERIOD: .................................................................. 45
7.7 EXCEPTIONS ........................................................................................... 45
7.8 PROPOSAL PREPARATION COSTS ................................................................... 45
7.9 CONTRACT PAYMENT AND RETAINAGE ............................................................. 45
7.10 SOURCE CODE ESCROW AGREEMENT .............................................................. 47
Page 1 of 48
RFP No. MSO0037
8.0 LIST OF APPENDICES FOR THIS RFP: ..........................................48
Page 2 of 48
RFP No. MSO0037
1.0 INTRODUCTION
1.1 Purpose of Request for Proposal
The City of Austin, hereinafter referred to as the City, seeks proposals in response to this
Request for Proposal (RFP) from qualified contractors with demonstrated experience
working with physical records management systems for local government entities.
Note: Please read though the entire RFP before beginning to work on your
response, and proof the proposal before submission.
Configure and price your system design to satisfy all stated RFP requirements, including
any and all optional system hardware and software elements necessary to satisfy a
requirement.
1.2 Business Goals
The project objective is to identify and select a vendor with the capability of replacing the
Gain 2000 records management system, currently in production.
1.3 Project Scope
The City of Austin is seeking a system to support the management of physical records
with a web-based application that can be accessed by authorized personnel within all City
departments. This includes replacing the current legacy system, GAIN RM, Enterprise
Edition by Triadd Software, and migrating existing data from that system.
The system must:
Process accessions of new boxes and files;
Support services for retrieval and re-filing boxes and files;
Provide reports and the ability to create customized, user-defined reports;
Support the City’s File Plan and the classification of records for retention
purposes;
Support services for records destruction;
Track the history of chain of custody and activities associated with boxes and
files;
Support identification of City departments and work units responsible for
records; and
Provide security based on user, group, and departmental access
permissions.
The contractor will also be responsible for:
Providing support services for the migration of data into the new system to
insure a seamless process and eliminate the possibility of data loss during
the transition; and
Providing training for Records Managers, administrators, and Records Center
Staff (train-the-trainer training).
Page 3 of 48
RFP No. MSO0037
1.3.1 Buyer’s Responsibilities
The Buyer will provide network infrastructure and facilities to support the system. The
Vendor must furnish and install a fully functional system that meets the requirements
specified in a negotiated contract. Details regarding the Buyer’s responsibilities and the
Vendor’s responsibilities are noted below. The final contract will dictate specifics of the
scope of work for both Buyer and Vendor.
Office space for Vendor project management staff
Site preparation
HVAC and AC power feed and generator backup for City systems
Local Area Network/Wide Area Network
Approval of milestones and deliverables
1.3.2 Vendor’s Responsibilities
The Vendor shall be responsible for the following:
All system design, software installation, programming, testing,
performance tuning, training, documentation and implementation required
for the system. If third-party software is required, Vendor shall assume full
responsibility for its inclusion in this solution.
The Contractor shall submit weekly and monthly, or as otherwise agreed
upon by the Physical Records Management System Implementation
Project Team and Contractor, progress reports to the Project
Manager/Project Team. The progress reports shall describe significant
accomplishments, issues and/or problems which have potential effect on
schedule or costs, and plans for the upcoming week. They should be
sufficiently detailed to assure that directions being pursued are in
compliance with established and/or projected goals.
All technical documents for the proposed system and its components.
These documents shall include administrator and end user manuals about
product installation and maintenance, including detailed design documents
for customized system application and test plans. The supplier shall grant
the City the authorization to reproduce any provided documents for
internal use.
Assist in the development of an acceptance test plan and assist in the
performance of testing the entire system. During testing, the Vendor must
be available for assistance and correction of any error detected. Testing
must be successfully performed before the City approves the final sign-off
for the acceptance of the system.
Be available via a toll-free number for technical support and problem
resolution during normal business hours (8:00 a.m. - 5:00 p.m. CST,
Monday through Friday) during implementation.
Provide a detailed list of the necessary resources and expertise, complete
with personnel job descriptions, which shall be required for the City to
maintain the system once implemented.
Page 4 of 48
RFP No. MSO0037
Provide system administrator training to a minimum of 5 users.
Provide train the trainer end user training for 10 users
1.3.3 City’s Acceptable Use Policy
Vendor computers will not be allowed to connect to the City’s internal network.
2.0 DESCRIPTION OF EXISTING SYSTEM(S)
2.1 Business Context
The purpose of the City of Austin’s Records Management Services Division is to manage
City records so that they are accessible, maintained efficiently and cost-effectively, and so
that the City retains all records it is required to keep, identifies and preserves records with
permanent value, and disposes of those with no further value in a secure and timely
manner.
The Records Management Services Division is also responsible for managing the transfer
of inactive records from City offices to its current offsite storage contractor, Iron Mountain;
for processing requests for the retrieval and re-filing of files and boxes to and from Iron
Mountain and; destruction of records in storage. NOTE: All references to “Iron Mountain”
in the RFP documents shall apply to any future off-site records storage contractor
engaged by the City of Austin.
2.2 Current System
The current records management system application being used by the City of Austin is
the Gain 2000 Enterprise Edition records management system by Triadd Software.
The numbers listed are estimates as of July 20, 2009. These numbers are subject to
change as new items are added, deleted and existing data clean-up projects continue.
Department/Divisions:
Currently 480 named departments and divisions.
Boxes:
Active: 90,587
Inactive: 13522
Files:
Active: 336172
Inactive: 5818
Retention Schedule:
Number of record series: 1498
End Users:
Active: 532
Watershed Protection and Development Review Database:
15,000 files
The application is used to track the transfer of City records to the Iron Mountain records
center. It also retrieves material and tracks the destruction of material in storage.
Page 5 of 48
RFP No. MSO0037
3.0 REQUIREMENTS INFORMATION
Vendor responses to the requirements are used to evaluate proposals. The Functional
and Technical requirements are presented in sections 4 and 5 and also in Appendix B,
the Vendor Response Access Database. NOTE: The Completed Vendor Response
Database must be burned to a CD and included with proposals as described in
Appendix A, Vendor Response Access Database Instructions. In addition a hard
copy original of the requirement responses must also be submitted. (See Section
7.4.1)
3.1 Organization of Requirements
Requirements are grouped into three areas:
Functional Requirements: These requirements describe product features
and functionality requested by end users.
Technical Requirements: Developed by the City’s Communication and
Technology Management staff, these requirements describe the technical
specifications to support the Functional Requirements and the constraints
for security and networking.
Project Implementation Requirements: These requirements describe the
project management resources, processes, documentation and training that
ensure effective product implementation and accomplishment of project
objectives.
3.2 Qualifiers for Functional and Technical Requirements
3.2.1 Category
“Category” distinguishes the requirement within each functional and technical group.
“Category ID” organizes requirements by business process or technical similarity.
3.2.2 Requirement Description
The “Requirement” describes the individual functions identified as either a necessity or a
desired function.
3.2.3 Required Response
The purpose of the “Required Response” is to provide the vendors with the opportunity to
describe and/or demonstrate how their product meets the individual requirements listed.
Submission of the Vendor Response Database is a requirement and responses are required
in the database.
3.2.4 Importance Rating
“Importance Rating” indicates how critical the requirement is to achieving product and project
objectives. End users assign priorities to Functional Requirements and Communications and
Technology Management staff assign Technical Requirement priorities. The three
“Importance Levels” are:
Page 6 of 48
RFP No. MSO0037
Must Have: These requirements may or may not be industry standards but
are highly critical to the project. They must either be satisfied by the
system’s base functionality or the vendor must offer an alternative such as
customization.
Expected: These requirements are important to the end users of the system
and generally are features that are industry standards. The majority of
these requirements need to be satisfied.
Desired: These requirements add value, but are not critical to end users.
These features would be considered optional.
4.0 FUNCTIONAL REQUIREMENTS
4.1 Responding To Functional Requirements
To ensure that a proposed solution is thoroughly represented, Vendors should respond to
each requirement below by completing Appendix B, Vendor Response Access Database
according to the instructions in Appendix A, Vendor Response Access Database
Instructions.
4.2 Table of Functional Requirements
Physical Records Management System Requirements
Req ID Owner Category Requirement Response Priority ReqType
4.03.001 OCC Admin The system must employ user Describe how your Must Have Functional
identification and authentication system meets the
measures to ensure that only requirement.
authorized users may access the
system.
4.03.002 OCC Admin The system must support the ability Describe how your Must Have Functional
to set up departmental/work unit system meets the
groups based on the City’s requirement.
organizational structure. The system
must support assigning users
simultaneously to more than one
department.
4.03.003 OCC Admin The system should support the Describe how your Desired Functional
ability to define certain system meets the
departments/work units as being requirement.
subject to “charge-backs” based on
the number of boxes in storage and
a user-configurable fee.
Page 7 of 48
RFP No. MSO0037
Physical Records Management System Requirements
Req ID Owner Category Requirement Response Priority ReqType
4.03.004 OCC Admin The system must support the ability Describe how your Must Have Functional
to set up user/departmental groups system meets the
and administer system privileges requirement.
based on group membership. At a
minimum the system must support
the following default groups:
Application Administrators are
responsible for setting up and
maintaining the system
infrastructure.
Records Managers are responsible
for the City’s records management
administration (the file plan, user
account maintenance, access
control, report/query creation, etc.)
Records Analysts are responsible for
coordinating the City’s records
management program with City
departments. Each Analyst is
assigned a group of departments for
which they are responsible.
Records Center Staff are
responsible for handling day-to-day
records center functions (processing
records retrieval requests,
processing box pickup requests,
records destruction, etc.)
Departmental Records
Administrators, Coordinators, and
Liaisons are authorized to perform a
variety of records management
tasks within departments and
divisions throughout the City such as
reviewing and authorizing box
transfers and destructions
(Departmental Administrators only);
creating and indexing box/file
records; making records retrieval
requests; and making box pickup
requests.
Staff or general users with limited,
read-only access.
4.03.005 OCC Admin The system must support the Describe how your Must Have Functional
assignment and/or denial of system meets the
permissions to users based on requirement.
group/departmental membership.
4.03.006 OCC Admin The system should support a Describe how your Desired Functional
method of overriding system meets the
Page 8 of 48
RFP No. MSO0037
Physical Records Management System Requirements
Req ID Owner Category Requirement Response Priority ReqType
group/departmental-level requirement.
permissions with individual user-level
permissions.
4.03.007 OCC Admin The system must support setting Describe how your Must Have Functional
access controls on individual boxes. system meets the
For instance, the system should requirement.
support the ability to grant or limit
rights based on the status of a box.
(Example: Allow departmental
records administrators to edit box
information for boxes pending
approval for transfer but not for any
boxes that have been approved and
transferred to the records center.)
4.04.001 OCC Search The system must support searches Describe how your Must Have Functional
using any combination of the box system meets the
and/or file indexing fields, including requirement.
user-defined and system-generated
metadata, based on the user’s
group/departmental access
permissions.
4.04.002 OCC Search The system must allow users to Describe how your Must Have Functional
specify partial matches and allow system meets the
use of “wild card” characters. requirement.
4.04.003 OCC Search The system must allow searches Describe how your Must Have Functional
using combinations of such Boolean system meets the
and relational operators as “and,” requirement.
“and not,” “or,” “greater than” (>),
“less than” (<>), is blank, is null, not
blank, and not null and should
provide a method for the users to
determine the order of precedence.
4.04.004 OCC Search The system must allow searches Describe how your Must Have Functional
using ranges of search criteria such system meets the
as date ranges, file ranges, box requirement.
number ranges, and department
code ranges.
4.04.005 OCC Search The system must allow Describe how your Must Have Functional
comprehensive searches for the system meets the
presence of specified search criteria requirement.
in all metadata fields via a single
search (full-text search).
4.04.006 OCC Search The system must allow users to Describe how your Must Have Functional
browse the records based on their system meets the
File Plan classification. requirement.
Page 9 of 48
RFP No. MSO0037
Physical Records Management System Requirements
Req ID Owner Category Requirement Response Priority ReqType
4.04.007 OCC Search The system must present the user a Describe how your Must Have Functional
list of boxes and/or files meeting the system meets the
retrieval criteria, or notify the user if requirement.
there are no records and/or files
meeting the retrieval criteria.
4.04.008 OCC Search The system should allow the user to Describe how your Desired Functional
select and group search results, and system meets the
to order the columns presented in requirement.
the search results list for viewing,
printing, etc.
4.04.009 OCC Search The system should provide the Describe how your Desired Functional
capability to create, view, save, system meets the
export, and print the results of a requirement.
search sorted and/or grouped by
user preference. User must be
allowed to select any number of
boxes or files in a search results list
for additional processing (retrieval
requests, destruction processing,
transfer, etc.)
4.04.010 OCC Search The system must allow the user to Describe how your Must Have Functional
abort/cancel a search. system meets the
requirement.
4.05.001 OCC Report The system must provide authorized Describe how your Must Have Functional
users with the ability to create system meets the
customized, user-defined reports, requirement.
notifications, and memos based on
report templates or queries using the
data held within the system’s
database. The system must support
the deployment of these reports for
use by other users based on the
group/departmental access
permissions as described in Section
4.03.
4.05.002 OCC Report The system must provide authorized Describe how your Must Have Functional
users with the ability to create system meets the
reports using a variety of search requirement.
criteria as described in Section 4.04.
4.05.003 OCC Report The system must: provide a means Describe how your Must Have Functional
to generate performance metrics system meets the
reports on a variety of system requirement.
activities including, but not limited to:
new boxes/files received, records
reviewed, items transferred, items
Page 10 of 48
RFP No. MSO0037
Physical Records Management System Requirements
Req ID Owner Category Requirement Response Priority ReqType
whose retention has expired, items
destroyed, etc.
4.05.004 OCC Report The system must provide authorized Describe how your Must Have Functional
users with the ability to export report system meets the
data from the system and save requirement.
reports in a variety of electronic
formats (Excel, Word, PDF, etc.)
4.05.005 OCC Report The system should be able to create Describe how your Desired Functional
billing memos for select departments system meets the
based on the number of boxes in requirement.
storage and a user-configurable fee.
4.05.006 OCC Report The system should provide Describe how your Desired Functional
authorized users with the ability to system meets the
send reports, notifications, and requirement.
memos to users via the City’s e-mail
system.
4.06.001 OCC History The system must provide a method Describe how your Must Have Functional
to track a complete history (audit system meets the
trail) of all of the events, status requirement.
changes, and activities associated
with boxes, files, records categories,
users, groups, departments, and
other system components. The audit
log must capture the identity of the
user taking the action, date/time of
the event or action, and the type of
event, status, and/or action.
4.06.002 OCC History The captured audit actions for box Describe how your Must Have Functional
records must include retrieving, system meets the
creating, deleting, viewing, requirement.
destruction, and editing activities.
The audit log must capture changes
of custody, when box statuses were
changed and who changed them.
4.06.003 OCC History The system should provide the ability Describe how your Desired Functional
for authorized users to create system meets the
custom-defined events, statuses, requirement.
and activities to be captured in the
history log.
4.06.004 OCC History The system must provide the ability Describe how your Must Have Functional
to view, copy, save, and print the system meets the
history log based on user requirement.
permissions.
4.06.005 OCC History The system must prohibit editing of Describe how your Must Have Functional
the history log. system meets the
Page 11 of 48
RFP No. MSO0037
Physical Records Management System Requirements
Req ID Owner Category Requirement Response Priority ReqType
requirement.
4.06.006 OCC History The system should provide analysis Describe how your Desired Functional
functionality by which an authorized system meets the
individual can create and save requirement.
specialized audit reports.
4.06.007 OCC History The system should allow only Describe how your Desired Functional
authorized users to export and/or system meets the
backup and remove audit files from requirement.
the system.
4.07.001 OCC Data Mgt The system must provide the Describe how your Must Have Functional
capability for authorized users to system meets the
make global changes to the record requirement.
series names, record series codes,
disposition components, users,
groups, originating departments,
box/file information, and other
metadata. Global changes of
metadata must propagate to all
related tables. The system must
enforce data integrity, referential
integrity, and relational integrity of
the metadata.
4.07.002 OCC Data Mgt The system must provide the Describe how your Must Have Functional
capability for authorized users to system meets the
perform bulk uploads of all or part of requirement.
the City’s File Plan, users, groups,
originating departments, box/file
information, and other metadata.
4.07.003 OCC Data Mgt The system must support the ability Describe how your Must Have Functional
to upload data from and export data system meets the
to the City’s records storage vendor, requirement.
Iron Mountain.
4.07.004 OCC Data Mgt The system must provide the Describe how your Must Have Functional
capability for authorized users to system meets the
customize user screens and arrange requirement.
the components on screens to be
used for searching, filing, making
retrieval requests, and other
screens.
4.07.005 OCC Data Mgt The system must provide the Describe how your Must Have Functional
capability for authorized users to system meets the
assign default values to metadata requirement.
fields on screens to be used for
searching, filing, making retrieval
requests, and other screens.
Page 12 of 48
RFP No. MSO0037
Physical Records Management System Requirements
Req ID Owner Category Requirement Response Priority ReqType
4.07.006 OCC Data Mgt The system must provide the Describe how your Must Have Functional
capability for authorized users to system meets the
create and maintain templates that requirement.
automatically populate commonly
used data into file and box metadata
fields. The system must provide the
capability for authorized users to
create and maintain picklists from
metadata lookup tables.
4.08.001 OCC Other The vendor must provide services to Describe how your Must Have Functional
support the migration of data from system meets the
the City’s legacy records center requirement.
system, GAIN 2000, as well as
metadata stored in a custom system
maintained by the Watershed
Protection Department. The City will
also expect assistance from the
vendor in data clean-up and
normalization prior to transfer to the
new system.
4.08.002 OCC Other The vendor must provide user Describe how your Must Have Functional
guides, technical manuals, system meets the
installation procedures, training requirement.
manuals, and other system
documentation required for ongoing
training, operations, and
maintenance of the system.
4.08.003 OCC Other The vendor must provide training for Describe how your Must Have Functional
Records Managers, administrators, system meets the
and Records Center Staff (train-the- requirement.
trainer training).
4.08.004 OCC Other The system must have an on-line Describe how your Must Have Functional
help capability for access to user system meets the
operational information. Help should requirement.
be context sensitive to the screens
from which help was launched.
Global help should be available from
a toolbar menu item or keyboard
shortcut.
4.08.005 OCC Other The system should have capability to Describe how your Desired Functional
create and read barcodes. system meets the
requirement.
4.09.001 OCC Records Vendors must demonstrate the Describe how your Must Have Functional
Control proposed system’s file system meets the
plan/taxonomy structure. requirement.
4.09.002 OCC Records The system must support the Describe how your Must Have Functional
hierarchical structure of the City’s system meets the
Page 13 of 48
RFP No. MSO0037
Physical Records Management System Requirements
Req ID Owner Category Requirement Response Priority ReqType
Control File Plan. Each File Plan category requirement.
identifier must be linked to its higher-
level File Plan components.
4.09.003 OCC Records The system must allow only Describe how your Must Have Functional
Control authorized users to create, edit, and system meets the
delete File Plan components and requirement.
their metadata.
4.09.004 OCC Records The system must maintain an audit Describe how your Must Have Functional
Control trail of edits made to File Plan system meets the
components as described in Section requirement.
4.06.
4.09.005 OCC Records The system must provide the Describe how your Must Have Functional
Control following mandatory File Plan system meets the
metadata: name, identifiers (COA requirement.
File Plan coding as well as Texas
Stat Library codes), Description,
Disposition Instructions, Disposition
Authority, Retention Period, Transfer
of Austin History Center Indicator
(Historical records), Vital Record
Indicator, Texas State Library
Approval Status and
Comments/Notes.
4.09.006 OCC Records The system must provide the ability Describe how your Must Have Functional
Control for authorized users to create system meets the
custom user-defined fields requirement.
associated with File Plan
components.
4.09.007 OCC Records The system must ensure that Describe how your Must Have Functional
Control Records Series (a group of related system meets the
records filed/used together as a unit requirement.
and evaluated as a unit for retention
purposes) identifiers are unique so
that ambiguous assignments,
classifications, or associations
cannot occur.
4.09.008 OCC Records The system should allow authorized Describe how your Desired Functional
Control users to restrict access to File Plan system meets the
components based on user group requirement.
membership, department/work unit,
or individual user profiles as
described in Section 4.03. The
system must present to users only
those Records Series available to
the user, group, or department for
filing.
Page 14 of 48
RFP No. MSO0037
Physical Records Management System Requirements
Req ID Owner Category Requirement Response Priority ReqType
4.09.009 OCC Records The system must support granting Describe how your Must Have Functional
Control access of File Plan components to system meets the
multiple user groups, requirement.
department/work units, and
individual user profiles.
4.09.010 OCC Records The system must allow authorized Describe how your Must Have Functional
Control users to associate records retention system meets the
rules with Records Series requirement.
components.
4.09.011 OCC Records The system must allow authorized Describe how your Must Have Functional
Control users to define and name retention system meets the
events. Multiple events per Records requirement.
Series must be supported.
4.09.012 OCC Records The system must allow authorized Describe how your Must Have Functional
Control users to define and name disposition system meets the
types. Examples include: requirement.
Destruction, Transfer and
Expungement.
4.09.013 OCC Records Mandatory event/disposition types Describe how your Must Have Functional
Control include: Records are eligible to enter system meets the
their disposition immediately after requirement.
the conclusion of a fixed period of
time following the event (year end,
fiscal year end, etc.); Records are
eligible for disposition immediately
after a specified event takes place
(Administrative value, etc.);
Retention periods triggered after a
specified event takes place (for
example, contract close plus two
years.)
4.09.014 OCC Records The system must calculate the Describe how your Must Have Functional
Control retention period and destruction system meets the
dates of records based on user- requirement.
supplied dates.
4.09.015 OCC Records The system must recalculate the Describe how your Must Have Functional
Control retention period and destruction system meets the
dates based on changes to any requirement.
event dates according to the
retention rules associated with the
dates.
4.09.016 OCC Records The system must provide the Describe how your Must Have Functional
Control capability to reorganize the File Plan system meets the
and automatically propagate the requirement.
changes resulting from the
reorganization to the affected
Page 15 of 48
RFP No. MSO0037
Physical Records Management System Requirements
Req ID Owner Category Requirement Response Priority ReqType
records.
4.09.017 OCC Records For boxes and files with event- and Describe how your Must Have Functional
Control time-event-driven dispositions, the system meets the
system must allow authorized users requirement.
to indicate when the specified event
has occurred.
4.09.018 OCC Records The system must provide the Describe how your Must Have Functional
Control capability for only authorized users to system meets the
change a Records Series associated requirement.
with a box.
4.09.019 OCC Records The system must provide the Describe how your Must Have Functional
Control capability to view, save, or print File system meets the
Plan metadata, sorted and/or requirement.
grouped by user preference.
4.09.020 OCC Records The system must provide the ability Describe how your Must Have Functional
Control to search the File Plan using a system meets the
variety of criteria as described in requirement.
Section 4.04.
4.09.021 OCC Records The system must provide authorized Describe how your Must Have Functional
Control users with the ability to create system meets the
customized, user-defined File Plan requirement.
reports as described in Section 4.05.
4.10.001 OCC Index Vendors must demonstrate the Describe how your Must Have Functional
proposed system’s procedures for system meets the
entering the indexing data for new requirement.
boxes and files.
4.10.002 OCC Index The system must restrict the ability Describe how your Must Have Functional
to create records for new boxes and system meets the
files to authorized users. requirement.
4.10.003 OCC Index Must allow authorized users to Describe how your Must Have Functional
establish data validation rules for all system meets the
users, user groups, departments, or requirement.
other organizational entities. Such
requirements may include: Making
some fields mandatory and others
optional (for instance, all boxes must
be classified in the File Plan, with a
disposal date and disposal action;
require identification of the record
custodian, linked to the departmental
code); Constraining data entry
options (for instance, limiting
departments to specific Records
Series identifiers and specific
departmental codes); Ensuring all
files in a box are classified in the
Page 16 of 48
RFP No. MSO0037
Physical Records Management System Requirements
Req ID Owner Category Requirement Response Priority ReqType
same Records Series and have the
same close date for retention
purposes; Prohibiting users from
entering records that have already
passed their retention period;
Prohibiting users from entering
records for a department code that
they do not have access.
4.10.004 OCC Index The system must assign a unique Describe how your Must Have Functional
record identifier for each box and file system meets the
it manages. If the unique identifier is requirement.
system-generated, the system must
also support one or more user-
defined identifiers for each box and
file (e.g., Iron Mountain bar code
numbers, departmental numbers,
etc.) and be able to search on those
user defined identifiers.
4.10.005 OCC Index The system must support the ability Describe how your Must Have Functional
to identify and track multiple box system meets the
types and sizes. requirement.
4.10.006 OCC Index The system should provide methods Describe how your Desired Functional
for assisting the user in classifying system meets the
records and in the selection of the requirement.
File Plan components to be assigned
to a record. For instances,
authorized users should be able to
designate “favorites” for a
department and/or user.
4.10.007 OCC Index The system must provide the Describe how your Must Have Functional
capability for only authorized users to system meets the
modify the metadata of boxes and requirement.
files or delete records from the
system.
4.10.008 OCC Index The system must support the bulk Describe how your Must Have Functional
upload of data to create new box and system meets the
file records. requirement.
4.10.009 OCC Index The system should support the Describe how your Desired Functional
ability to scan indexing information system meets the
on folders; for instance file names requirement.
and/or barcodes.
4.10.010 OCC Index The system must support tracking Describe how your Must Have Functional
“accessions” of boxes; a group of system meets the
boxes submitted for review and requirement.
transfer on the same date by the
same requester.
Page 17 of 48
RFP No. MSO0037
Physical Records Management System Requirements
Req ID Owner Category Requirement Response Priority ReqType
4.10.011 OCC Index The system must support the City’s Describe how your Must Have Functional
process for submitting new boxes for system meets the
review and transfer to the records requirement.
center, and manage box statuses.
This procedure may include:
Entering box and file metadata into
the system with a status of “pending”
or “under review.”; Alerting Records
Analysts that accessions of new
boxes from one of their assigned
departments are ready for review.
The system must identify and
present to the Records Manager
and/or Analysts the boxes that are
ready for review. The system must
support Records Analysts in tracking
and managing/prioritizing their
review activities; Generating a
report for departmental Records
Administrator notifying them of the
status of the Records Analyst review
(which boxes in an accession have
been approved for transfer and
which have been denied). The
system must provide a means for
the departmental Records
Administrator to respond to this
report; Issuance of pick-up requests
to Iron Mountain by Records Center
staff in order to schedule the pick-up
of the boxes that have been
approved for transfer. The system
must also send confirmation of the
pick-up request to the departmental
staff that entered the request;
Updating the status of the boxes to
indicate whether they have been
“checked into” the Records Center,
or “denied” transfer; Confirming the
receipt of boxes at Iron Mountain’s
facilities.
4.10.012 OCC Index The system must allow users to Describe how your Must Have Functional
enter special instructions or delivery system meets the
instructions when placing a request requirement.
for delivery or pick-up.
4.10.013 OCC Index The system must provide a means Describe how your Must Have Functional
to generate performance metrics system meets the
reports on accession and transfer requirement.
activities including, but not limited to:
number of new boxes submitted for
review, number of records reviewed,
Page 18 of 48
RFP No. MSO0037
Physical Records Management System Requirements
Req ID Owner Category Requirement Response Priority ReqType
status of records being accessioned,
number of items actually transferred,
etc.
4.10.014 OCC Index The system must provide a method Describe how your Must Have Functional
to track a complete history of all of system meets the
the events associated with new requirement.
accessions of boxes.
4.11.001 OCC Retrieval Vendors must demonstrate their Describe how your Must Have Functional
proposed system’s procedures for system meets the
handling retrieval requests and re- requirement.
files of boxes and files.
4.11.002 OCC Retrieval The system must support searching Describe how your Must Have Functional
to locate boxes and files for retrieval system meets the
using all of the methods described in requirement.
Section 4.04.
4.11.003 OCC Retrieval The system must allow the user to Describe how your Must Have Functional
select any number of boxes or files system meets the
in a search results list for a retrieval requirement.
request. The system must track a
complete history (audit trail) of all of
the events, status changes, and
activities associated with retrieval
requests of boxes and files as
described in Section 4.06.
4.11.004 OCC Retrieval The system must prevent Describe how your Must Have Functional
unauthorized retrieval requests using system meets the
group-, departmental-, or individual- requirement.
level permissions as described in
Section 4.03.
4.11.005 OCC Retrieval The system must provide a means Describe how your Must Have Functional
to generate performance metrics system meets the
reports on activities associated with requirement.
retrieval requests of boxes and files
as described in Sections 4.05 and
4.06.
4.11.006 OCC Retrieval The system must provide authorized Describe how your Must Have Functional
users with the ability to create system meets the
customized, user-defined reports, requirement.
notifications, and memos using data
associated with retrieval requests of
boxes and files as described in
Section 4.05.
4.11.007 OCC Retrieval The system must allow users to Describe how your Must Have Functional
provide special delivery instructions system meets the
for retrieval requests. requirement.
Page 19 of 48
RFP No. MSO0037
Physical Records Management System Requirements
Req ID Owner Category Requirement Response Priority ReqType
4.11.008 OCC Retrieval The system must allow users to Describe how your Must Have Functional
make “mixed” requests for both files system meets the
and boxes in the same transaction. requirement.
4.11.009 OCC Retrieval The system must allow users to set Describe how your Must Have Functional
a priority level on a retrieval request. system meets the
requirement.
4.11.010 OCC Retrieval The system must allow authorized Describe how your Must Have Functional
users to define custom priorities system meets the
values and set default priorities on requirement.
retrieval requests.
4.11.011 OCC Retrieval If a user requests a box or file that is Describe how your Must Have Functional
already checked out, the system system meets the
must alert the user that the item is requirement.
not available.
4.11.012 OCC Retrieval The system should support the Describe how your Must Have Functional
capability to electronically transmit system meets the
retrieval requests to the City’s requirement.
records management vendor, Iron
Mountain.
4.11.013 OCC Retrieval The system must support the Describe how your Must Have Functional
capability to electronically receive system meets the
and upload retrieval request statuses requirement.
provided by the City’s records
management vendor, Iron Mountain.
Examples include “Processed,” “Not
Found,” and “Already Checked Out.
4.12.001 OCC Re-files The system must support searching Describe how your Must Have Functional
to locate boxes and files for re-files system meets the
using all of the methods described in requirement.
Section 4.04.
4.12.002 OCC Re-files The system must allow the user to Describe how your Must Have Functional
select any number of boxes or files system meets the
in a search results list for a re-file requirement.
request.
4.12.003 OCC Re-files The system must track a complete Describe how your Must Have Functional
history (audit trail) of all of the system meets the
events, status changes, and requirement.
activities associated with re-file
requests of boxes and files as
described in Section 4.06.
4.12.004 OCC Re-files The system must prevent Describe how your Must Have Functional
unauthorized re-file requests using system meets the
group-, departmental-, or individual- requirement.
level permissions as described in
Section 4.03.
Page 20 of 48
RFP No. MSO0037
Physical Records Management System Requirements
Req ID Owner Category Requirement Response Priority ReqType
4.12.005 OCC Re-files The system must provide a means Describe how your Must Have Functional
to generate performance metrics system meets the
reports on activities associated with requirement.
re-file requests of boxes and files as
described in Sections 4.05 and 4.06.
4.12.006 OCC Re-files The system must provide authorized Describe how your Must Have Functional
users with the ability to create system meets the
customized, user-defined reports, requirement.
notifications, and memos using data
associated with re-file requests of
boxes and files as described in
Section 4.05
4.12.007 OCC Re-files The system must allow users to Describe how your Must Have Functional
provide special instructions for re-file system meets the
pick-ups. requirement.
4.12.008 OCC Re-files The system must allow users to Describe how your Must Have Functional
make “mixed” requests for both files system meets the
and boxes in the same transaction. requirement.
4.12.009 OCC Re-files The system should support the Describe how your Desired Functional
capability to electronically transmit system meets the
re-file requests to the City’s records requirement.
management vendor, Iron Mountain.
4.12.010 OCC Re-files The system must support the Describe how your Must Have Functional
capability to electronically receive system meets the
and upload re-file transaction requirement.
statuses provided by the City’s
records management vendor, Iron
Mountain.
4.13.001 OCC Disposition Vendors must demonstrate the Describe how your Must Have Functional
disposal processing procedure of the system meets the
proposed system. requirement.
4.13.002 OCC Disposition The system must identify and Describe how your Must Have Functional
present to the Records Manager and system meets the
Analysts the records, including requirement.
metadata, that have met their
retention period.
4.13.003 OCC Disposition The system must support the Describe how your Must Have Functional
destruction of records before they system meets the
have met their retention period requirement.
(expungement of records). The
system must restrict the approval of
expungements to the Records
Manager and Analysts.
4.13.004 OCC Disposition The system must permit authorized Describe how your Must Have Functional
users to generate one or more system meets the
Page 21 of 48
RFP No. MSO0037
Physical Records Management System Requirements
Req ID Owner Category Requirement Response Priority ReqType
notifications (the destruction requirement.
authorization memo) requiring
departmental Records
Administrators to provide
confirmation/approval before the
destruction operation is executed.
4.13.005 OCC Disposition The system must permit authorized Describe how your Must Have Functional
users to add/remove items from a system meets the
destruction authorization memo. requirement.
4.13.006 OCC Disposition The system must permit authorized Describe how your Must Have Functional
users to generate a destruction system meets the
notification report for the purpose of requirement.
review by the City’s archives, the
Austin History Center (AHC). The
Austin History Center must review
select destruction authorization
memo before it goes to the
department responsible for the
records so that items of historical
value can be identified. The system
must provide a method to “flag”
boxes that have been so identified.
The destruction authorization
memos sent to departments for
review should identify the boxes that
have been flagged for transfer to the
Austin History Center.
4.13.007 OCC Disposition The system must provide a method Describe how your Must Have Functional
to manage the destruction system meets the
cancellation and reassignment requirement.
process: instances in which the
departmental response to a
destruction authorization memo is
that the boxes belong to another
department. The system must
provide a method to cancel the
destruction authorization memo,
change department codes, and
resume the destruction process.
4.13.008 OCC Disposition The system must provide a method Describe how your Must Have Functional
to identify items that are currently system meets the
checked out from the Records requirement.
Center and have met their retention
period. The system must provide a
method to notify the department in
possession of the records that they
are responsible for the destruction.
4.13.009 OCC Disposition The system must provide a method Describe how your Must Have Functional
Page 22 of 48
RFP No. MSO0037
Physical Records Management System Requirements
Req ID Owner Category Requirement Response Priority ReqType
to process the preliminary and final system meets the
destruction listings received in Excel requirement.
format from Iron Mountain, in order
to compare the contents of this
report against the contents of the
destruction requests/pick-lists sent to
them.
4.13.010 OCC Disposition The system must provide an option Describe how your Must Have Functional
allowing the City to select whether to system meets the
retain or delete the metadata of requirement.
destroyed records.
4.13.011 OCC Disposition The system must provide a method Describe how your Must Have Functional
for tracking the transfer of records to system meets the
the Austin History Center. requirement.
4.13.012 OCC Disposition The system must restrict the final Describe how your Must Have
records destruction, expungement, system meets the
transfer approval to authorized requirement.
users.
4.13.013 OCC Disposition The system must provide Describe how your Must Have Functional
documentation of system meets the
destruction/expungement/transfer requirement.
activities (certificates of destruction).
This documentation will be retained
as records.
4.13.014 OCC Disposition The system must update the status Describe how your Must Have Functional
of destroyed/expunged/transferred system meets the
boxes and add the requirement.
destruction/expungement event to
the boxes’ audit/history logs.
4.13.015 OCC Disposition The system must provide the Describe how your Must Have Functional
capability for bulk updating of box system meets the
and file metadata as a result of requirement.
destruction, expungement, or
transfer actions.
4.13.016 OCC Disposition The system must support the Describe how your Must Have Functional
capability for only authorized users to system meets the
extend or suspend (freeze) the requirement.
retention period of records beyond
their scheduled disposition. The
system must provide a field for
authorized users to enter the
reasons for freezing a box.
4.13.017 OCC Disposition The system must provide a method Describe how your Must Have Functional
to identify boxes that have been system meets the
frozen and provide authorized users requirement.
Page 23 of 48
RFP No. MSO0037
Physical Records Management System Requirements
Req ID Owner Category Requirement Response Priority ReqType
the capability to unfreeze them.
4.13.018 OCC Disposition The system must allow authorized Describe how your Must Have Functional
users to search, update, and view system meets the
the reasons for freezing a record or requirement.
record folder.
4.13.019 OCC Disposition The system must provide a means Describe how your Must Have Functional
to generate performance metrics system meets the
reports on destruction processing requirement.
activities including, but not limited to:
number of destruction authorization
memos sent out, number of items
actually destroyed, records
transferred to the History Center,
records frozen, etc.
4.13.020 OCC Disposition Must provide a method to track a Describe how your Must Have Functional
complete history of all of the events system meets the
associated with items on a requirement.
destruction authorization memo
including, but not limited to (a)
destruction authorization memos
sent to the Austin History Center; (b)
responses from the Austin History
Center; (c) first destruction
authorization memos sent to
departments; (d) second reminders
sent to departments; (e)
confirmations returned from
departments; (f) destruction requests
sent to Iron Mountain; (g) preliminary
destruction listing received from Iron
Mountain; (h) confirmation from Iron
Mountain that items have been
destroyed.
4.13.021 OCC Disposition Certain permanent records are also Describe how your Must Have Functional
microfilmed for retention purposes. system meets the
The system must support the ability requirement.
to link a box with a reel of microfilm
and a new box number containing
the microfilm version of the records.
The system must provide a method
to track the history of events
associated with microfilming records
and support generating performance
metrics reports on microfilming
activities.
Page 24 of 48
RFP No. MSO0037
5.0 TECHNICAL REQUIREMENTS
5.1 Technology Environment at the City of Austin
The City has a heterogeneous environment using various operating systems. It is
important that software applications allow the City the flexibility to choose among LAN
vendors and desktop vendors in the future. Thus, Web-based and RFC compliant
systems are given preference.
City workstations are mostly Windows XP based but there are also Linux desktops. The
systems are 350MHz and above, with 256MB memory and 30GB hard drives used for all
software applications. The selected solution must accommodate MS Office 2003 or
higher, including Office XP and the latest version now in beta testing format.
The LAN environment is mostly Active Directory 2003 but the selected solution should
provide support for the Windows Vista when it becomes available. The solution should
also support NFS and NIS for UNIX platforms. Being LDAP compliant is important to the
City, as it will allow the software application to use various authentication systems.
The Vendor should assume 100/1000 Mbps, full duplex, data transfer rate for the
communications between servers and between servers and core switches with the
standard workstation communicating with the network at a speed of 10 Mbps, full duplex.
The network has many ISDN links that must be considered in the Vendor’s proposal.
Network time source will use NTP protocol and is available on the TCP/IP network.
The City of Austin manages and monitors its private fiber network via Computer
Associate’s Spectrum Management System on its wired network.
The public front-end Web servers are standardized on Apache and Red Hat for security
reasons. Database platforms have been standardized on IBM AIX P Series and Oracle.
Windows systems are acceptable for other tiers of a system if appropriate.
5.2 Responding To Technical Requirements
To ensure that a proposed solution is thoroughly represented, Vendors should respond to
each requirement below in Attachment B, Vendor Response Access Database according
to the instructions in Attachment A, Vendor Response Access Database Instructions.
Note: All proposed solutions should respond to section 5.03. If the proposed solution is a
client-server or internally hosted solution, respond to the requirements in section 5.04. If
the proposed solution is an externally hosted solution (ASP) respond to the requirements
in section 5.5.
5.3 Table of Technical Requirements – All Solutions
Physical Records Management System Requirements
Req ID Owner Category Requirement Response Priority ReqType
5.03.001 All Solutions Application The desktop component of Describe what Expected Technical
Software the solution should be able operating environment
to run on the MS XP is used by the solution.
Operating System (City Indicate whether
desktops are managed via Microsoft Vista is (or
the network). will be) supported.
Page 25 of 48
RFP No. MSO0037
Physical Records Management System Requirements
Req ID Owner Category Requirement Response Priority ReqType
5.03.002 All Solutions Application If the solution is client- Describe how users Expected Technical
Software server architecture, the can be operated by
client software should be remote access over a
Citrix compliant. network via Citrix
sessions. Indicate
whether the proposed
solution is currently
running successfully in
a Citrix environment at
customer sites.
5.03.003 All Solutions Application The vendor must identify List any third-party Expected Technical
Software any third-party software software products used
products used within the within the proposed
proposed system configuration. Include
configuration. third-party DB
management products,
report/query tools,
client-side products
required. Also list any
third-party tools
supported, but not
provided (I.e. report
writing tools).
5.03.004 All Solutions Application Patch updates to operating Describe how patch Expected Technical
Software system software, updates are tested and
application software, approved for
database software and implementation within 5
client software should be days of a new patch
tested and identified for release (i.e. server,
implementation within 5 OS, application,
days of a new patch browser, and
release. database). Provide the
average time required
by your organization to
test and approve
patches and upgrades
for operating systems,
application software,
and other components
of the entire working
solution.
5.03.005 All Solutions Application The Vendor should provide Provide the Expected Technical
Software documentation detailing the documentation of the
technical architecture of the solution and indicate its
components of this limitations. Provide a
solution, including a simple simple diagram of the
network architecture proposed solution
diagram. architecture, showing
Page 26 of 48
RFP No. MSO0037
Physical Records Management System Requirements
Req ID Owner Category Requirement Response Priority ReqType
the hardware
components and
indicating the types of
data exchange
between components.
5.03.006 All Solutions Application The proposed solution List any dependencies Expected Technical
Software client software should not that the proposed
depend on Microsoft Office solution has on
applications for proper Microsoft Office
operation. applications.
5.03.007 All Solutions Business The proposed solution Explain how the Must Have Technical
Continuity must be capable of solution can be
providing 99.9% uptime if designed to support
the City of Austin chooses this level of uptime.
to require it. This level of Indicate tools and
availability may be directly methods supported by
supported by the proposed the solution to provide
solution, or may use third- the uptime requirement
party tools and methods to (such as hardware fault
achieve 99.9% uptime. tolerance, clustering,
mirroring, high
availability platforms,
etc.). Annotate the
provided
network/system
diagrams to illustrate.
5.03.008 All Solutions Business If data archiving is Describe the limits for Expected Technical
Continuity provided, the solution archiving data.
should enable data storage Describe how data is
and retrieval from archived stored and retrieved.
data.
5.03.009 All Solutions Business If data archiving is Describe the solution’s Expected Technical
Continuity provided, the solution data archiving solution.
should allow a user with Indicate if a user with
appropriate privileges to appropriate privileges
define datasets to be can define datasets to
archived, retention periods be archived, retention
for current and archived periods for current and
data, and the date and time archived data, and the
of archival. date and time of
archival. Describe all
other user-definable
features of the
archiving function.
5.03.010 All Solutions Business The solution should be able Explain how certain Expected Technical
Continuity to recover specific data selected records and/or
Page 27 of 48
RFP No. MSO0037
Physical Records Management System Requirements
Req ID Owner Category Requirement Response Priority ReqType
records and/or files. files can be recovered
from backup data and
made available to the
application.
5.03.011 All Solutions Business The solution should be Provide the number of Expected Technical
Continuity scalable for future growth. concurrent users the
proposed system can
support, and explain
the software and
hardware changes
required to allow
growth. Include the
licensing structure and
the cost levels.
5.03.012 All Solutions Data The Vendor should explain Describe the Expected Technical
Management the relationships between relationships between
data stored on the main data stored on the main
servers, the report servers, servers, the report
the training servers, the servers, the training
archive servers, and any off servers, the archive
line data. servers, and any off
line data.
5.03.013 All Solutions Data The application should Describe the methods Expected Technical
Management manage concurrent data or technologies used by
updates by multiple users the solution to prevent
without creating deadlocks data loss or deadlock
or data loss. conditions when
multiple users are
updating data.
5.03.014 All Solutions Data The solution should provide Explain the process for Expected Technical
Management a method for archiving archiving historical
historical data. data. Include
information on
archiving, retrieval, and
purging record data
and attached
documents. Describe
features available to
authorized users for
selecting records for
archiving.
5.03.015 All Solutions Data The solution database Provide a data Expected Technical
Management should be well- dictionary and Entity
documented, including a Relationship Diagram
current data dictionary and (ERD) for the proposed
Entity Relationship solution.
Diagram...
Page 28 of 48
RFP No. MSO0037
Physical Records Management System Requirements
Req ID Owner Category Requirement Response Priority ReqType
5.03.016 All Solutions Data Future releases of the Describe how Expected Technical
Management application should NOT historically archived
render archived data data is supported
unusable. regardless of changes
to the application data
schema.
5.03.017 All Solutions Interfaces If email is used within the Describe the Desired Technical
application, the email application’s
component should be messaging
SMTP and/or Microsoft architecture, and
Exchange compliant and indicate if the solution
provide a messaging is SMTP and/or
development environment Microsoft Exchange
through the provision of compliant and how it
documented APIs. provides a
development
environment through
the provision of APIs.
5.03.018 All Solutions Network The Vendor should use Explain how that the Expected Technical
standard Domain Name system uses standard
Services (DNS) for Domain Name Services
identifying all server (DNS) for identifying all
components in the system. server components in
the system.
5.03.019 All Solutions Network TCP/IP common Describe how the Expected Technical
transmission and systems uses TCP/IP
management protocol must common transmission
be used as the sole and management
network protocol for both protocol as the sole
LANs and WANs. network protocol for
both LANs and WANs.
Identify any non-
TCP/IP protocols used
in the solution (i.e.
SMB, NETBEUI)
5.03.020 All Solutions Performance The Vendor should provide Describe a backup Expected Technical
a backup process that does process that does not
not impact the performance impact the
of the core system or the performance of the
availability of online data. core system or the
availability of online
data. If the proposed
solution does not
include a backup tool,
recommend one that
has been tested with
your system.
5.03.021 All Solutions Security When the vendor is Describe how solution Must Have Technical
Page 29 of 48
RFP No. MSO0037
Physical Records Management System Requirements
Req ID Owner Category Requirement Response Priority ReqType
connected to the City’s support personnel use
VPN for solution support VPNs to support the
purposes, single tunneling application at the
is required (which means customer site, and
that they are disconnected indicate whether single-
from their local network tunneling will be
during the VPN session). enforced.
5.03.022 All Solutions Security If the solution provides a Describe how the Must Have Technical
Web server, the solution’s solution’s Web
Web interface must be able interface is able to
to operate a secure operate a secure
communication session as communication session
SSL 128 bit encrypted as SSL 128 bit HTTPS.
HTTPS.
5.03.023 All Solutions Security The solution must provide Explain all password Must Have Technical
and enforce complex format options provided
password formats. by the solution, and
Passwords must be a how passwords are
minimum of 8 characters, managed and
and must allow use of enforced.
upper and lower case and
numeric and special
characters.
5.03.024 All Solutions Security Passwords must not be Describe how system Must Have Technical
displayed as readable text allows end users to
when users are entering type in their password
them on-screen in a non-printing, non-
displaying manner (i.e.
*****).
5.03.025 All Solutions Security Passwords must NOT be Explain how passwords Must Have Technical
included in automated sign- are managed, stored
on procedures, stored and transmitted over
unencrypted in cache, or the network.
transmitted as clear text
over the network.
5.03.026 All Solutions Security The solution should not Describe the level of Expected Technical
require operating system privileges required to
administrator privileges on install application
the client workstation(s) to updates and indicate if
run or receive application the application requires
updates. workstation
administrator privileges
to execute or update.
5.03.027 All Solutions Security When new users are Describe the process of Expected Technical
created, the security creating a new user in
permissions assigned to the system, and explain
the new accounts should the default system
Page 30 of 48
RFP No. MSO0037
Physical Records Management System Requirements
Req ID Owner Category Requirement Response Priority ReqType
default to least privileged. privileges assigned to
new user accounts.
5.03.028 All Solutions Security To maintain network Provide a list of re- Expected Technical
security, the solution should assignable ports
include re-assignable ports utilized by the solution.
for the solution.
5.03.029 All Solutions Security The solution should Describe how the Expected Technical
minimize the number of solution minimizes the
different IP ports and number of IP ports and
protocols to limit exposure protocols used and
and simplify security provide a list of IP ports
administration. and protocols utilized.
5.03.030 All Solutions Security To help enforce Customer’s Describe how the Expected Technical
security policies, the solution allows the
solution should allow the Administrator to lock
Administrator to disconnect out a particular user
a particular user and to lock and to disconnect a
out a user during an active user during an active
session. session.
5.03.031 All Solutions Security Administrator users should Describe how Expected Technical
be able to define the Administrator users
number of login attempts define the number of
allowed before a user login attempts before a
account is locked and/or user account is locked
disabled. and/or disabled.
5.03.032 All Solutions Security The solution should log an Describe how the Expected Technical
event and alert the solution logs an event
Administrator when a user and alerts the
exceeds login attempts. Administrator when a
user exceeds login
attempts.
5.03.033 All Solutions Security The system must Explain the process Expected Technical
automatically log-off a used to define an
user’s work session due to inactivity time-out
inactivity within a period, and describe
Customer-defined period. what happens when the
application detects an
inactivity time-out.
5.03.034 All Solutions Security The application should Describe how the Expected Technical
allow the Application Application
Administrator to restrict Administrator can
generic logins. restrict generic logins.
5.03.035 All Solutions User Interface If the proposed application Provide a list of web Expected Technical
is web-based, the browsers and browser
application must provide versions supported by
user functionality through
Page 31 of 48
RFP No. MSO0037
Physical Records Management System Requirements
Req ID Owner Category Requirement Response Priority ReqType
XHTML 1.0-compliant Web your application.
browsers including, but not
limited to, Internet Explorer
V6 or above and Firefox
V1.5 or above.
5.4 Table of Technical Requirements - Client-Server or Internally Hosted Solution
Physical Records Management System Requirements
Req ID Owner Category Requirement Response Priority ReqType
5.04.001 Customer- Application If the solution uses Oracle, For Oracle databases, Must Have Technical
Hosted Only Software it must use minimum describe what version
release level of version of Oracle the database
10g. supports and if 9i can
be updated to 10g.
5.04.002 Customer- Application Executable server software Explain how server- Must Have Technical
Hosted Only Software processes must be capable side software
of running as service(s) (or processes are
daemon(s)) that run executed automatically,
automatically upon system and indicate whether
start-up, and do not require the processes are
a user login to start up. designed to be service
(or daemon)
processes.
5.04.003 Customer- Application The solution should be Describe how the Expected Technical
Hosted Only Software capable of utilizing solution supports a
computer storage devices SAN storage solution.
(SAN).
5.04.004 Customer- Architecture If applicable, the solution Explain how the Expected Technical
Hosted Only should be implemented solution is implemented
using N-tier architecture. N- within the N-tier
tier implementation should architecture, including
be capable of supporting load balancing across a
load balancing across a series of solution
series of solution servers. servers.
5.04.005 Customer- Architecture The City prefers List the operating Desired Technical
Hosted Only Linux/UNIX OS for public systems on which each
web servers. Windows and component of your
Linux/UNIX operating application will run. If
systems are acceptable for choices exist, indicate
internal servers. the OS’s most
commonly used by
existing clients.
Page 32 of 48
RFP No. MSO0037
Physical Records Management System Requirements
Req ID Owner Category Requirement Response Priority ReqType
5.04.006 Customer- Architecture Linux/UNIX or Windows List the operating Desired Technical
Hosted Only operating systems are systems on which each
preferred for application component of your
servers. application will run. If
choices exist, indicate
the OS’s most
commonly used by
existing clients.
5.04.007 Customer- Business The proposed solution Describe the data and Must Have Technical
Hosted Only Continuity must be capable of being application backup and
fully restored in the event of recovery plan including
catastrophic server failures. automatic and
unattended backups,
expected data loss
from recovery, backups
in a separate facility
from the production
system, and
allowances for full or
partial recovery.
5.04.008 Customer- Business The Customer should be Provide capacity Expected Technical
Hosted Only Continuity able to accurately plan for estimates (in terms of
storage and backup GB of storage) for the
requirements, both for initial proposed system on-
implementation and for line storage and data
future growth. archives.
5.04.009 Customer- Business The solution should be Describe your support Expected Technical
Hosted Only Continuity supported in a virtual server for running the
environment based on application software on
VMware Infrastructure 3. VMWare or other
virtual server
environments.
5.04.010 Customer- Business The RDBMS used by the Explain how the Expected Technical
Hosted Only Continuity solution (if applicable) solution’s RDBMS
should support transaction supports transaction
logs and allow a data logs and allows for a
restore from transaction data restore from those
logs. logs.
5.04.011 Customer- Business The system should include Describe the backup Expected Technical
Hosted Only Continuity a backup and recovery plan and recovery plan. It
for data, data structures, should address
application software files, automatic and
executables, and unattended backups,
application software expected data loss,
utilities. The plan should backups in a separate
include a backup test plan. facility from the
production system,
emergency notification
Page 33 of 48
RFP No. MSO0037
Physical Records Management System Requirements
Req ID Owner Category Requirement Response Priority ReqType
procedures, and
procedures for full or
partial recovery.
5.04.012 Customer- Business If the solution uses Describe how the Expected Technical
Hosted Only Continuity relational database solution RDBMS can
management technology, it provide availability and
should be capable of resiliency through the
supporting high availability use of such
and resiliency. technologies as mirror
imaging, portability, and
replication.
5.04.013 Customer- Business The software environment Describe how the Expected Technical
Hosted Only Continuity should be capable of solution is capable of
dynamically accepting dynamically accepting
changes to network changes to network
configurations with little or configurations with no
no impact on solution impact on solution
availability (i.e. Installing availability (i.e.
additional Changing the IP or
servers/workstations and subnet of any of the
changing the IP or subnet servers should not
of any of the servers). affect operation).
5.04.014 Customer- Business If the proposed solution Describe how the Desired Technical
Hosted Only Continuity includes fail-over, the fail- system performs
over event should be automatic fail-over
completely automated. between redundant
systems in the event of
system failure for both
the application and the
database.
5.04.015 Customer- Data The solution should use a Describe the database Must Have Technical
Hosted Only Management widely-accepted and well- system(s) and version
supported DBMS such as numbers supported by
Oracle 10g (or higher) or the solution. (Oracle
MS SQL 2000 SP3. systems with
processor-level
licensing are preferred
but MS SQL is
accepted.)
5.04.016 Customer- Data The Vendor should provide Provide Expected Technical
Hosted Only Management recommendations for recommendations for
tuning parameters for all tuning parameters for
databases. all databases. Explain
the reasoning for these
recommendations.
5.04.017 Customer- Data If the proposed solution Explain how the Expected Technical
Hosted Only Management uses an RDBMS system RDBMS used by the
other than Oracle 10g (or solution supports two
Page 34 of 48
RFP No. MSO0037
Physical Records Management System Requirements
Req ID Owner Category Requirement Response Priority ReqType
higher) or MS SQL 2000 phase commit
SP3 (or higher), the procedures.
RDBMS should support two
phase commit procedures.
5.04.018 Customer- Data If the proposed solution Provide evidence that Expected Technical
Hosted Only Management includes a relational the proposed RDBMS
database management is ACID compliant.
system other than Oracle or
MS SQL, the RDBMS must
be ACID compliant.
5.04.019 Customer- Network The solution should be able Describe how the Must Have Technical
Hosted Only to run in a switched and solution runs in a
routed network switched and network
environment. environment.
5.04.020 Customer- Network The solution should be able Describe how the Must Have Technical
Hosted Only to run in an environment solution runs in an
that uses 100/1000MB full environment that uses
duplex connections for 100/1000MB full duplex
back-end systems. connections for back-
end systems.
5.04.021 Customer- Network If the proposed solution Provide specifications Must Have Technical
Hosted Only includes electronic on network interfaces
hardware such as servers of all network-enabled
or network devices, all devices proposed.
network-enabled hardware
must support auto-
negotiation of network
speeds and duplex
settings, including 10 mbps,
100 mbps and Gigabit
Ethernet, if applicable.
5.04.022 Customer- Network Application servers should Explain any limitations Must Have Technical
Hosted Only NOT require Layer 2 relating to Layer 2
adjacency. adjacency
requirements for the
proposed application.
Can all application
server components be
separated on different
network segments or
subnetworks?
5.04.023 Customer- Network The proposed application Explain how inter- Must Have Technical
Hosted Only should NOT require static network
network routes. communications are
supported in the
application without the
need for statically
Page 35 of 48
RFP No. MSO0037
Physical Records Management System Requirements
Req ID Owner Category Requirement Response Priority ReqType
assigned routes.
5.04.024 Customer- Network The proposed solution If the application must Must Have Technical
Hosted Only must not require broadcast use broadcast
messaging for normal messaging, describe
operation. the purpose and
functionality of
broadcasting.
5.04.025 Customer- Network The solution should be able Describe how the Expected Technical
Hosted Only to run in a VLAN solution runs in a VLAN
environment. environment. Note any
limitations of running
the solution in a VLAN
environment.
5.04.026 Customer- Network The application servers Describe how the Expected Technical
Hosted Only should support the use of various solution
fully-qualified domain components can
names, rather than short address one another,
names or IP addresses and indicate
only. compliance with this
requirement.
5.04.027 Customer- Network The proposed solution Provide documentation Expected Technical
Hosted Only should be compatible with, of application/data
and easily supported on the traffic including
Customer’s native network protocols and ports.
infrastructure. List the ports and
protocols used for data
communication
between each tier of
the application. Note
any exceptional
aspects of the
application
communication
architecture.
5.04.028 Customer- Network The proposed solution Explain how the Expected Technical
Hosted Only must be capable of proposed solution
operating over routed components can
subnetworks (does not communicate with each
require components to be other when separated
co-located on the same on different
subnetwork). subnetworks.
5.04.029 Customer- Security The solution should provide Describe what Expected Technical
Hosted Only RADIUS, LDAP, or MS authentication methods
Active Directory are supported by the
authentication to provide application software.
authentication to the
application software.
Page 36 of 48
RFP No. MSO0037
Physical Records Management System Requirements
Req ID Owner Category Requirement Response Priority ReqType
5.04.030 Customer- Security All Windows-based Describe how the Expected Technical
Hosted Only solutions deployed on both application is tested
client workstations and and validated as being
servers should be compatible with the
compatible with Trend Trend Micro Anti-Virus
Micro Anti-Virus, KACE application, KBOX, and
KBOX, and SMS for SMS.
servers and workstations.
5.5 Table of Technical Requirements – ASP Solution
Document Management System Requirements
Req ID Owner Category Requirement Response Priority ReqType
5.05.001 ASP-Hosted Business The Vendor should Provide a copy of your Expected Technical
Only Continuity maintain a recovery recovery test plan and
test plan and recovery procedures, and provide
test procedures that documentation of
result in a full recovery periodic tests performed.
of the system following
full and partial system
failures.
5.05.002 ASP-Hosted Data Hosted solutions must Describe how Customer Must Have Technical
Only Management support off-line storage can create and
of Customer data at periodically update off-
Customer’s site. line copies of Customer
data. Explain the types of
connections available to
retrieve data, and how
data retrieval can be
scheduled.
5.05.003 ASP-Hosted Data Authorized users must Explain how current and Must Have Technical
Only Management be able to receive a historical data can be
complete copy of received by Customer if
current and archived the contract is terminated
data hosted by an ASP for any reason.
provider in the event of
contract termination.
5.05.004 ASP-Hosted Network The application’s client Describe the minimum Expected Technical
Only should be capable of client bandwidth required,
running over a low- and the recommended
speed connection of as bandwidth.
slow as 128kbps.
Page 37 of 48
RFP No. MSO0037
Document Management System Requirements
Req ID Owner Category Requirement Response Priority ReqType
5.05.005 ASP-Hosted Security The vendor must Describe how an external Must Have Technical
Only conduct a 3rd party audit of the proposed
annual security system security will be
assessment of all tiers provided.
of its hosting facility,
including application
servers and network
devices. Copies of the
security audit reports
must be provided to the
Customer annually.
5.05.006 ASP-Hosted Security All user access must Describe what user Must Have Technical
Only be logged with time- access logs are kept and
stamped entries, and made available to
the log made available Customer, and how they
to the Customer. are accessed.
5.05.007 ASP-Hosted Security Customer data must Describe how Customer Must Have Technical
Only not be made available data is protected from
to any other parties not access by unauthorized
specifically authorized parties.
to view or access the
data.
5.6 External Interfaces - Responding to External Interfaces
This section addresses the various systems, applications and databases that are required
to interface with the solution. Vendor should respond with the base data elements and
potential data elements that can be downloaded to their system. IE: systems that may be
accessed using a separate terminal session, such as dial-up, are not considered to be
interfaces and will not be addressed in this section.
5.7 Name of System - Interface
Criticality: Expected
Requirement Description: The solution should be able to interface with Iron
Mountain’s IM Connect System or similar Company applications.
Required Response: State if your product is web based and will permit access
to authorized City of Austin personnel
Purpose of Interface: COA Physical Document Storage Management System
Type of Interface: Two Way
Description of Data Transfer: Physical Record Management
Application Software, Database or Data Structure
Type
Brand Name or Name
Version
Language Oracle
Page 38 of 48
RFP No. MSO0037
Database Engine Oracle
Database Engine Version Oracle 10g
File Format and Field Definitions
Data Structure Dictionary
Application Access Requirements, Formats, Parameters
Hardware
Hardware Type
Brand Name
Model Number
Operating System or Network Operating System Windows 2003 enterprise
Operating System Version Enterprise 2003
Network Connectivity
Type of Media
Network Type
Protocol Type
Page 39 of 48
RFP No. MSO0037
6.0 IMPLEMENTATION REQUIREMENTS
6.1 Responding To Implementation Requirements
Vendors should respond to the implementation requirements by providing the
documentation, plans and other information as indicated in section 6.2 below.
6.2 List of Implementation Requirements
6.2.1 Vendor’s Project Management Methodology
Responding Vendors must provide documentation describing their proven project
management methods. The City recognizes that each Vendor will recommend a project
management methodology that demonstrates a commitment to completing the project on
time and within budget. Documentation to be included:
Project Management Methodology (Model) Used
Explanation of the proposed project manager roles (functional and
technical)
Explanation of how the Methodology will be used in this project
Explanation of how risks will be managed
Explanation of how issues will be managed
Explanation of issues escalation process
Explanation of how issues are classified
Provide a timeline for the completion of this project
6.2.2 Required System Documentation
Vendors must describe the format for each document they will provide and be prepared to
deliver selected system documents upon request during the evaluation and selection
process. Prior to system acceptance, the selected vendor should provide the following
system documentation in hard copy.
One (1) complete set of maintenance and operations manuals for each
category of software or equipment purchased in association with this
project
Manuals for all software applications, hardware, and hardware
configurations for users and administrators
6.2.3 Training
The Vendor must provide a detailed training plan and training that
includes system administrator, technical training and end user training.
The Vendor must provide training materials that can be adapted for use by
City staff to conduct end user training.
The Vendor must submit recommendations on how to conduct ongoing
training for new users and training for future upgrades.
Page 40 of 48
RFP No. MSO0037
6.2.4 Maintenance
The Vendor must provide a plan for support and maintenance for a four year period
following final system acceptance and the warranty period. The plans should include
information on how to contact the Vendor, the availability of the Vendor support team, and
levels of service and associated response times. In addition, the plan should include
information regarding what software is supported in the maintenance plan, the cost of the
plan, information about warranties, and information about enhancements and upgrades.
7.0 PROPOSAL PREPARATION AND EVALUATION
7.1 Evaluation Criteria:
Criteria Description % of Total
Proposed Solution Viability Compliance with functional requirements 50
Compliance with technical requirements
Evaluated Cost Cost of base product, cost of maintenance 25
agreements, cost of optional items
The proposer with the lowest cost to the City
receives the maximum points; remaining proposers
are scored on a percentage ratio basis.
Experience Number of successfully installed sites 15
Customer references
Similar installations (size and scope)
Maturity of product
Maturity of company
Project Management Approach Project management methodology 10
Completeness of project management
documentation
On-site project manager
Qualifications and experience of project
management staff
Financial Viability of Company Company financials Pass/Fail
Financial ratings
Financial ratios
Sub total 100
Proposed Solution Demonstration Compliance with Demonstration Scripts 25
(Optional at the discretion of the Functional flow and User Interface Preferences
City)
7.2 Product and Proof of Concept Demonstration
Based on preliminary evaluation of proposals, some Vendors may be invited to come to
Austin and present a product and proof of concept demonstration to the City of Austin
Document Management System Team. The demonstrations must address each of the
Page 41 of 48
RFP No. MSO0037
functional and technical requirements. These demonstrations are used to further evaluate a
“short list” of Vendors’ proposals.
7.2.1 Demonstration Guidelines
Product and proof of concept demonstrations must address all functional
and technical requirements listed in Sections 4.0 and 5.0 of this RFP.
Vendors selected to provide demonstrations are required to submit a
demonstration agenda. The agenda should specifically identify when
Section 4.0 Functional Requirements and Section 5.0 Technical
Requirements are addressed and demonstrated during the sessions so that
appropriate groups of users can attend. The agenda is used to formulate an
evaluation worksheet used by demonstration attendees from the Document
Management System Team.
Demonstrations are attended by project team members and end users from
the departments involved.
Vendors must provide the appropriate technical personnel to attend
demonstration sessions.
7.3 Vendor Qualifications
The City of Austin seeks proposals from Vendors who can demonstrate evidence of
completed installations within the last five years that ideally meet the following
requirements:
The Vendor should provide evidence of completed installations of systems
similar in scope to those used in this project.
The Vendor should demonstrate that the proposed system is securely
operating at one or more customer sites connected by wide area computer
networks and utilizing the Internet.
The Vendor should meet all requirements presented in Sections 4.0 and 5.0
of this RFP that are noted with a Criticality ranking of “Must Have.”
Vendors are encouraged to attend the pre-proposal conference as part of
the process.
7.4 Mandatory Submittals
7.4.1 RFP Responses
The following must be submitted:
One signed original and ten (10) hardcopies of the RFP response.
Two (2) copies of the RFP response on CD-ROM (compatible with
Microsoft Windows).
Two (2) copies of the completed Microsoft Access database (Appendix
B) on CD-ROM (see Appendix A for instructions).
Page 42 of 48
RFP No. MSO0037
One (1) copy of the completed Microsoft Access database (Appendix B)
hardcopy (with original copy of the proposal)
7.5 Proposal Format
The Vendor proposal must be submitted in the format shown below with at minimum, the
following subject headings and information included:
7.5.1 Executive Summary
The Executive Summary with the following information:
Name of the proposing firm
Address of the proposing office
Contact names, telephone numbers, fax numbers, and e-mail addresses for
individuals authorized to answer technical, price, and/or contract questions
Summation of proposal
Explanation of the suitability of product (10 pages or less)
Statement of assumptions made
7.5.2 Table of Contents
The Table of Contents shall include the following:
Index of the proposal contents
Index of tables and figures
Index of attachments
7.5.3 Firm Background, Principal Officers and Prior Experience
This section will include the following items:
Listing of the principal officers of the company, including name, title and
tenure.
Audited financial statements for the past two years. In the event that
audited financial statements cannot be provided, the Vendor must provide
financial information that will enable the City to accurately assess
financial stability and viability. Provide the same information for any
entity that will participate in this project through a joint venture or
subcontract arrangement.
Project management organizational chart identifying the Project Manager
and full time/part time project staff members, including resumes for
project personnel and the amount of time each project staff member will
be dedicated to the project.
Name, address, phone, e-mail and fax number of the authorized negotiator.
Page 43 of 48
RFP No. MSO0037
7.5.4 Response to Functional Requirements (Section 4.0)
The vendor must provide a detailed response for each functional requirement that is listed
in Section 4.0 of this document. Vendors must respond to each requirement in Appendix
B, Vendor Response Access Database according to the instructions in Appendix A,
Vendor Response Access Database Instructions.
7.5.5 Response to Technical Requirements (Section 5.0)
The vendor must provide a detailed response for each technical requirement listed in
Section 5.0 of this document. Vendors must respond to each requirement in Appendix B,
Vendor Response Access Database according to the instructions in Appendix A, Vendor
Response Access Database Instructions.
7.5.6 Response to Implementation Requirements (Section 6.0)
The vendor must provide a detailed response for each implementation requirement listed
in Section 6.0 of this document.
7.5.7 Response to Proposal Preparation and Evaluation (Section 7.0)
The vendor must provide the documentation, plans and information described in section
7.0 of this document as indicated.
7.5.8 Operation Site References
Provide four (4) customer references, which are operating a fully
functional system. Provide a list of work performed for municipalities
similar in size to Austin, Texas (population of 1 million). References
should include system implementations that involve the use of an
outsourced records management services provider, such as Iron Mountain.
References must include the following information:
Name of Company
Number of personnel
Contact name – sponsor or IT Lead
Contact address
Contact telephone number
Contact fax number
Contact e-mail
System description (hardware and software configuration, version number
of software and network configuration)
Date of system installations
7.5.9 System Updates and Modifications
Vendor must provide policy and pricing methodology for the following:
Minor revision upgrades to the installed system
Page 44 of 48
RFP No. MSO0037
Major revision upgrades to the installed system
Bug fix releases
Product enhancements (new features)
7.5.10 Cost Proposal
Vendor must provide all costs associated with this project:
Software
Third party software
Project Management Services
Annual Maintenance & Support (for four years following final system
acceptance and the warranty period)
Source code escrow
Other costs
Travel expenses. All travel lodging expenses in connection with the Contract for which
reimbursement may be claimed by the Contractor under the terms of the Solicitation will
be reviewed against the City’s Travel Policy as published and maintained by the City’s
Controller’s Office and the Current United States General Services Administration
Domestic Per Diem Rates (the “Rates”) as published and maintained on the Internet at:
http://www.gsa.gov/Portal/gsa/ep/contentView.do?contentId=17943&contentType=GSA_BASIC
No amounts in excess of the Travel Policy or Rates shall be paid. All invoices must be
accompanied by copies of detailed receipts (e.g. hotel bills, airline tickets). No
reimbursement will be made for expenses not actually incurred. Airline fares in excess of
coach or economy will not be reimbursed. Mileage charges may not exceed the amount
permitted as a deduction in any year under the Internal Revenue Code or Regulations.
7.6 Proposal Acceptance Period:
All proposals are valid for a period of one hundred and twenty (120) calendar days
subsequent to the RFP closing date unless a longer acceptance period is offered in the
proposal..
7.7 Exceptions
Be advised that exceptions to any portion of the Solicitation may jeopardize acceptance of
the Proposal.
7.8 Proposal Preparation Costs
All costs directly or indirectly related to preparation of a response to the RFP or any oral
presentation required to supplement and/or clarify a proposal which may be required by
the City shall be the sole responsibility of the Proposer.
7.9 Contract Payment and Retainage
The contract shall be prepared under the direction of the City, and shall incorporate all
applicable provisions. A firm fixed price or not to exceed contract is contemplated, with
progress payments per the milestone payment schedule.
Page 45 of 48
RFP No. MSO0037
Ten percent (10%) of the total contractual price will be retained until submission and
acceptance of the final work products. These payments shall be based upon milestones
completed.
The Contractor’s invoice shall indicate the amount due, less the retainage. Upon final
acceptance of the work, the Contractor shall submit an invoice for the retainage to the
City and payment will be made as specified in the Contract. Payment of the retainage by
the City shall not constitute nor be deemed a waiver or release by the City of any of its
rights and remedies against the Contractor for recovery of amounts improperly invoiced.
7.9.1 Milestones
Milestone When %
System Installed and tested After the system is 20%
(Deliverable #1) successfully installed and
tested
Migrate data from legacy After data is successfully 30%
system (Deliverable #2) migrated from the legacy
system and validated as
complete and accurate
City records controls/retention After the City’s records control 20%
schedules in place (Deliverable (retention) schedules are
#3) implemented in the new
system
User Training completed After successfully delivering 20%
(Deliverable #4) the required training to
Records Managers,
administrators, and Records
Center Staff (train-the-trainer
training)
Application documentation After delivery of the 10%
delivery (Deliverable #5) documentation listed in
Deliverable 5, in the following
section.
Total Total 100%
Note: Ten percent (10%) of the total contractual price will be retained until submission and
acceptance of the final work products
7.9.2 Deliverables
Deliverable # Deliverable Description
Complete system installation Delivery, installation, and successful acceptance testing
and acceptance testing of a browser-based records center application that can be
1
accessed by authorized personnel within all City
departments based on established security parameters.
Page 46 of 48
RFP No. MSO0037
Migrate data from legacy Successful migration of the data from the legacy GAIN
system to new system 2000 system and metadata stored in a custom Oracle
2 database maintained by the Watershed Protection and
Development Department must be complete and verified
as accurate.
Implement City’s Control and Successful implementation of the City’s control/retention
3 retention schedules schedules in the system must be complete and verified
as accurate.
Completion of User and Delivery of training on the user and administrative
Admin training functions of the application to be provided to City of
4 Austin personnel by the vendor. Includes delivery of
training manuals, quick reference guides, and other
training materials.
Deliver application Delivery of documentation including user guides,
documentation technical manuals, installation procedures, and other
5
system documentation required for ongoing operations,
and maintenance of the system.
7.10 Source Code Escrow Agreement
At the City of Austin’s option, the Contractor’s source code shall be placed in escrow
deposit with a nationally recognized escrow firm for the benefit of the City of Austin.
Escrow deposits by the Contractor shall be kept current with all modifications, releases
and fixes throughout the life of the System. Break out this cost separately in your cost
proposal.
Page 47 of 48
RFP No. MSO0037
8.0 LIST OF APPENDICES FOR THIS RFP:
Appendices
Appendix A: Vendor Response Access Database Instructions
Appendix B: Vendor Response Access Database
Page 48 of 48
