***********************************************************************************************

STATE OF CONNECTICUT REQUEST FOR PROPOSALS (RFP 989-A-23-7052-C)

***********************************************************************************************

FORWARD

1.1. Objective

The Department of Information Technology (DOIT) is responsible for "The purchase and provision of supplies, materials, equipment and contractual services, as defined in section 4a-50" (CGS Sec 4a-2). Within DOIT, the Contracts and Purchasing Division (CPD) is responsible for processing and authorizing all procurement activities for information Technology, including telecommunication.

The DOIT Vision is "That the State of Connecticut's information technology is integrated, eliminating duplication and redundancy, while allowing for the sharing of information and the consolidation of reports throughout all the State agencies". This vision is the umbrella under which all State purchases will be governed.

A key information technology objective of The Office of the Connecticut State Comptroller (OSC) is to implement the best possible technological and communication enterprise infrastructure to support the efficient and accurate performance of the OSC's critical business functions. This infrastructure should be implemented as economically as possible while remaining in strict accordance with the applicable legislation of the State of Connecticut.

It is the further purpose of the OSC information technology function to use applicable standards to make interoperability as free of encumbrance as practicable while being mindful of the legal and operational needs for informational privacy.

The Retirement and Benefit Services Division (RBSD) of OSC, requires a turnkey document imaging system that is capable of storing legally and operationally required documents for both active and retired state employees. The vendor of the existing system used to make and store documents on updateable microfiche will not continue to provide film and supplies or maintain the existing duplicating equipment after December 1998.

The vendor must also propose equipment to convert the existing microfiche data archives to the image storage media. The conversion of the existing microfiche must be performed in-house because there is no backup for the current microfiche and removal of original fiche for conversion is non-viable for legal, cost and supply considerations. Currently, only copies of the source microfiche are allowed to leave the confines of the microfiche area. Making copies of all source microfiche is not feasible. Prospective vendors are encouraged to propose conversion schemes that they have implemented successfully.

1.2 Background

1.2.1 Overview of Current Process

The Duplicating Unit in the Retirement and Benefit Services Division is staffed by three full time employees. The Duplicating Unit receives documents and correspondence from the other various operating units of the Division for scanning to updateable microfiche. Batches of documents are sorted in alphabetic order by employee last name. For each document or group of documents, the files of microfiche are checked to see if a microfiche record with earlier documents exist. If a fiche already exists, it is pulled from the files for updating with the new documents. If no prior fiche record exists, a new blank fiche is prepared with a typed employee name label affixed to it.

The sorted documents to be scanned, with the old or new blank fiche clipped to them, are taken to the microfiche scanner in the unit. The fiche is loaded to the scanner and updated with the new documents by scanning one document at a time to the next available blank location selected on the fiche by the scanner operator. The operator's name is also scanned with each document for quality control purposes. Updated microfiche is then returned to the fiche file drawers and the scanned documents are boxed for offsite storage.

Currently, there are about eight to ten million images on approximately 200,000 fiche. Each fiche can contain up to 98 images. Most employees average about 40 to 50 document images. Employees with more than 98 images have multiple fiches filed together in the storage drawers. Each week, approximately 7500 new documents are scanned. Of these documents, about 500 new fiche need to be started each week for employees with no fiche on record.

Division staff ( approx. 100 people ) may view and/or print scanned documents during their daily work of processing retirement applications, purchase applications, finalizing retirement audits and for a variety of other business purposes. When a Division employee wishes to view a fiche record, they fill out a request slip for which record is desired. A Duplicating Unit staff member pulls the desired fiche ( filed by employee name ) and makes a fiche copy of the original microfiche. This is required as no original microfiche record is allowed out of the Unit. The copy fiche is given to the requestor who either views the records on one of the 16 microfiche readers distributed throughout the Division or prints a copy of the fiche ( or selected images on the fiche ) on one of the three fiche image printers available in the Division. Approximately 100 to 150 fiche are copied each day for Division staff usage.

Current counts of microfiche images processed per week: approximately 7500.

Processing daily cycle - 1500 documents per day - minimum of 150 documents per hour per scanning.

 

1.2.2 Office of the Comptroller Technical Infrastructure

The chosen document imaging system will support the retention of input documents processed in the OSC's Retirement Database and Retirement Payroll Systems. The Retirement Database System is an IMS hierarchical database structure that resides on an IBM 3090/MVS mainframe with a CICS user interface. Access to the IMS Database at the state data center is accomplished via a high speed NETEX-T1 connection. Database downloads and information extracts are possible via FTP.

