REQUEST FOR PROPOSAL

for

VERMONT JUDICIARY CONSOLIDATED COURTS MANAGEMENT SYSTEM (“VCase”)

Important Date Summary (Note RFP Section 2.1 for Full Schedule):

DATE POSTED / June 12, 2008
QUESTIONS DUE , INTENT TO BID / June 27, 2008
BIDDER’S CONFERENCE / July 9, 2008 (9 – 4, Burlington, VT)
PROPOSALS DUE / August 27, 2008, 2pm.

LOCATION OF BID OPENING: 2418 Airport Rd, Suite 4, Barre, VT 05641

PLEASE BE ADVISED THAT ALL NOTIFICATIONS, RELEASES AND AMENDMENTS ASSOCIATED WITH THIS RFP WILL BE POSTED AT THE VERMONT BUSINESS-TO-BUSINESS WEBSITE: http://www.vermontbidsystem.com/Default.aspx

IT WILL BE THE RESPONSIBILITY OF EACH VENDOR TO PERIODICALLY CHECK THE BID WEB SITE FOR THE LATEST DETAILS AND UPDATES.

RFP CONTACT: Rick Conklin, VCase Project Manager

TELEPHONE: (802) 828-3364

E-MAIL:

IMPORTANT NOTE

THIS COMPLETE RFP IS COMPOSED OF SEVEN (7) FILES

1. RFP Document: Vermont-VCaseRFP-RFP.zip / Vermont Judiciary VCase RFP in a Word 2003 .doc editable file (zipped; click Save, then unzip)
2. Attachment File #1A: Vermont-VCaseRFP-Attachment1A.zip / Attachments 1 – 10 (Word 2003 .doc editable file zipped; click Save, then unzip)
3. Attachment File #1B: Vermont-VCaseRFP-Attachment1B.zip / Attachments 11 – 14 (Word 2003 .doc editable file zipped; click Save, then unzip
4,5,6. Attachment Files #2A/B/C: Vermont-VCaseRFP-Attachment15A, B, C.zip / Attachment 15, VTADS Screen Summary Presentation (PowerPoint .ppt files zipped; click Save, then unzip)
7. Attachment File #3: Vermont-VCaseRFP-Attachment16.pdf / Attachment 16, Courts Activity Reports (.pdf file.)
State of Vermont Judiciary / Page 2 of 135 / RFP for new Case Management System

Table of Contents

1. Overview 6

1.1. Purpose of this RFP 6

1.2. Project Background 6

1.3. Overview of the State of Vermont Judiciary 8

1.4. Introduction to the Current Technology in the Courts 9

1.5. Common Terminology Used in this RFP 10

1.6. The VCase Project Vision 12

1.7. Proposal Management Summary Requirement 13

1.8. Major Project Functions, Timeframes, and Milestones 15

1.9. The Focus of Each RFP Chapter 18

2. Project Information and General Guidelines 21

2.1. RFP and Contracting Schedule 21

2.2. Single Point of Contact for this RFP 22

2.3. Question-Answer Period and Intent to Bid Notification 22

2.4. Bidders Conference and Finalist Presentations 22

2.5. Limitations 23

2.6. Additional Submissions 23

2.7. Independence Certification 23

2.8. Laws and Regulations 23

2.9. Customary Contract Provisions 24

2.10. Method of Award 24

2.10.1. Contract Award 24

2.10.2. Rejection of Proposals 25

2.10.3. Proposal Evaluation Criteria 25

2.10.4. The Contract Negotiation Process 26

2.11. Noting Exceptions to Requirements Listed in this RFP 26

2.12. Subcontractors 27

2.13. Ownership of Work Product and Intellectual Capital 27

2.14. Delivery 28

2.15. Quality of Hardware and Software 28

2.16. Environmentally Preferable Purchasing 28

2.16.1. Mercury Content 29

2.16.2. Take Back Provisions 29

2.16.3. Energy Efficiency 29

3. Project Management 30

3.1. Project Management Overview 30

3.2. Project Planning 31

3.2.1. Alignment with an Industry Standard Project Methodology 31

3.2.2. Risk Management, Organizational Change, and Communications 32

3.2.3. Alignment with Industry CMS and Systems Standards 32

3.2.4. Master Project Plan 34

3.2.5. Pre-Contract Trial Period (“90-Try”) 35

3.3. Prior Project Experiences 36

3.4. Staffing 36

3.4.1. “Key” Staff 36

3.4.2. Project Manager 36

3.4.3. Business Analysts 37

3.4.4. Technical Staff 37

3.4.5. Trainers 37

3.4.6. Judiciary project staff requirements 37

3.5. Checklist for Responding to this Chapter 38

4. Core CMS/DMS Requirements 41

4.1. Introduction 41

4.2. Why don’t we have an Extensive Requirements Checklist? 42

4.3. Capabilities of Your Proposed CMS/DMS 43

4.3.1. Usability 43

4.3.2. User permissions 44

4.3.3. Reports 44

4.3.4. Restricted Information 45

4.3.5. Events 46

4.3.6. Business Rules and Workflow Rules 47

4.3.7. Merge Documents 47

4.3.8. Electronic Document Management 48

4.4. Checklist for Responding to this Chapter 49

5. E-Filing 50

5.1. Introduction 50

5.2. Judiciary Expectations for the E-Filing Solution 50

5.3. General Capabilities of Your E-Filing Solution 52

5.4. Detailed Requirements for the Baseline E-Filing Initiatives 54

5.4.1. Superior Court – Mortgage Foreclosure Cases 54

5.4.2. Family Court – Juvenile, Children in Need of Care and Supervision (CHINS) and Termination of Parental Rights (TPR) Cases. 56

5.4.3. District Court – All Criminal Cases in Two Pilot Courts 56

5.4.4. Superior and Family Court – Filings by Pro Se Users in Specified Proceedings. 57

5.5. Checklist for Responding to this Chapter 61

6. Initial System Configuration and Construction. 62

6.1. Introduction 62

6.2. What do we mean by Initial System Configuration and Construction? 62

6.3. Your Approach to Initial System Design and Configuration 63

6.4. Initial Configuration Objectives 64

6.5. Parameters for Configuration 65

6.6. Sequencing the Configuration and Construction Activities 65

6.7. Checklist for Responding to this Chapter 67

7. Production System Rollout and Training 69

7.1. Introduction 69

7.2. What do we mean by Production System Rollout and Training? 69

7.2.1. List of the 19 Databases 70

7.2.2. Court Statistics by Database 70

7.2.3. Overview of 19 Database Rollout Strategy 71

7.3. Required Rollout Activities and Questions 73

7.4. Checklist for Responding to this Chapter 75

8. Interfaces 76

8.1. Introduction 76

8.2. Description of the Current Data Exchange Files 76

8.2.1. Current Interfaces 76

8.2.2. Definitions 77

8.2.3. Baseline Interface Description 77

8.3. Proposed Interface Solution 82

8.3.1. Architecture and Standards 82

8.3.2. Interface Support 82

8.3.3. Flexibility 83

8.3.4. Justice Integration 84

8.3.5. Interface Options 84

8.4. Approach to Implementing Exchanges 84

8.4.1. Approach 84

8.4.2. Interface Project Plan 85

8.5. Checklist for Responding to this Chapter 86

9. Conversion 87

9.1. Introduction 87

9.2. Judiciary Expectations for Conversion 87

9.2.1. What is a “minimalist” conversion approach? 87

9.2.2. What is the Judiciary View of the Conversion Process? 88

9.2.3. Does the Judiciary have experience converting VTADS data? 91

9.2.4. How many “conversions” might be necessary? 91

9.2.5. How will vendors learn more about the VTADS database structure? 93

9.3. Checklist for Responding to this Chapter 93

10. Architecture and Support 95

10.1. Introduction 95

10.2. Current Technical Architecture 95

10.2.1. IT Infrastructure 95

10.2.2. Case Management Software & Citrix 98

10.2.3. Research and Information Services Resources 99

10.2.4. Judiciary Information Technology Overview 100

10.3. Proposed Technical Architecture 100

10.3.1. Architecture 100

10.3.2. Performance 103

10.3.3. Disaster Recovery 103

10.3.4. Storage 104

10.3.5. Archiving 105

10.3.6. Security 105

10.3.7. Software as a Service 105

10.3.8. Module Integration 106

10.3.9. Technical Documentation 106

10.3.10. Public Access 107

10.3.11. Training and Maintenance 107

10.3.12. Reports 107

10.4. Proposed Technical Approach 108

10.5. VCase Architecture Plan Requirements 109

10.6. VCase Hardware and Software List 110

10.7. Checklist for Responding to this Chapter 111

11. Post Implementation Support 113

11.1. Introduction 113

11.2. Approach to Post Implementation Support 113

11.3. Checklist for Responding to this Chapter 114

12. Costs 115

12.1. Introduction 115

12.2. Cost Spreadsheet Assumptions Grids 116

12.3. Cost Spreadsheet Grids 117

12.4. Checklist for Responding to this Chapter 120

13. Project Phase 2 - E-Filing and Probate 122

13.1. Introduction 122

13.2. Phase 2 E-Filing Description 122

13.3. Phase 2 Probate Court Description 122

13.4. Checklist for Responding to this Chapter 123

14. Vendor Response Content and Format 124

14.1. Proposal Content 124

14.2. Required Format of the Proposal 124

14.3. Summary of Background and Experience Form 128

15. Proposal Submission Instructions 130

15.1. Closing Date 131

15.2. Sealed Bid Instructions 131

15.3. Delivery Methods 132

16. Description of Attachments 133

1.  Overview

1.1.  Purpose of this RFP

The State of Vermont Judiciary seeks proposals from qualified vendors to supply, configure, implement, and support a new, consolidated case management, document management, and electronic filing solution for all courts in the Vermont Judiciary. This new courts management system is referred to in this RFP as “VCase”. The Judiciary seeks proposals from a prime contractor, who with optional subcontractor(s), will provide a technically current, standards-based, flexible, user-friendly package-based solution that best supports the Judiciary’s requirements listed in this RFP. Successful responses to this RFP will propose a team that will lead this project through all phases of the definition and implementation lifecycle, including project leadership tasks, software and hardware installation assistance, detailed requirements and gap analysis, system definition and system administration configuration, approved package modifications, conversion and interfaces assistance, testing support, functional and technical training and documentation, state-wide system production rollout and post-implementation support.