The OSC LAN is 16Mb token ring topology. Category 5 UTP connects each workstation to departmental wiring hubs (Madge SmartCAU or Olicom OC-3610 CAUs). The departmental hubs connect via fiber to the central server room hub (Cabletron MMAC). The agency file servers currently run NetWare 4.11, with version 5 in testing. The Retirement Division also maintains a server running Windows NT version 4.

Workstations are generally either AST P/100 systems with 40MB memory and 15" monitors or Gateway P/350 systems with 64MBs and 17" monitors. All workstations run Windows 95. Major desktop applications are email (GroupWise 5.2), Office 97, internet access (Netscape 4.0) and mainframe access. Printing is accomplished using networked printers from the HP LaserJet 4 family.

 

1.3 Desired System

The State is seeking comprehensive proposals for a Retirement document Imaging package that address all requirements described in this RFP with particular attention to the mandatory requirements as specified in section 1.4 Mandatory Requirements and 1.5 Technical Requirements. Proposals must include the project plans for implementation that encompass data conversion, training and documentation.

The Retirement Division requires the capability of scanning documents of varying size and rapid retrieval of documents from optical storage in a readable form. The Division requires that image retrieval can be accomplished in two ways. Retrieval of images from the storage medium selected should be via dedicated image retrieval stations attached to a standalone network directly attached to the imaging storage device ( for printing and high volume requests) and at Division employee desktops via the OSC LAN ( low volume requests ).

The Division desires to logically tie the imaging index algorithm to the existing Retirement Database mainframe information system so that data on the imaging system is stored under the same unique identifier utilized for data storage on the employee database, and so the indexing and document locating scheme is as similar as possible to the current locating schema as used on the current retirement contribution accounting database. Additionally there should be a record type location scheme within the employee lookup scheme that would allow documents to stored and retrieved by document type.

The microfiche conversion is an important aspect of the project and of the proposed solution. Approximately eight to ten million microfiche images on up to 200,000 updateable ABDICK System 200 microfiche must be converted by Duplicating Unit staff. The Division plans to convert each old microfiche for an employee as a new document comes in for scanning. Fiche to scanned image equipment should be capable of imaging multiple/variable documents from a fiche without having to manually scan each separate document contained on an individual microfiche. As noted, vendors are invited to propose alternate approaches.

The general characteristics of the desired System include:

1.4 Mandatory Requirements

This section will outline the major requirements that the successful proposals must address.
The vendor must submit a comprehensive proposal for an off-the-shelf/vanilla Retirement Document Imaging package that addresses the business functions, installation, implementation, interfaces with other systems, training, documentation and support.

1.4.1 Scanning/Input Workstation Requirements:

  1. The desired Imaging system must have two scanning workstations for input - at least one of these stations must accommodate different paper sizes (3" x 5" up to max of 8.5" x 14" and different paper weights)
  2. At least one scanner must be duplex capable with document feed error detection.
  3. The system Image quality must have minimum image resolution of 300 DPI, and be reviewed at 1280 X 1024 resolution on large format screen. A 19" screen size is the minimum.
  4. The document management system must include a microfiche conversion scanner to enable conversion directly from current fiche to digital imaging in a 18 month to 24 month time frame with legible quality image resolution.
  5. The vendor must supply a supplementary historical fiche conversion system driven by batch loaded key identifier data that will come from the current Retirement Contribution Accounting System.
  6. Vendors must have demonstrable experience in converting microfiche to digital images in conjunction with the implementation of document imaging systems. Vendors are asked to describe their experiences and propose alternate conversion approaches, if appropriate.
  7. The System must enhance the image resolution for low quality images currently on microfiche that are of low or less than legible quality resolution, and be capable of the same enhancements on the incoming paper documents.

1.4.2 Indexing Requirements:

  1. The system must be capable of storing and retrieving documents under a unique identifier with a minimum of three lookup indices ( i.e. Lookup/indexing/retrieval through utilization of either an employee social security number, last name, or a combination of name, and date of birth or employee number secondary index ). The goal is to have the Document Imaging System identifier system operate similarly to the existing Retirement Database and any interoperability (the ability to cross-reference lookups on the existing Retirement Contribution Accounting Database without having to re-key the information would be advantageous).
  2. The index identifiers and secondary indices must be capable of being batch loaded from an extract of a mainframe identifier database.
  3. The document management system must have capability for "batch processing" up to several hundred documents with one identifier (i.e. Scan up to three hundred images for one employee and index them all to one unique identifier en masse ). The capability for "batch processing" is especially important to the microfiche conversion.