The optimal prime contractor will be provide, at a minimum, the software and support of a market-leading, thin-client courts case management system. The prime contractor, and optimally all subcontractors, must propose staff and references that clearly demonstrate that the proposed team has strong credentials to successfully configure, implement, and support a state-wide, multi-court case management, document management, and e-filing system rollout.

1.2.  Project Background

TheState of Vermont Judiciary’s current case management systems are all based on the original text-based Vermont Automated Docketing System (VTADS). VTADS was built originally by Relational Semantics, and has been maintained and enhanced bythe Judiciary’s Research & Information Services Division (RIS)since 1990. VTADS worked well but its decentralized configuration does not allow for viewing data on a statewide basis and does not easily provide court statistics, management reports or meet data requests from other state agencies.

In 2000/2001, the Judiciary implemented a data warehouse to combine data specifically from the District, Family and Superior Courts to support statistic generation and data access and sharing among the courts and state agencies. The system was built on Business Objects WebIntelligence and Oracle 8i. A web-based application called Vermont Case Access System (VCAS) allows end-users to search for court case information on a statewide basis. But while the data warehouse has provided improved functionality in some areas, the underlying case management system continues to limit the ability of the Judiciary to move ahead with the flexibility inherent with today’s technologies.

In 2004/2005, the Judiciary contracted with the National Center for State Courts (NCSC) to perform a review of the current state of the case management system, and deliver a requirements analysis and a feasibility assessment. Those documents were used as a basis for publishing a Request for Information (RFI) in 2005. The RFI was used to gauge the state of the market and potential success of replacing VTADS.

Using the information gathered from the responses to the RFI and several other sources (e.g., CTC-10, calls to other states to learn about their CMS projects, informal discussions with several members of the CMS vendor community, consulting with the NCSC), the Judiciary has embarked on the process of not just replacing VTADS, but implementation of a state-of-the-art courts management system, we call a “CMS framework”, to include case management, document management, and e-filing.

In 2006, a full-time project manager was brought onboard to manage this critical project. In addition, NCSC was hired to review the previous work, update the information and complete an RFP for a new court case management system.

An RFP was issued in January, 2007, but it was withdrawn in June, 2007 due to a number of factors, including:

·  There were several other RFPs issued in the same timeframe which stretched the CMS vendor community’s ability to submit multiple simultaneous quality bids;

·  We required a flexible web-based package and several leading vendors were not yet ready to release their new products;

·  There was the perception that we did not have enough money to launch a project with the scope we defined; and,

·  The scope needed clearer definition to help reduce risk and costs.

In the last year we feel that we have learned a great deal about what it takes to set in place a solid project foundation with a governance structure that will lead to project successes for all parties. We intend that this current RFP, while requiring a similar scope to the last one, will facilitate more focused and less risky bids in a number of areas, including:

·  Instead of expecting a COTS “CMS package” pre-coded to meet 90% of our requirements list on day one, we have redefined “package” in this RFP to mean courts-oriented “framework”, with a high emphasis on power-user level system administration configuration capabilities so that our combined business analyst teams can mold the new system to meet our requirements via system administration tables (and not require programmers to modify hard-coded logic and screens, both now and in the future).

·  Instead of asking for “interfaces to everyone”, we have narrowed the scope to about 20 files that our old system produces and we have provided the specifications for those files, and we will evaluate your system’s flexibility to create more NIEM-compliant exchanges in the future;

·  Instead of asking for “conversion of all our old data”, we ask for your proposal for a minimalist conversion that strives to convert only what we need to use your system effectively on Day 1 and going forward, and we will evaluate your approach and tools that will help us leverage the conversion effort;

·  Instead of supplying a list of hundreds of reports from our old system, we ask for your estimate to provide “x” number of reports;

·  Instead of asking you to train all 500 of our users, we agree to be integral to a train-the-trainer approach;

·  Instead of providing some limited court information and asking for your proposal to provide a rollout strategy, we provide more detailed information on each court and the parameters for effective rollout that we have learned from our calls to many other states and lessons learned from those projects; and,

·  Instead of relying strictly on general fund project funding, we instituted (starting last July) a “fee-based technology revolving fund” which provides us with an ongoing base of funding. In addition, we are actively pursuing other grant funding opportunities.

Two important areas have not changed since our last RFP:

·  The Vermont Executive Branch Enterprise Project Management Office strongly recommends that projects follow the TenStep project management methodology. We require you to propose with this methodology in mind except in cases where you have an alternative methodology for us to consider; and,

·  We are a heavily CITRIX based shop. Over 80% of our court users do not have PCs on their desks; they have winterms. We serve up their entire desktop (including the Microsoft Office suite) via CITRIX Presentation Server from our central CITRIX farm location in Montpelier. With few exceptions (e.g., perhaps scanning applications) we require that your software runs without issues via CITRIX.