1.4.3 Retrieval Requirements:

  1. Retrieval time to screen on the first document must be no more than six seconds. The system must allow a user to retrieve the first document and print in less than fifteen seconds.
  2. At least two dedicated retrieval stations are required with minimum 24-Page Per Minute printer at each station with the capability for adding additional retrieval stations.
  3. Any specialized hardware or software required for retrieval through the OSC LAN must be separately identified and separately priced by the vendor.
  4. The Ideal solutions must use a secured "publish to web (or intranet)" using standard Internet browsers.
  5. The estimated daily volumes are approximately 100 retrieval requests per day (average total of 4000 images, half of the requests for image retrieval may subsequently be printed out).
  6. The system must not allow updates to the original document image, however it should allow for annotation or for additional documents to be added under a single set of identifiers.

1.4.4 Server Architecture and Database Storage Component Requirements:

  1. The State requires that the relational database software used by the system to be industry standard, and generally accepted for usage in the document management field.
  2. The system must exist on its own application server utilizing Windows NT operating system.
  3. The storage architecture for this application must be of standard, general storage media with ISO recognized formatting, and available from more than one vendor. The document management system must use different storage media from different vendors, (magneto-optical jukeboxes or raid arrays or fiber-channel storage or read/write-DVD tower arrays, or some combination).
  4. Storage volume required is based on the conversion of existing fiche images ( 10 million images ) and five years of estimated daily volumes of 1500 documents per day (8.5 x 11 inch source).
  5. The desired system must provide for the sequential backup of new scanned images on a monthly basis.

1.4.5 Security Considerations:

  1. System Security based on user login ID and individual password. There must also be a method for logging which user put documents into the system (each document will be tagged with the ID of the Document Management User). Ideal EIM system security would support the Open Software Foundation's Distributed Computing Environment (DCE) and use this capability to manage users, passwords, and groups more easily, and authenticate users more securely.
  2. Once a document has been stored in an image format it can not be changed, modified or deleted, but new or subsequent documents or notes need to be appended to the original document, with the id of the operator adding it. Ideal solutions should encompass the capability to answer requests from "trusted clients" that come from an operating system with inherent companionable system security and the proper permissions.

1.5. Technical Requirements

1.5.1 Imaging Technical Infrastructure

  1. Prospective vendors for this system will demonstrate how they comply with the Federal Information Processing Standard (FIPS) MS44 for the ongoing quality control within an electronic image management (EIM) system from input to output. (ANSI/AIIM MS60-1996)
  2. Prospective vendors for this EIM system will demonstrate how they comply with the ANSI/AIIM MS61-1998 Industry Standard API(Application Programming Interface) for Scanners in Document Imaging Systems facilitating device independent software and document image scanners.
  3. Prospective vendors for this EIM system should follow as closely as possible ANSI/AIIM TR35-1995 (Human and Organizational Issues for Successful EIM System Implementation) (human and ergonomic factors for EIM systems).
  4. Prospective vendors for this EIM systemwill demonstrate how they comply with ANSI/AIIM MS60-1996. The standard is for Electronic Folder Interchange Data stream and covers how to transit objects, attributes, and hierarchical relationships between Electronic Image Management (EIM) Systems.
  5. Prospective vendors on this system must adhere to the use of industry standard SQL as the query language and for database table definition and manipulation .
  6. Prospective vendors on this EIM system must use an industry standard Relational Database Management System that supports the use of object relational data types for management of data such as MS SQL Server or IBM DB2 or Oracle. The relational database must support online transaction processing (OLTP), and online analytical processing (OLAP). Ideal database structures should have the capability for user-defined table functions, wherein non-relational data can be built into a tabular format that can be queried and captured into relational tables. Usage of personal "desktop" database products such as MS Access is not acceptable except for non-critical reporting purposes.
  7. The selected vendor must make use of a non-proprietary interface following the general model of the Windows95/Windows98/WindowsNT GUI interface as closely as possible.
  8. Prospective vendors must propose a design for an EIM System that will allow for data structures in Visual Basic, JAVA HTML 3.2 ASP pages and would allow input by Electronic Data Interchange or Electronic Forms (for example Jet Forms)
  9. The prospective turnkey standalone document management system must be capable of operation independently of the current OSC LAN, and maintain interoperability with the current LAN for low volume requesting.
  10. The selected vendor must use a uniform set of data definitions for all component applications; The data definitions must   be maintained in the RDBMS data dictionary facility and permit custom modifications at OSC, by OSC personnel.
  11. Prospective vendor on this EIM system must make use of SSL or VPN security mechanisms for internet or web based   solutions for secure data submittal.
  12. In proposing an overall IT solution (including architecture, application software and implementation, the proposer must   adhere to State of Connecticut policies and guidelines on:
    software management and licensing http://www.state.ct.us/otc/softmpm/smpmtitl.htm
    web application user interface and accessibility http://www.opm.state.ct.us/policies.htm
  13. Proposed architectures that use messaging / store and forward technologies should use IBM's MQ Series product (or a compatible product).
  14. The physical architecture proposed by the bidder should support location independence of application, Internet and database servers; however it should be clearly understood that such equipment is to be under the exclusive control of the operational and technological staff of Office of the State Comptroller and that the equipment will reside within the physical and business confines and environs of the Office of the State Comptroller, and as such should be as compatible with the equipment, services and knowledge of the OSC staff as possible.

1.5.2 Technical Requirements and Questions

  1. The vendor must provide an IT architecture description (both narrative and pictorial) that supplies the following:
    1. Physical layout of application processing, database processing, network/communications and internet/web implementation (if any); this description will include bandwidth and traffic requirements.
    2. Description of how the proposed architecture, and its implementation, supports adherence to State information technology policies and the OSC's technical infrastructure.
  2. Independent of image compression for storage purposes, do you use any other compression techniques/algorithms when transmitting images over a network?
    1. If the images are to be retrieved by networked workstations, or printed on networked printers, what networking topology do you recommend as optimal for this purpose?
    2. Is the currently installed 16Mb token ring LAN adequate for this purpose, based on the retrieval rates described for low volume requests?
  3. Please list the email systems that your software interfaces with.
  4. What is the estimated shelf life of the storage media that you propose?

1.6 Evaluation

A State evaluation team will be established to review vendor responses to this RFP. The submittal of proposals shall constitute, without any further act required of the vendors or the State, acceptance of the requirements, administrative stipulations and all of the terms and conditions of the RFP.

Proposals will be evaluated by, but not limited to, the following criteria:

 

  1. Understanding of the RFP and the Vendors ability to provide a Retirement Document Imaging Management System as specified. The total points accumulated during technical merit and evaluation stage of the RFP shall be used as a measure of this priority;
  2. The Vendor's plan for implementing the entire System. This evaluation will include, but not be limited to, the Vendor's plan for the integration and supervision of all subcontractors and suppliers as well as the existing equipment;
  3. The Vendor's ability to perform the contractual services as reflected by technical training and education, general experience, and specific experience in providing the required Retirement Document Management system; and the qualifications and abilities of the personnel proposed to be assigned to perform the design, implementation, and management of the System.
  4. A record of favorable past performance of similar work in regard to design, size, scope and implementation of Document Management Systems, including overall quality, performance and project schedule.

Within these areas the State will consider (where appropriate) the following:

  1. Functionality
  2. Target architecture
  3. Support
  4. Data conversion
  5. Ease of transition
  6. Time to implement
  7. Turnkey Operation
  8. Price of the solution

1.7 Implementation

As a result of the evaluation process, if the proposal of a given vendor is found to be most advantageous, the State shall select that vendor's proposal for implementation.

2.ADMINISTRATIVE REQUIREMENTS

2.1 Vendor Instructions

2.1.1 Conformity to Instructions

Vendors must conform with all RFP instructions and conditions when responding to this RFP. The State, at its discretion, may reject any nonconforming proposal .

2.1.2 Proposal Responses to this RFP

Vendors desiring to participate in this RFP process must submit proposals with the format and content as outlined in Attachment 2. All proposal text must be specifically cross-referenced to the RFP Section and/or Attachment numbers to which a given part of the proposal applies.

2.1.3 Vendors Not Submitting Proposals

Vendors that are provided with a copy of this RFP and that choose not to offer a proposal to the State are asked to submit a negative reply to verify their receipt and consideration of the RFP.

2.1.4 Identifying RFP Communications

All proposals and other communications with the State regarding this RFP must be submitted in writing in sealed envelopes or cartons clearly identifying:

  1. The appropriate RFP reference key (i.e., RFP 989-A-23-7052-C);
  2. The applicable proposal due date and time;
  3. The name and address of the originating vendor; and
  4. An indication of the envelope contents (e.g., "PROPOSAL," "NEGATIVE RESPONSE," "QUESTIONS," OR "BENCHMARK").

Any material received that does not so indicate its RFP related contents will be opened as general mail, which may not ensure the vendor's intent.

2.1.5 Vendor Questions and State Replies

This office will attempt to reply to any written vendor questions which it receives no later than within five (5) business days of receipt. DOIT does not guarantee a response to questions received less than five days before the due date.

At the discretion of the State, copies of pertinent questions and related replies will be distributed to all vendors originally issued a copy of the RFP. The State may, in its sole discretion, orally communicate responses to vendors if it is likely that written responses will not reach them prior to the proposal due date. The oral communication will be followed by a written confirmation, clarification, or correction. However, oral communications notwithstanding, the State shall be bound only by the written document which follows.

2.1.6 Acceptance of Administrative Requirements

Vendor proposals must include unequivocal statements accepting the administrative requirements of this RFP, and must reflect compliance with such requirements. Any failure to do so may result in the State's rejection of the proposal.

2.1.7 Deviating from RFP Specifications

The State will reject any proposal that deviates significantly from the specifications of this RFP. Vendors submitting proposals with any minor deviations must identify and fully justify such deviations for State consideration.

2.1.8 Exclusion of Taxes from Prices

The State of Connecticut is exempt from the payment of excise and sales taxes imposed by the Federal Government and/or the State. Vendors remain liable, however, for any other applicable taxes.

2.1.9 Vendor Contact(s)

The proposal must provide the name, title, address, and telephone number of the contact person(s) responsible for clarifying proposal content and for approving any agreement with the State.

2.1.10 Proposal Copies

Any vendor responding to this RFP must submit an original and seven copies of the proposal. Pages should be numbered by section. Include one (1) complete set of all applicable standards manuals (Procedure Manuals, Media Preparation Guides, etc.).

2.1.11 Validation of Proposal Offerings

The proposals shall be binding commitments which the State may include, by reference or otherwise, into any agreement with a vendor. Therefore, each proposal copy must be validated by signature of a person having such authority to commit the vendor. The signer's authority in this regard must be authenticated by a signed statement to that effect by an appropriate higher-level company official. A Vendor Proposal Validation and Authentication Statement, attached to this RFP as Attachment 4, must be used for this purpose.

2.1.12 Proposal Completeness

To be acceptable, proposals must contain all required information and statements in the form requested by this RFP. Vendor proposals must submit "none" or "not applicable" responses to any RFP question and information request, when such a response is the only appropriate response.

2.1.13 Restrictions on Contacts with State Personnel

From the date of release of this RFP until a contract is awarded as a result of this RFP, all contacts with personnel employed by or under contract to the State of Connecticut are restricted. During the same period, no prospective vendor shall approach personnel employed by or under contract to State or any other State agency participating in the evaluation of proposals, or any other related matters. An exception to the foregoing will be made for vendors who, in the normal course of work under a valid contract with other State agencies, need to discuss legitimate business matters concerning the relationship of their work.

Violation of these conditions may be considered sufficient cause by the State to reject a vendor's proposal, irrespective of any consideration.

2.2 Other Conditions

2.2.1 Amendment or Cancellation of RFP

The State reserves the right to amend or cancel this RFP at any time if it deems it to be in the best interest of the State to do so .

2.2.2 Proposal Modifications

No additions or changes to any vendor's proposal will be allowed after the proposal due date, unless such modification is specifically requested by the State.

2.2.3 Control of RFP Events and Timing

Timing and sequence of events resulting from this RFP will be determined by the State.

2.2.4 Proposal Expenses

The State of Connecticut assumes no liability for payment of any costs or expenses incurred by any vendor in responding to this RFP.

2.2.5 Acceptance or Rejection of Proposals

The State reserves the right to accept or reject any or all proposals submitted for consideration in whole or in part; and to waive minor technical defects, irregularities, or omissions, if, in its judgment, the best interest of the State will be served.

2.2.6 Ownership of Proposals

All proposals shall become the sole property of the State.

2.2.7 Oral Agreement or Arrangements

Any alleged oral agreements or arrangements made by vendors with any State agency or employee will be disregarded in any State proposal evaluation or associated award.

2.2.8 Bonding Requirements.

No Bonding Requirements for this RFP.

2.2.9 Vendor Presentation of Supporting Evidence/Surety

Vendors must be prepared to provide any evidence of experience, performance ability, and/or financial surety that the State deems to be necessary or appropriate to fully establish the performance capabilities represented in their proposals.

2.2.10 Vendor Demonstration of Proposed Products

Vendors must be able to confirm their ability to provide all proposed services. Any required confirmation must be provided at a site approved by the State and without cost to the State.

2.2.11 Vendor Misrepresentation or Default

The State will reject the proposal of any vendor and void any award resulting from this RFP to a vendor who materially misrepresents any product or defaults on any State contract.

2.2.12 State Fiscal and Product Performance Requirements

Any product acquisition resulting from this RFP must be contingent upon contractual provisions for cancellation of such acquisition, without penalty, if the applicable funds are not available for required payment of product costs or if the product fails to meet minimum State criteria for acceptance and performance reliability.

2.2.13 Conformance of Awards with State Statutes

Any award resulting from this RFP must be in full conformance with State of Connecticut statutory, regulatory and procedural requirements.

2.2.14 Erroneous Awards

The State reserves the right to correct inaccurate awards, including canceling an award and contract, resulting from its clerical errors.

2.2.15 Registration with Connecticut Secretary of State

Contract Awards are contingent upon the vendor's obtaining:

  1. Certificate of Authority, Certificate of Legal Existence or Certificate of Good Standing, as applicable, from the Connecticut Secretary of the State's Office, prior to the execution of the contract ;
  2. A tax clearance statement from the Department of Revenue Services within sixty (60) days of the execution of the contract and
  3. A statement from the Department of Labor regarding employee contributions within sixty (60) days of the execution of the contract.

2.2.16 Joint Ventures

Proposals requesting joint ventures between vendors will not be accepted. The State will only enter into a contract with a prime vendor who will be required to assume full responsibility for the delivery/installation of equipment, wiring, software and related services identified in this RFP whether or not the equipment, products and/or services are manufactured, produced or provided by the prime vendor. The prime vendor may enter into written subcontract(s) for performance of certain of its functions under the contract only with written approval from the State prior to the effective date of any subcontract. The prime vendor shall be wholly responsible for the entire performance of the contract whether or not subcontractors are used.

2.2.17 Freedom of Information.

Due regard will be given for the protection of proprietary information contained in all proposals received; however, vendors should be aware that all materials associated with the procurement are subject to the terms of the Freedom of Information Act (FOIA) and all rules, regulations and interpretations resulting therefrom. It will not be sufficient for vendors to merely state generally that the proposal is proprietary in nature and not therefore subject to release to third parties. Those particular sentences, paragraphs, pages or sections which a vendor believes to be exempt from disclosure under the FOIA must be specifically identified as such. Convincing explanation and rationale sufficient to justify each exemption consistent with the FOIA Section 1-19 of the Connecticut General Statutes, must accompany the proposal. The rationale and explanation must be stated in terms of the prospective harm to the competitive position of the vendor that would result if the identified material were to be released and the reasons why the materials are legally exempt from release pursuant to the above cited statute.

ALL SUCH MATERIAL SHOULD BE SUBMITTED IN A SEPARATE SEALED ENVELOPE AND MARKED "CONFIDENTIAL".

2.2.18 Security Clearance.

A vendor receiving an award from this RFP must understand that all employees including sub-contractor personnel shall be subject to DAS' security procedures.

2.2.19 Project Leader/Staff.

In submitting a proposal, the vendor must submit the names and credentials of the individual(s) being named as Project Leader and all staff to be assigned to the project. The vendor must further represent and warrant that all staff to be so assigned will not be removed from the project without the express written consent of DOIT. Such consent will not be unreasonably withheld.

2.2.20 Workers' Compensation.

A vendor receiving an award from this RFP must carry sufficient workers' compensation and liability insurance in a company, or companies, licensed to do business in Connecticut, and furnish certificates as may be required by DOIT.

2.2.21 System Non-Acceptance.

Failure of the System to be accepted by the State as proposed by the vendor may result in the State's calling the Payment and Performance Bond furnished by the vendor.

2.2.22 Warranty

  1. The vendor shall represent and warrant in the proposal that the System shall conform to the RFP requirements, vendor's written specifications and that it shall be free from defects in materials and workmanship for a minimum period of two (2) years after acceptance of the System.
  2. Vendor shall represent and warrant that the System proposed shall function according to published manufacturer specifications on the acceptance date for such System, and that the vendor shall modify, adjust, repair and/or replace said System as the State deems it to be necessary or appropriate to have it perform in full accordance with the terms and conditions of the RFP.

2.2.23 Ownership of System

The vendor, upon acceptance of the System by the State, shall relinquish all interest, title, ownership, and proprietary rights (collectively, "Title") in and to the System and transfer said Title to the State. The State will hold ownership of all Software Licenses required for the System.

2.2.24 Implementation

As a result of the evaluation process, the State shall select the vendor whose proposal the State deems to be the most advantageous to the State.

2.2.25 Independent Price Determination

In the proposals, vendors must warrant, represent, and certify that in connection with this RFP the following requirements have been met:

  1. The costs proposed have been arrived at independently, without consultation, communication, or agreement for the purpose of restricting competition as to any matter relating to such process with any other organization or with any competitor.
  2. Unless otherwise required by law, the costs quoted have not been knowingly disclosed by the vendor on a prior basis directly or indirectly to any other organization or to any competitor.
  3. No attempt has been made or will be made by the vendor to induce any other person or firm to submit or not to submit a proposal for the purpose of restricting competition.

 

2.2.26 Offer of Gratuities.

The vendor warrants, represents, and certifies that no elected or appointed official or employee of the State of Connecticut has or will benefit financially or materially from this procurement. Any contract and/or award arising from this RFP may be terminated by the State if it is determined that gratuities of any kind were either offered to or received by any of the aforementioned officials or employees from the vendor, the vendors agent(s), representative(s) or employee(s).

2.2.27 Readiness of Offered Products.

All System products (hardware, operating system, etc.) offered to the State in the proposal must be currently manufactured and available for general sales, lease, or licenses on the date the proposal is submitted.

2.2.28 Inspection of Work Performed.

During and after the installation of the products and System, the State, and its authorized representatives, shall be allowed access to inspect all Vendor materials, documents, work papers, equipment or products, deliverables, or any such other items which pertain to the scope of work for this RFP and contract. This requirement also applies to any subcontractors who may be engaged by the vendor.

2.2.29 Year 2000 Compliance.

The System provided in response to this RFP shall be Year 2000 (Y2K) compliant.
The contractor warrants that each hardware, software, and firmware product ("product") or each developed, modified or remediated item of hardware, software, firmware ("item") or each service delivered under this contract shall be able to:

 

  1. accurately assess, present or process date/time data (including, but not limited to, management , manipulation, processing, comparing, sequencing and other use of date data, including single and multi-century formulae and leap years) from, into , and between the twentieth and twenty-first centuries, and the years 1999 and 2000 and leap year calculations;
  2. properly exchange date/time data when used in combination with other information technology;
  3. perform as a system, if so stipulated in the contract, and the warranty shall apply to those items as a system.

Notwithstanding any provision to the contrary in any vendor warranty or warranties, the remedies
available to the State under this Year 2000 warranty shall include repair or replacement of any listed product and/or item whose non-compliance with the Year 2000 warranty is discovered and made known to the contractor in writing. This warranty remains in effect through December 31, 2000 or 365 days following the termination of this agreement, whichever is later.

Nothing in this warranty shall be construed to limit any rights or remedies the State may otherwise have under this contract with respect to defects other than Year 2000 compliance.

In addition, the contractor warrants that products or items modified or remediated to achieve Year 2000 compliance will remain unaffected with respect to their functioning or performance except for processing and exchanging date/time data. The contractor warrants that products or items not being modified or remediated directly will remain unaffected with respect to their normal functioning or performance.

3. TYPICAL ACTIVITIES CONDUCTED AFTER RFP ISSUANCE

3.1 Vendor communication

3.1.1 Vendors' Questions

The State intends to answer questions from any vendor that is considering a response to this RFP. Questions received by the Contracts and Purchasing Division (CPD) up to four days before the due date will be answered. The State reserves the to right to respond to any questions within five days of receipt. Address your inquires to Dennis McKinley. Only written inquiries will be accepted via Fax (860) 566-2648, e-mail: dennis.mckinley@po.state.ct.us or the US postal system, (Department of Information Technology, Division of Contracts and Purchasing, Attention Dennis Mckinley, 340 Capital Avenue, Room 254, Hartford, CT. 06106.

3.2 Coordinate and Review RFP Responses

The State will open only those proposals received by the date and time specified in Section 4.2. Proposals received after the due date will be returned unopened. Immediately upon opening, the State will review each proposal for vendor compliance with the instructions and conditions applicable to this RFP. The State, at its option, may seek vendor retraction and clarification of any discrepancy/contradiction found during its review of proposals. The State will evaluate only proposals complying with the administrative requirements of this RFP.

3.3 Evaluate Proposals

3.3.1 Evaluation Team

A State evaluation team will be established to evaluate vendor proposals.

3.3.2 Evaluation Process

The State will evaluate requested proposal information (including that which is appended, attached, and/or enclosed) against all RFP requirements, using criteria and methodology pre-established in coordination with the planned users of a given service.

Vendors are requested to respond to all requirements in this document by properly cross referencing the Attachment and appropriate Section Number.

In this document requirements that are stated as mandatory use the words "must" and "will". The State evaluation team will review all documents for compliance to the stated mandatory requirements.

3.4 Establish and Conduct Applicable Vendor Benchmarks

The State will determine the nature and scope of any benchmarking that it may deem to be necessary or appropriate to the evaluation of vendor System proposals.

3.4.1 Benchmarking Purpose and Scope

The State uses benchmarks to demonstrate and validate a vendor's proposal, to satisfy given operating requirements, and to ascertain the adequacy and timeliness of vendor responses to user requirements.

The State may employ two benchmark phases: (1) vendor conducted and documented tests which are not monitored by the State, and (2) actual demonstrations to the State of the vendor's ability to perform as required.

3.4.2 Unmonitored Vendor-Documented Benchmarks

State benchmarks often require vendors to conduct and document, within set time frames, the actual operation of their proposed service and the operation of sample functional sequences using State supplied information.

3.4.3 Live Demonstration of Benchmarks to State

The State usually requires vendors to conduct benchmark demonstrations at a mutually agreed upon site and at no cost to the State. Such demonstrations may be conducted at the site where the vendor conducted the unmonitored tests described above, or at a more convenient operating site which meets minimum State demonstration requirements. Should the demonstration, inspection or benchmark site be beyond the regional area of Hartford, Connecticut then your company will be responsible for necessary travel, meals and lodging arrangements and expenses for a team of up to seven (7) State employees.

3.5 Implement Necessary Agreements

The offered agreement (Attachment 5: Information Processing Systems Master Software License Agreement) shall be the agreement pertaining to this issued RFP. In that the State offered agreement is viewed as being most reasonable to the vendor, the State will not accept any request by the vendor to modify a specific provision unless there are compelling reasons for doing so, and that without the provision being modified the vendor will not consider contract approval. In any such case, you should state the rationale for the specific provision's unacceptability (define the deficiency); provide recommended verbiage (consistent with verbiage used throughout the agreement) for the State's consideration; and state how such recommended verbiage corrects the claimed deficiency and maintains fairness to both parties. IT IS NOT ACCEPTABLE to simply replace a State provision with a vendor's "preferred" provision.

If for some reason the Contracts and Purchasing Division (CPD) cannot reach consensus with the vendor within an reasonable time, CPD shall offer the agreement to the next best proposal and so on until either the agreement is executed or the State decides to start the RFP process again.

3.6 Notification of Awards

The State will notify vendors who submit proposals as to any award issued by the State as a result of this RFP.

4. PROPOSAL REQUIREMENTS

4.1 Proposals

The following Attachments to this RFP provide vendors with the specific guidance required to correctly respond to this RFP.

Take special care to ascertain that any proposal response fully complies with all of the response requirements specified in these attachments.

Attachment 1 - Applicable Definitions

Attachment 2 - Vendor Proposal Format and Content Requirements

Attachment 3 - Proposed System Product Cost Worksheets

Attachment 4 - Vendor Proposal Validation and Authentication Statement

Attachment 5 - Information Processing Systems Agreement

Attachment 6 - Strategic Plan For Information Technology

4.2 Proposal Submission

Vendor proposals in response to this RFP 989-A-23-7052-C MUST be received at:

Department of Information Technology
Division of Contracts and Purchasing
340 Capitol Avenue, Room 254
Hartford, CT 06106

no later than 10:30 a.m. (EST) on April 8, 1999 in order to be considered. Postmark dates will not be considered as the basis for meeting any submission deadline. Therefore, any vendor proposal received after the deadline will not be accepted. If delivery of proposals is not made by courier or in person, the use of certified or registered mail is suggested.
All RFP communications should be addressed to the RFP issuer as shown on the title page of this document.

Proposals will not be publicly opened on the due date. On the date and time proposals are due the Department of Information Technology will announce only that the vendor has submitted either a proposal or no proposal.

Back to Table of Contents
Back to Comptroller's Home Page