VCase RFP
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:
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: RICK.CONKLIN@STATE.VT.US
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: |Attachment 15, VTADS Screen Summary Presentation (PowerPoint .ppt files zipped; click |
|Vermont-VCaseRFP-Attachment15A, B, C.zip |Save, then unzip) |
|7. Attachment File #3: Vermont-VCaseRFP-Attachment16.pdf |Attachment 16, Courts Activity Reports (.pdf file.) |
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
Overview
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.
2 Project Background
The State 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 by the 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.
3 Overview of the State of Vermont Judiciary
The Vermont Judiciary is composed of seven courts: Supreme, Superior, District, Family, Judicial Bureau, Environmental and Probate. A description for each court can also be found at the Judiciary’s website .
The State of Vermont Judiciary, referenced in this document as the Judiciary, is organized as follows:
Vermont has one appellate court, the Supreme Court, which has one clerk’s office.
The Judicial Bureau and Environmental Court each have 1 clerk’s office. The District Court, Family Court, and Superior Court each have 14 clerk’s offices, which are located in Vermont’s 14 counties. The Probate Court has 18 clerk’s offices.
Vermont has 31 courthouses. Each courthouse contains at least 1 clerk’s office, but may include as many as 4 clerk’s offices (district court, family court, probate court, and superior court).
Vermont has approximately 90 judicial officers: 1 chief justice, 4 associate justices, 15 superior court judges, 17 district court judges, 2 environmental court judges, 6 family magistrates, 2 judicial bureau hearing officers, 18 probate judges, and 28 assistant judges. Many of these judicial officers work in multiple courts and multiple counties.
Vermont has 53 court managers: Each court manager is responsible for at least 1 clerk’s office, but may be responsible for as many as 4 clerk’s offices co-located within a courthouse (district court, family court, probate court, and superior court). For the purposes of this RFP, court managers include “court managers”, “superior court clerks”, and “probate court registers”. The state court administrator’s office has direct supervision of the court managers for the district court, environmental court, family court, judicial bureau, and supreme court. Elected assistant judges supervise the superior court clerks. Elected probate judges supervise the probate court registers.
Vermont has approximately 250 court staff members working in various courts. Court staff members tend to have duties parallel to their respective court manager (e.g. if the court manager is responsible for both the district court and the family court clerk’s office in Addison County, then the court manager’s staff members are cross-trained to work in both district court and family court).
Vermont has a centralized court administrator’s office with approximately 35 administrative staff members. This includes the Court Improvement and Innovation Division (formerly the Training Division), Trial Court Operations division, the Administrative Services division (which includes the finance department), and the Research and Information Services (RIS) division which is responsible for all LAN/WAN/Helpdesk/Web and programming services for the Judiciary.
4 Introduction to the Current Technology in the Courts
As stated above, our current case management system is called VTADS. The system is about 18 years old and is character based (function key driven). It was developed with the ACCELL 4GL development tool and utilizes Unify Dataserver ELS v6.5 as the database engine. Since ACCELL is basically a language that generates C code, many parts of the system are also coded in C. While originally bought by the court as a CMS “software package”, the court has owned the rights to the source code for many years and maintains the system with a staff of three in-house programmers.
VTADS began as a system to support criminal dockets. Over time it was expanded, copied and sometimes modified to handle all docket types used in the Judiciary today. The VTADS structure in the courts is as follows:
• Vermont has 14 counties. Each county has its own copy of the VTADS “database”, which is a copy of the VTADS programs and data which support operations for all courts in one county. It is important to note that throughout this RFP we often use the term “database” to mean the VTADS software and database that supports a county or a standalone court (e.g., the Supreme court has one “VTADS database”). “Database” is further explained later in this chapter, and Chapter 7, Production System Rollout and Training, provides more detailed information on this definition of “database”. There are three basic court types in each county: a District (criminal) court, a Family court (which includes the juvenile docket), and a Superior (civil) court. Therefore, each of these three courts in a county share one “copy” of VTADS, e.g., one central entity (“person”) table per county. As we move to a centralized VCase, we will have to combine these separate entity tables, plus resolve differences in code/reference tables, which have the same structure, but may have some slightly different values (even across the same court types). Chapter 9, Conversion, has more information on conversion considerations. Other notes are as follow:
o While the 14 District and Family courts use VTADS, only 12 of the Superior courts use it. Two Superior courts (Chittenden and Franklin) have their own CMS systems and conversion of those systems is not part of the scope of this RFP.
o There are 18 Probate courts, so some counties have two Probate courts. However, the Probate courts do not use VTADS. In fact, they have no formal case management system. All of their work is done via WordPerfect macros, spreadsheets, etc. Five of the 18 Probate courts use CITRIX environments; others currently have their own PCs and servers. Note: Probate courts will be converted into the new VCase system in “Phase 2” of the project; “Phase 2” is defined later in this chapter and in RFP Chapter 13.
o While each county has a database, each copy of the database is not physically in each county. Rather, the system is served to the users via a central CITRIX farm based in Montpelier, and therefore all VTADS servers are in Montpelier.
• There is one appellate court, the Supreme Court. It has its own server, and uses an old version of VTADS (VTADS1). This version runs on an old version of Informix and is unique to the Supreme Court. (Note: As discussed later in this document, there are instances where appeals can go to other courts depending on the type of case.)
• There is one Environmental Court. It has a modified version of VTADS2 that is specific to this court. The Environmental Court has a centralized staff but holds hearings throughout the state.
• There is one statewide traffic court, called the Judicial Bureau. Like the Environmental Court, the Judicial Bureau has a centralized staff but holds hearings throughout the state. The Judicial Bureau has a modified version of VTADS2 for processing traffic tickets (Vermont Civil Violation Complaints) and a few other document types. In addition, the Municipal Ordinance system is also housed at the Judicial Bureau, another modified version of VTADS2. Note:
o The Judicial Bureau is the only court in the state that has scanning. Since Vermont has no e-citation program, paper tickets come to the Judicial Bureau from the police. Paper tickets are scanned into a standalone imaging system from1Mage Software, Inc. The ticket images are stored separately from the VTADS database. However, custom routines link the ticket image to the corresponding case record in VTADS, so that the user can press F1 from a VTADS screen and pull up the corresponding image. Data from the ticket image is manually entered into the case record in VTADS.
5 Common Terminology Used in this RFP
Throughout this document, the following definitions apply:
Case-record means data and documents stored within the system and associated with a particular case.
Case-type means a classification of cases according to legal subject matter (e.g. divorce, small claims, and criminal are three distinct case-types).
Claim means a civil cause of action, criminal charge, or other allegation that constitutes the legal basis for initiating a case.
Configure means to define system settings by clicking checkboxes, entering values in textboxes, and adding, deleting, or editing records in tables. Configuring the system also may include stand-alone logic statements containing Boolean operators. Configuring the CMS is distinguished from programming, which requires a software developer to write programming code to produce the desired functionality.
Court means a group of case-types (e.g. the Family Court may include divorce, juvenile and mental health case-types).
Docket sheet means a compilation of events and other entries about a particular case. Vermont’s term “docket sheet” may be similar to a “register of actions” in other states.
Document-type means a classification of documents according to the purpose of the documents (e.g. initial pleading, responsive pleading, motion).
Electronic files means Microsoft Office files, PDF files, TIFF files, email messages, audio and video files, and files in other electronic formats.
Participant means a party or other person assigned a role in a case (e.g. parties, attorneys, guardians ad litem, case workers, and interpreters may be participants).
System means a vendor’s complete information technology solution proposed for the VCase project.
User means a person with an account to access the system. All accounts are user accounts, regardless of the permissions associated with the accounts.
Vendor means the entity proposing a solution in response to this Request for Proposals.
Venue means the office where cases are processed (e.g. a county or district).
VT means the Vermont Judiciary.
6 The VCase Project Vision
The Vermont Judiciary has a long term vision to transform the case managing process from a paper-driven business model to an electronic-focused business model that leverages the power of the latest technologies. The Judiciary is looking for a case management solution that is web based, contains flexible workflow, business rules definition, and security features, and is tightly integrated with electronic filing and document management capabilities. Integration with digital audio and video systems must be possible in the future. Required is an n-tier thin-client deployment that achieves the Vermont Courts’ goals of reducing complexity for users and administrators, expanding access to the Courts, and improving the reliability of results. The Vermont Courts anticipate offerings of Web-based solutions that integrate with users and outside systems using modern technologies such as XML/NIEM, Microsoft Exchange for email and calendar integration, Microsoft Share Point, a non-proprietary programming language and database management system, and flexible report writing features.
The Judiciary’s vision is a full-lifecycle project to implement VCase in all jurisdictions statewide. The major business drivers for this project are:
• Access To Justice – A high priority for the Judiciary is to improve access to the courts by citizens through improving our web capabilities. This includes a combination of electronic filing, electronic forms, and document management functionality to implement the electronic interchange of information between the courts and external stakeholders (e.g., certain members of the Bar, pro-se litigants) to the maximum extent possible. A goal for this RFP is to install the infrastructure and support the move toward paperless case files throughout the Judiciary.
• Improve inter-agency communication – The Judiciary, the State of Vermont, and the Federal government all share the goal of improving the timeliness and effectiveness of inter-agency communication through the increased use of standards. Data “exchanges” between the new courts system and other agencies will be based on the NIEM standard. Since the current system cannot generate NIEM-standard XML interfaces, the new VCase system will provide a much more robust and flexible platform to send and receive information in the common, standard format.
• Replace the current, aging case management system – The Judiciary is at risk for failure of its main record keeping and source of information by continuing with its current case management system that is more than 18 years old. The proposed solution must allow the Judiciary to completely turn off all versions of its current case management (and related) systems – without losing any of the current VTADS functionality that users require. Merely by installing a single, modern system we expect to improve the usability of the Judiciary systems in virtually every major functional area.
7 Proposal Management Summary Requirement
Your proposal must follow the “tab layout” specified in Chapter 14 of this RFP. Your Management Summary must provide a concise (less than 10 pages preferred) overview of your proposed solution. Your Summary must include the following table:
|Question |Brief Response |See Also (further info in |
| | |proposal) |
|1. Overall, do you believe VCase is a low, | | |
|medium, or high risk project? Why? | | |
|2. Do you feel that you can accomplish all | | |
|required tasks listed in this RFP in 36 months?| | |
|3. What do you feel are the three greatest | | |
|risks for this project? | | |
|4. Is your thin-client system a “ground up” | | |
|rewrite from your thick client system? | | |
|5. How confident are you that your system will | | |
|run without problem under CITRIX? | | |
|6. Has the proposed team worked and/or | | |
|developed in a CITRIX environment before? If | | |
|so, where? | | |
|7. What is the minimal and optimal number of | | |
|full-time Judiciary staff members (with job | | |
|category) that you think are required to make | | |
|this project a success from contract signing | | |
|through “Completion of 19 database rollout” as | | |
|defined in Chapter 7? | | |
|8. What team experience stands out to indicate | | |
|to us that your proposed team (not just | | |
|company) has the breadth and depth for a | | |
|state-wide, multi-court implementation? | | |
|9. Does your application have any limitations | | |
|on the type, number or combination of court | | |
|types, docket types, court locations, and/or | | |
|user security role combinations that are | | |
|definable by the Judiciary system | | |
|administration team via standard system table | | |
|maintenance screens? | | |
|10. If Vermont were to be the first purchaser | | |
|of your thin-client application, what are the | | |
|main steps you will take to mitigate the risk | | |
|of us being “first”? What is the cost savings| | |
|if we are “first”? | | |
|11. In your experience, name a project where | | |
|the experience did NOT end in success, and | | |
|briefly describe what you will do differently | | |
|on this project. | | |
|12. To control the project, we will need a | | |
|repository for project artifacts (deliverables,| | |
|bug tracking, scheduling, etc) and metrics. Do| | |
|you propose to set up facilities on our Share | | |
|Point 2007 site to do this? If not, what tools| | |
|do you propose? | | |
|13. Does your CMS product have integrated | | |
|document management? | | |
|14. Does your CMS product have integrated | | |
|e-filing functionality? | | |
|15. Does your CMS product comply with the NCSC| | |
|National CMS Functional Standards? If not, | | |
|what are the three most significant areas where| | |
|your CMS does not support capabilities listed | | |
|by the NCSC standard? | | |
8 Major Project Functions, Timeframes, and Milestones
As the Judiciary’s team has proceeded to consider the expected tasks and deliverables necessary to accomplish the requirements of this RFP, the team has come to divide the project into high-level divisions along two lines:
• Major Project Functions: We have divided the major functions or components of the project into these areas (you might think of these as potential “teams”):
o CMS/DMS (this includes the design/development of forms and reports and training);
o E-Filing;
o Interfaces and Conversion; and,
o Architecture and Support (includes technical infrastructure, dba work, help desk support, etc).
• Major Project Timeframes: The significant timeframes are:
o Evaluation: Proposal evaluations and selection of a winning vendor, timeframe until contract signing. Included in the Evaluation timeframe will be the “90-Try” onsite trial (further defined in Chapter 3, Project Management);
o Configure: configuration of the system, including all tasks between contract signing and being ready to “go live” in the first court. (Note: later in this document we explain that each county has several courts on one “VTADS database”, therefore, we expect to go live by converting all courts that use a single “database”, not “by court”);
o Rollout: Implementation of the system state wide, and
o Phase 2: post-Rollout activities, including post-implementation support and continuation of e-filing and probate court rollout.
The chart at the end of this section, “RFP Layout Map”, provides a graphical summary of the above, with Functions defining the rows and Timeframes forming the columns. The contents of the resulting cells contain bar-chart style lines showing the Judiciary’s assumptions of what major activities will take place on the project, by Function, over Time.
In addition to Functions and Timeline, the top of the Map also indicates four major Milestone points in the project.
• Major Project Milestone Dates: The major project milestone dates are:
o July 1, 2009 Contract: According to the expected schedule as outlined in Chapter 2, the Judiciary expects a contract to be signed and work to begin on July 1, 2009.
o TBD – Ready for First Database Rollout: As explained in Chapter 7, Production System Rollout and Training, the Judiciary expects that VCase migration into the courts will take place one VTADS “database” at a time. Completing all initial tasks, and therefore being ready to start “rollout” into the first courts (i.e., the “first database”), is an important milestone. Of course, we will look to your proposal (e.g., your project plan in response to Chapter 3) for your estimate when you propose to begin production rollout.
o June 30, 2012 – Complete 19 Database Rollout: Also as explained in Chapter 7, the Judiciary expects that the rollout of VCase will happen by VTADS “database”, and there are 19 VTADS databases. The completion of tasks proposed in response to Chapter 7 will meet a key goal of the VCase project vision – to be able to turn off production VTADS processing within three years of contract signing.
o June 30, 2014 – Complete E-Filing and Probate: Another goal of the Judiciary is to implement “paperless courts” throughout the Judiciary and to complete the migration of the Probate courts into VCase. This is called “VCase Phase 2” and is explained further in Chapter 13, Phase 2 E-Filing and Probate. The completion of VCase Phase 2 within five years of contract signing is a key foundation of the VCase project vision.
In summary, the RFP Layout Map provides a very high-level bar-chart project plan of the Judiciary’s expectations for the progress of the VCase project. As you will note, the bars in the cells each represent one Chapter in this document, and your proposal will be similarly organized with equivalent “Tab” numbered chapters as specified in Chapter 14 of this RFP. While this format provides you with an idea of how we expect the project to flow, it is also intended to be at a high enough level to leave you room to propose a solution that you feel will best meet the goals of this RFP.
The next section provides a summary the remaining chapters in this RFP.
RFP Layout Map
[pic]
9 The Focus of Each RFP Chapter
The remaining chapters in this RFP are of two types, Administrative and Project Specific. The Administrative chapters are:
• Chapter 2 – Project Information and Guidelines: provides the overall RFP schedule and sections that describe further topics in bidding and contracting process;
• Chapter 14 – Vendor Response Content and Format: provides the structure you must follow to properly assemble your response. You are required to follow the “Tab” structure as detailed in Chapter 14.
• Chapter 15 – Proposal Submission Instructions: provides proposal submission instructions.
• Chapter 16 – Description of Attachments: provides a high-level description of the Attachments.
The Project Specific chapters are outlined below, and are represented on the RFP Layout Map at the end of this chapter:
• Chapter 3 – Project Management: The purpose of this chapter is to present our expectations for project management tasks that will encompass the entire project. In response to this chapter you will present your project management methodology, staffing, and baseline, high-level “master” project plan for the project (not including the “Phase 2” timeframe).
• Chapter 4 – Core CMS/DMS Requirements: The purpose of this chapter is for us to explain what type of system we want, and for you to respond to our questions and checklist about the features you propose. This chapter is unique is that there are no “costs” associated with this chapter – it’s sole focus is to help us decide which vendor’s system has the highest probability of supporting the Judiciary’s operational needs.
• Chapter 5 – E-Filing: We have made a conscious effort to avoid breaking the project into “phases” or “tracks” or other types of partitions that do not have a pneumonic title (i.e., “Evaluation”, “Configuration”, etc.) It is important to note that the overall goal of the VCase project is to support Judiciary-wide e-filing in all dockets within five years of contract signing. However, in order to help focus the scope of this RFP for purposes of proposing a fixed-price bid, the e-filing requirements have been divided into baseline and “Phase 2” requirements. The baseline e-filing requirements are detailed in Chapter 5 and are to be bid as part of the baseline fixed costs. There are four major e-filing initiatives required for baseline e-filing and the requirements for each are explained in Chapter 5. In response to Chapter 5 you will provide your methodology, proposed staffing, timeline, and assumptions for the activities to gather requirements, configure, test, prepare training, and so forth, for the four e-filing initiatives. The production implementation of e-filing is included in Chapter 7, Production System Rollout and Training.
• Chapter 6 – Initial System Configuration and Construction: This chapter’s focus is the set of activities necessary to prepare the CMS/DMS software for production rollout into the courts. In response to this chapter you will provide your methodology, proposed staffing, timeline, and assumptions for activities such as gathering functional requirements, preparing a “gap” analysis, configuring the system via the system administration functions, making any required programming modifications to your system, preparing training materials, and so forth.
• Chapter 7 – Production System Rollout and Training: The focus of Chapter 7 begins once the CMS/DMS and the e-filing initiatives, as described in Chapters 5 and 6, have completed User Acceptance Testing and are ready to be “rolled out” into production. We use the term “rollout” to mean all the activities necessary to put VCase into production, including: final data cleaning and conversion, turning on the new interfaces, implementing the new CMS/DMS and e-filing functionality, training the user staff, helping support the court as they begin to use the new system. As is described in Chapter 7, the Judiciary expects the VCase rollout to be based on replacing each of the 19 VTADS databases. Your response to this chapter will provide your proposed methodology, staffing, timeline, and assumptions – by database – to rollout VCase and enable the Judiciary to stop production processing in all versions of VTADS within three years of contract signing.
• Chapter 8 – Interfaces: Interfaces (also known as “exchanges”) are those automated files that exchange information between VCase and other agency/department systems. The emphasis of Chapter 8 is on acquiring a flexible interface subsystem that will facilitate replacing the interface files that exist in VTADS, and building new interfaces/exchanges, that may either be published or consumed via industry standard XML (e.g., NIEM, Legal ECF) or flat-files, at our option. Your response to this chapter will provide your proposed methodology, staffing, timeline, and assumptions for providing the interface subsystem framework, designing/coding/testing the replacement of VTADS interfaces, and your approach for creating new interfaces/exchanges that are not yet defined.
• Chapter 9 – Conversion: The Judiciary will accept a minimalist approach to conversion, foregoing the “we want to convert everything” approach for a more moderate “let’s convert just what we need” approach. Our conversion analysis team will work with your conversion team to research and document the courts’ data conversion requirements, map VTADS elements to your database requirements, and help with the design, construction, and testing of utilities and processes for data cleaning and conversion. Your response to this chapter will provide your proposed methodology, staffing, timeline, and assumptions for VTADS to VCase data cleaning and conversion.
• Chapter 10 – Architecture and Support: The focus of Chapter 10 is to outline the Judiciary’s VCase architecture requirements, and provide you with an overview of the current technical infrastructure including hardware, software, telecommunications, help desk, and staffing. Chapter 10 asks you to respond to a series of questions that will help us understand your proposed architecture and support offerings. Your response to this chapter will provide your proposed hardware and software requirements, telecommunications requirements and capabilities, technical staffing and support offerings, infrastructure setup timelines, and other architecture and support related capabilities and assumptions.
• Chapter 11 – Post Implementation Support: The purpose of this chapter is to allow you to provide us with your proposed long term options in areas such as long term software support, help desk capabilities, user group and training opportunities, and so forth.
• Chapter 12 – Costs: It is standard State purchasing practice to ask vendors to separate their “technical” proposal from their “cost” proposal. Your response to Chapter 12, Costs, will be separate from your response to the rest of this RFP. Chapter 12 provides a spreadsheet format where you will provide your fixed price and optional rates that correspond to the various levels of effort you have proposed in response to the other chapters of this RFP.
• Chapter 13 – Project Phase 2 E-Filing and Probate: Chapter 13 provides an overview of what the Judiciary will require in “Phase 2” of VCase. Phase 2 E-Filing requirements are those remaining documents/data needs necessary to support paperless courts state-wide after the 19 database rollout described in Chapter 7 is completed. Because the Probate Courts do not use VTADS and the decommissioning of VTADS is a key objective of this RFP, the rollout of VCase to the Probate Courts will be scheduled to begin after the completion of the 19 database rollout discussed in Chapter 7. Therefore, Chapter 13 allows you to provide an expected approach to the methodology, staffing, and timeframe you believe will be required to complete Phase 2. Note: Phase 2 E-Filing requirements and conversion of Probate Court are presented in Chapter 13 (represented by the dotted line on the RFP Layout Map) but will not be included in the fixed price bid you propose in Chapter 12, Costs
Project Information and General Guidelines
1 RFP and Contracting Schedule
The table below presents the Judiciary’s expected schedule for this RFP and contracting process. Please note that the Judiciary may change this schedule at any point. Changes will be posted to the website listed on the cover of this RFP.
|RFP Published |June 12, 2008 |
|Initial Vendor Questions on RFP document due |June 27, 2008 |
|Intent To Bid Notification due via email (Strongly recommended, puts |June 27, 2008 |
|you on our email notification list for things like Bidder’s Conference| |
|agenda changes, etc.) | |
|Judiciary replies to Initial Vendor Questions |At the Bidder’s Conference on July 9, then will post an updated set of|
| |answers/RFP updates by July 31, 2008 |
|Bidder’s Conference (Strongly recommended, but not required to bid.) |July 9, 2008 (Champlain Room, Costello Courthouse, Burlington, VT, 9am|
| |– 4pm) |
|Proposal Due (see Chapters 14 and 15 for detailed instructions on |Wednesday, August 27, 2pm |
|Proposal Format and submission instructions) | |
|Notification letters sent to Finalists chosen for Vendor Presentations|Friday, September 26, 2008 |
|Vendor Presentation timeframe |October 6 – 24, 2008 (approximately) |
|Potential Judiciary site visit(s) |Early November |
|Best-And-Final Changes due to the Judiciary (Optional: based on final |November 21, 2008 |
|questions and demonstrations) | |
|Winning Firm Selection Notification |December 5, 2008 |
|“90-Try” period |Jan – March, 2009 |
|State Independent Review of Project |Feb – April, 2009 |
|Contract Negotiation Period |Feb – June, 2009 |
|Contract Signed |June 30, 2009 (approximate) |
|Estimated Start work date |July 1, 2009 (FY 2010) |
|Estimated Completion of 19 Database Rollout |36 months from the date of contract |
|Estimated Completion of VCase Phase 2 |60 months from the date of contract |
2 Single Point of Contact for this RFP
All communications concerning this RFP are to be addressed in writing to the attention of the RFP Contact listed on page 1 of this RFP. The RFP Contact is the sole contact for this RFP. Attempts by bidders to contact any other party could result in the rejection of their proposal.
3 Question-Answer Period and Intent to Bid Notification
Any vendor requiring clarification of any section of this proposal or wishing to comment or take exception to any requirements or other portion of the RFP must submit specific questions in writing according to the Schedule listed in Section 2.1. Questions must be e-mailed to the RFP Contact listed on the cover page of this proposal during the applicable time period. Any objection to this RFP or to any provision of this RFP that are not raised in writing on or before the last day of the initial question period is waived. Additional clarification may be discussed at the Bidder’s Conference.
You are strongly encouraged to email a short “Intent to Bid” notification to the Contact listed on the cover of this RFP. An Intent to Bid email is not required to submit a proposal, nor is it promise to respond to this RFP. However, an Intent to Bid notification puts you on our distribution list for last minute notifications (change of venue for meetings, etc). Be sure to include your name, phone, and email address in your Intent to Bid email. Note that the Judiciary will attempt to notify those on the distribution when major updates are posted to the project website, however, notifications are not guaranteed and it is your responsibility to continually monitor the bid website for updates during the bid process.
Please also indicate the number of people you believe will attend the Bidder’s Conference in you Intent to Bid email.
4 Bidders Conference and Finalist Presentations
As part of this RFP process, the Judiciary strongly encourages you to send a representative to the VCase Project Bidder’s Conference. This session will be in two parts: a 2 – 3 hour morning session and a 2 – 3 hour afternoon session. The morning session agenda includes topics such as: Introduction of the project’s Management Team, a review of the RFP, the RFP process, the VCase project and answers to the Vendor Questions. The afternoon session will be an informal online demonstration and Q/A on our current system, VTADS. An agenda and directions will be sent to those vendors that register by the date specified in Section 2.3 above, and directions will be posted to the bid website.
This Bidders Conference is currently expected to be scheduled as per the RFP schedule above. This meeting is scheduled to be held in the Champlain Room, Costello Courthouse, Burlington, VT. There will be no cost to the Judiciary for attending this meeting. There will be no meeting notes posted and calling in will not be allowed.
As part of the evaluation of proposals, the Judiciary will require a set of Finalist vendors to make a presentation based on their solution. These on-site presentations will be in a Montpelier, VT area facility arranged by the Judiciary. Finalist Presentations are expected to be 2 - 3 days in length, including vendor demonstrations of the solution (with and without a script), technical staff review of the architecture of the system, and management level discussions about the proposed solution and potential areas of contract negotiations. Further details of the Presentations will be distributed and discussed at the Bidder’s Conference. There will be no cost to the Judiciary for these Finalist presentations. The expected presentation period is stated in the schedule above. Your proposal must include any special requirements you may have for your presentation should you be selected for the Finalist list.
5 Limitations
The Judiciary assumes no responsibility or liability for costs incurred by a vendor prior to issuance of a contract (except for costs in the “90-Try” period as explained later in this RFP). In addition, this RFP does not commit the Judiciary to award a contract, procure any materials or supplies or pay any costs incurred in the preparation of a vendor’s proposal.
All vendor proposals become public record and are available for public review and inspection upon execution of the contract. The Judiciary will not intentionally publish properly marked proprietary material, although it cannot guarantee that any pages marked “Proprietary and Confidential” will remain private in the event of a dispute. Any contract(s) awarded as a result of this RFP will contain the general guidelines and conditions contained herein and will also incorporate the successful vendor’s proposal.
6 Additional Submissions
The Judiciary may award a contract or contracts based upon the offers received, without additional submissions from the vendor. However, the Judiciary reserves the right to request additional oral or written information or presentations from any vendor in support of their written proposal or questions.
7 Independence Certification
Each vendor must certify that it has no personal, financial, or professional relationship(s) with the Judiciary, its management or employees.
8 Laws and Regulations
The vendor selected will be subject to, and expected to adhere to, all applicable laws and regulations of the United States, the Internal Revenue Service, the State of Vermont, and any state or province in which the vendor operates. This condition is of special significance with respect to confidentiality.
The vendor and all employees working on this contract will treat all information as confidential and will sign a contract with the Judiciary to that effect. The Judiciary reserves the right to inspect the systems and procedures of the vendor to guarantee that the Vendor and its employees are adhering to the confidentiality provisions of the contract.
9 Customary Contract Provisions
The vendor must affirmatively state their understanding of the provisions contained in Attachment 1, State Contracting Addendum, and agree to abide by them should they receive a contract offer from the Judiciary. Furthermore, with regard to the Section 6 of Attachment 1, the company that issues insurance required by this section must be registered with the State’s Department of Banking and Insurance to do business in the State.
10 Method of Award
1 Contract Award
The Judiciary intends to award one contract as a result of this RFP, but reserves the right to make additional awards to the same vendor or other vendors who submitted proposals at any time during the first year of the contract if such award is deemed to be in the best interest of the Judiciary.
The Judiciary intends to issue a 36 month contract, with options to renew the contract for three 12-month periods based on the vendor’s performance without requesting contract proposals from other vendors.
The selected vendor will sign a contract with the Judiciary to provide the items named in their responses and accepted by the Judiciary, at the prices listed. Minimum support levels, as well as terms and conditions and requirements from this RFP and the vendor’s response will become part of the contract. This contract will be subject to review throughout its term. The Judiciary will consider cancellation upon discovery that a vendor is in violation of any portion of the agreement, including an inability by the vendor to provide the products, support and/or service offered in their response.
This project is estimated to start work as defined in the Schedule outlined in Chapter 2.
Subcontractors will be held to the terms and conditions set forth for the prime contractor, and it will be the responsibility of the prime contractor to convey, monitor and enforce those terms and conditions.
Evidence of insurance will be required of the successful vendor prior to contract execution.
2 Rejection of Proposals
The Judiciary reserves the right to reject any or all proposals received as a result of this RFP and/or not proceed with any proposal. The Judiciary may accept part(s) of a proposal. The Judiciary is not obligated to proceed beyond issuing this RFP.
A proposal may be rejected for one or more of the following reasons or for any other reason deemed to be in the best interest of the Judiciary:
▪ Failure of the vendor to adhere to one or more provisions of this RFP.
▪ Failure of the vendor to submit information required by this RFP.
▪ Failure of the vendor to follow generally accepted ethical and professional standards during the RFP process.
3 Proposal Evaluation Criteria
The Judiciary’s proposal review team will evaluate proposals based on the criteria listed below in approximate order of importance. The Judiciary shall be under no obligation to contact vendors for clarification of proposals, but it shall reserve the right to do so at any time prior to contract award. The Judiciary reserves the right to request additional information from any or all vendors during the evaluation process.
Based on the results of the evaluation, the proposals determined to be the most advantageous to the Judiciary may be selected for further action.
|PROPOSAL EVALUATION FACTORS |
|Cost: Baseline fixed price, Programmer and analyst average hourly costs |
|Experience of business analyst team to lead GAP analysis and configuration |
|Answers to Core CMS/DMS Requirements chapter |
|Experience with court rollouts |
|Probability that solution will run under CITRIX without problem |
|References |
|N-tier Architecture |
|Conversion approach methodology (risk) |
|Framework features (workflow, rules engine, date sensitive tables, unlimited court types/docket types/locations/user roles) |
|Interface engine capabilities |
|E-Filing features |
|DMS features |
|Realistic 36 month project plan |
|Quality of Proposal |
|Long term support offerings and capabilities |
4 The Contract Negotiation Process
Upon completion of the evaluation process, the Judiciary may select one bidder with which to negotiate a contract, based on the evaluation findings and other criteria deemed relevant for ensuring that the decision made is in the best interest of the Judiciary. The Judiciary may accept a vendor’s proposal in whole or in part. In the event the Judiciary is successful in negotiating with a bidder, the Judiciary will issue a notice of award. In the event the Judiciary is not successful in negotiating a contract with a selected bidder, the Judiciary reserves the option of negotiating with another bidder.
Once a winning bidder is selected, the first part of the contract negotiation phase will be a “90 day Evaluation-Before-You-Buy” period, called “90-Try” in this RFP. A description of the objectives of the 90-Try period is contained in Chapter 3, Project Management. Your response to Chapter 3 will include your proposed methodology, timeframe, staffing, and assumptions for the 90-Try period. Your costs for participation in the 90-Try period will be a separate line item in Chapter 12, Costs.
Simultaneous to the 90-Try period, the State Enterprise Project Management Office (EPMO) will initiate an “Independent Review” of this project. According to State statute, all IT projects over a certain size are required to go through an Independent Review. The EPMO will independently hire a consultant with an in-depth knowledge of large systems implementations, and if possible, courts management systems specifically. The major purpose of the Independent Review is to assess your proposal, the project plans, the project risks, and the expected ROI of this system. The resulting document, which will be reviewed by the State CIO, the Court Administrator, and the Supreme Court, will provide recommendations to the Judiciary on whether or not the risk of this project is acceptable to move forward, or what risks should be mitigated either through contract terms or other means. Also the consultant will assist the Judiciary with drafting the contract as part of the Independent Review.
Once the 90-Try period, the Independent Review, and the contract are completed, the project can begin. At its sole discretion, the Judiciary reserves the right to terminate this contracting process at any time.
11 Noting Exceptions to Requirements Listed in this RFP
This RFP text, answers to vendor questions, and Best and Final Offer documents, will become part of the contract for this project. Standard State Contracting Provisions are presented in Attachment 1. If you have an objection to, or concern with, any functional, technical, or legal requirement in this RFP (including Attachments), you must consolidate and document all concerns and your suggested changes in Tab 18 of your proposal entitled “Exceptions”.
12 Subcontractors
If you, as the primary contractor, propose to use subcontractors and the Judiciary accepts, subcontractors hired by the primary contractor must adhere to the same standards and contract provisions applicable to the primary contractor (“the vendor”). The vendor retains overall responsibility for contract performance. The vendor’s proposal must clearly explain those responsibilities you may assign to a subcontractor (if any), the name and contact information for the subcontractor, and include references that can speak to the subcontractor’s work doing similar duties to those you propose in your response.
13 Ownership of Work Product and Intellectual Capital
Except for agreed proprietary rights to commercial software and hardware, the Judiciary will have all ownership rights to hardware and software, and modifications thereto, as well as associated documentation. “All data, technical information, materials gathered, originated, developed, prepared, used or obtained in the performance of the contract, including, but not limited to, all reports, surveys, plans, charts, literature, brochures, mailings, recordings (video and/or audio), pictures, drawings, analyses, graphic representations, software computer programs and accompanying documentation and print-outs, notes and memoranda, written procedures and documents, regardless of the state of completion, which are custom developed and/or required under this contract shall be and remain the property of the Judiciary. If not already submitted within the course of project delivery requirements, all referenced project artifacts shall be delivered by the vendor to the Judiciary on or before 30 days request/notice by the Judiciary. With respect to custom software computer programs outside the VCase application software and/or custom source codes developed for the Judiciary, the work shall be considered “work for hire”, i.e., the Judiciary, not the contractor or subcontractor, shall have full and complete ownership of all software computer programs and/or source codes developed.”
All work products and deliverables produced under contracts awarded as a result of this bid will be the exclusive property of the Judiciary. This includes, but is not limited to, custom developed software, documentation, and development materials. A vendor shall not sell a work product or deliverable produced under a contract awarded as a result of this bid without explicit permission from the Judiciary.
The Judiciary requires all source code to be put into escrow. If you object to this provision, please explain in your Exceptions chapter.
The vendor’s RFP must clearly describe the terms of all licensing considerations, such as an End User License Agreement.
14
15 Delivery
If the vendor proposes to order any hardware or software for use on this project: All equipment pricing is to include F.O.B. delivery to the ordering facility. No request for extra delivery cost will be honored. All equipment shall be delivered ready for immediate use, unless otherwise requested by the Judiciary. Liability for product delivery remains with the vendor until delivered and signed for by the Judiciary, in accordance with the Division of Purchasing and Contract Administrations terms and conditions.
We anticipate the evaluation, selection and negotiation phases of this procurement will extend over several months. Given the pace of change in hardware/network specifications and capabilities, we are open to negotiating more current solutions (as of contract signing date). The price of more current solutions should not exceed the original price proposed by Responders. It is probable that the Vermont Judiciary will order commodity solutions through our State contracting vehicles. If responders conclude that they can offer more advantageous pricing, we welcome the offer.
16 Quality of Hardware and Software
If the vendor proposes to order any hardware or software for this project: All products provided under this agreement will be new and unused, unless otherwise stated. Factory seconds or remanufactured products will not be accepted unless specifically requested by the Judiciary. All products provided by the vendor must meet all federal, state and local standards for quality and safety requirements. Products not meeting these standards will be deemed unacceptable and returned to the contractor for credit at no charge to the Judiciary.
17 Environmentally Preferable Purchasing
The State of Vermont is a national leader in the development and application of Environmentally Responsible Purchasing and control of Hazardous Material Use. Environmentally Preferable Purchasing means “products and services that have a lesser or reduced effect on human health and the environment when compared with competing products or services that serve the same purpose. This comparison may consider raw material acquisition, production, manufacturing, packaging, distribution, re-use, operation, maintenance, or disposal of the product or service” (Presidential Executive Order 13101; US EPA; generally accepted by industry).
The State of Vermont has established specific goals and objectives aimed at: providing sound environmental stewardship, protection of human health, reducing state operating expenses associated with the use and control of regulated hazardous materials, and reduction of potential liability attributable to environmental impact. Therefore, the following environmental criteria shall be considered for all state purchasing and contracts:
1 Mercury Content
Mercury Content: The State of Vermont is committed to minimizing the amount of mercury utilized in its operations, and desires to eliminate the purchase of products that contain mercury whenever feasible alternatives exist at a reasonable cost and comparable performance. Where mercury-free alternative products do not exist, preference will be given to the purchase of products with the lowest (documented) total mercury content feasible and products that bear a mercury content warning label as required of product manufacturers under Vermont law, Executive Order #03-02. The State of Vermont urges suppliers to continue to develop, produce, and bring to market appropriate, cost competitive, and effective mercury-free replacements.
2 Take Back Provisions
Take Back Provisions: It may be preferable to have products or equipment returned to the provider at the end of its useful life to provide for environmentally conscientious disposal. If the vendor has a take-back program please provide details that include methodology and any costs associated with it. Detail the program by addressing each of the following: date the program is or will be in operation, type of equipment being taken back or proposed to be taken back, volume of equipment being recycled/disposed or proposed, certificates of disposal, disk storage cleaning, take-back charge by type of equipment, and compliance with federal or other regulatory authorities regarding disposal. The State of Vermont reserves the right to request additional information.
3 Energy Efficiency
Energy Efficiency (Energy Star): State of Vermont Agencies and Departments are directed to reduce greenhouse gas emissions from state government buildings and operations (Executive Order # 14-03). To improve our energy performance and help the environment by reducing our energy use, purchases shall be made only for reduced energy-consuming devices that meet or exceed the Energy Star or comparable standards established by the U.S. federal government, where possible, without compromising quality or performance. These products use 25 to 50 percent less energy than their traditional counterparts. Reduced energy consumption will result in fewer fossil fuels burned and greenhouse gas emissions reduced, lessening air pollution. Energy efficient products often have an extended product life and decreased maintenance costs, and provide a return on investment due to a reduction in energy costs.
Project Management
The vendor will be responsible to the Judiciary’s Project Manager who has overall responsibility for the project schedule and adherence to contract provisions. The vendor’s staff must meet with the Judiciary Project Manager and other Judiciary staff as needed throughout the project. The vendor will abide by all Judiciary standards and protocols as defined by the Judiciary’s Project Manager. The vendor will be required to coordinate all efforts with Courts staff.
1 Project Management Overview
The vendor must develop a proposed project plan and present the plan, together with resource, scope and scheduling assumptions and constraints as part of your response. Following clarifications of scope and assumptions during contract negotiations, the vendor must develop a detailed “baseline” project plan, Project Charter, and project schedule, and submit the updated plan to the Vermont Judiciary within 90 days after contract signing. The baseline project plan will require Judiciary approval. Updates to this project plan must be submitted at least monthly as part of routine reporting and communications. The baseline plan will be reviewed quarterly and, if there is a change in scope, updates may be made to the baseline plan. Changes to the baseline plan must be approved by the Judiciary. The Project Plan must be submitted and updated in MS Project 2003 or a newer release when the Judiciary upgrades.
Your Key Project Manager will be responsible for the successful delivery of all non-Judiciary tasks and subtasks defined in the project plan. Progress will be monitored, and approach adjusted as necessary in Project Status Meetings. Your Key Project Manager will attend a Project Status Meeting weekly, or more frequently as needed, with the Judiciary Project Manager. Project teams will meet on an as-needed basis. Your Key Project Manager will be expected to provide bi-weekly (or more frequently as needed) written Status Reports to the Judiciary Project Manager. Status Reports will include, at a minimum: all tasks accomplished, incomplete, or behind schedule in the previous two weeks (with reasons given for those behind schedule); all tasks planned for the coming two weeks, an outline of the status of tasks (e.g., % completed, completed, resources assigned to tasks, etc), and the status of any corrective actions undertaken. The report will also contain items such as the current status of the project’s technical progress and contractual obligations, achievements to date, risk management activities, unresolved issues, requirements to resolve unresolved issues, action items, problems, contractor working relationships, and installation and maintenance results where applicable.
In addition, your Key Project Manager will be required to help plan, and create materials for, periodic Steering Committee meetings with other Judiciary stakeholders. Your Key Project Manager may be required, at times to present information to and answer questions from the Steering Committee members and Stakeholders.
The Judiciary strongly prefers that the proposed Key Project Manager has extensive implementation experience with the proposed solution, has a PMI “PMP” certification, as well as JIEM certification (note: JIEM certification for all proposed business analysts is a significant plus.) Please note that the proposed Key Project Manager must be identified specifically and be proposed as a “Key” project team member. The Vermont Judiciary reserves the right to approve all staff members designated as “key”. Responders should propose and submit resumes for the project team members who will be assigned to the VCase project, rather than anonymous or representative staff resumes. If selected as finalists, responders must bring key staff members to onsite presentations unless you make other arrangements with the Judiciary.
2 Project Planning
1 Alignment with an Industry Standard Project Methodology
The State’s Office of the CIO, Enterprise Project Management Office, has adapted the standard TenStep, Inc. project management methodology. TenStep is an industry-standard, PMBOK-compliant methodology for managing projects. We strongly encourage you to review, and base your project management strategy, using an approach consistent with that found at the TenStep website at .
The related lifecycle methodology is called LifecycleStep () The Judiciary requires (unless you explain otherwise, and we accept your approach) that the major tasks and deliverables you propose to this RFP are consistent with the major activity areas and deliverables recommended in the Package Implementation part of LifeCycleStep section 465 “Package Selection and Implementation.”
Upon contract award, the Judiciary can share the complete TenStep and LifecycleStep methodology and template library with our selected vendor. We have briefed the management of TenStep/LifeCycleStep on this RFP. If you wish to ask more specific questions about the TenStep methodology, you may contact them at 770-795-9097; ask for Tom Mochal or Tim Peek. You may email TenStep at: tom.mochal@ or tim.peek@.
The Vermont Judiciary wishes to adhere to this methodology. However, we recognize that each responding organization is likely to have its own structured methodology, and, we will give preference to those organizations that can prove industry certification achieved by their courts/justice groups, and a track record of success based upon those methodologies.
We also recognize that industry-standard methodologies share much common ground. Responders are free to adapt our TenStep methodology in whole as a structure for this response, or to present, in detail, your specific project methodologies - mapping phases, tasks (and where possible, sub-tasks) and deliverables to the TenStep framework “for implementing package-based software”. While we do not require that responders submit their entire project management methodology, we do expect a clear explanation of how your methodologies and standard deliverables fit our structure.
2 Risk Management, Organizational Change, and Communications
Responders are encouraged to submit templates of Risk Management, Organizational Change and Communications plans as part of their proposal, and will be required to submit VCase-specific drafts if selected as Finalists. Within the first 90 days after contract signing, you will be required to deliver an updated Risk Management Plan, Organizational Change Strategy, and Communications Plan. Your proposal must discuss the organizational experience you plan to provide to the project in each of these areas. An example of how your team has addressed each of these areas on prior projects will give us a better appreciation of your capabilities.
In the area of Communications, you must explain how you propose to keep your project team and the Judiciary’s team “in sync” and keep key stakeholders informed. The Judiciary’s team includes our IT and development staffs, as well as the Courts community which is widely dispersed around the state. The Judiciary already has an Intranet based on SharePoint 2003 and is getting ready to upgrade to Share Point 2007, and there will be some information on the VCase project on this site. Unless another method is proposed and accepted, the Judiciary expects, at a minimum, that the VCase project Document Library and Project Calendar will be on our SharePoint server. Experience in building team communication functionality in SharePoint is not required, but is a significant plus. You must propose how you will implement and maintain a VCase project Document Library and Project Calendar.
3 Alignment with Industry CMS and Systems Standards
Nationally and internationally, across industries and domains, many of the factors that support predictably good and useful results are codified in business and technical standards. The Vermont Judiciary is committed to using and maintaining the standards that will best support this project – from its conception throughout its lifecycle. In particular, we refer responders to standards related to case management systems, electronic filing, information exchange and state-specific Web guidelines.
We are also interested in your involvement and your business/product plans to incorporate emerging domain standards, such as the Justice Reference Architecture (JRA). Additional consideration will be given responders who can demonstrate an understanding of these emerging standards and a plan to incorporate them.
The following is a minimal, not exhaustive, list of standards that anchor our approach to Courts automation. We will evaluate responders’ familiarity with and previous experience in the use of these standards. Additionally, we will evaluate offerors’ capabilities and certifications in specific project and product disciplines, such as SEI, CMM, PMI and other relevant structures for delivering services and technologies. Responders must be specific in referencing their qualifications to the following standards:
a) National CMS Functional Standards ( ) - Both sets of national CMS functional standards are written at a high level. Vermont assumes that most vendors will be capable of complying with the standards. You should view the standards as setting a high level baseline for functional capability.
b) National E-Filing Standards: ( ; see also: ) - The national e-filing standards consist of the business process standards found on the NCSC website and the technical standards found on the OASIS website under the Legal XML Electronic Court Filing Technical Committee. The business process standards are very important, since they tie together best practices at the business policy, business process and technical standards levels. The Judiciary assumes that vendors are able to support projects that comply with these business requirements. However, the Judiciary may make business or policy decisions to reject specific standards. The Judiciary will indicate to vendors if it desires to reject any of these standards during applicable detailed design discussions during the project. The technical standards support a very modular and flexible architecture that can support a number of e-filing business models. For all e-filing managers implemented, the Judiciary desires that e-filing implementations comply with the interface standards contained in the specification. The Judiciary requires following the NIEM 2.0 or higher standard. The Judiciary requires following the OASIS Legal ECF 3.0 standard or higher for e-filing.
c) National Information Exchange Model (NIEM) and Court IEPDs ( see also: ) - The Judiciary does not have any current interfaces coded to the GJXDM (or NIEM) standard. However, some of the potential exchanges coming into VCase from other departments may be in the GJXDM format. For any GJXDM format exchanges, the proposed team must provide the processes necessary to translate these exchanges into NIEM Version 2.0 or higher for consumption through the interface processes defined in response to Chapter 8. All new exchanges and external interfaces must be implemented using NIEM Version 2.0 or higher. If an exchange requires data not contained in NIEM, you must consult Vermont for any preferences for data model standards. If there is a national reference IEPD in either the OJP Clearinghouse or the NIEM repository for a required external exchange, it must be used as the starting point for Vermont requirements. If there is a national reference court IEPD on the NCSC website for a required external exchange, it must be used as the starting point for Vermont for logical modeling requirements and then translated from GJXDM 3.0 into NIEM 2.0 or higher. All NIEM-based IEPD’s should comply with NIEM Naming and Design Rules (NDR) Version 1.3 or higher.
d) Justice Information Exchange Methodology ( ) - When available, Vermont will supply the vendor with an exported UMI file from the SEARCH JIEM tool to describe the required external exchanges and their associated business rules. Your proposed team must be capable of using the UMI file as a starting point for business requirements and exchange development and implementation.
e) Vermont Web Standards ( ) - The Judiciary requires that all web components of the VCase system follow the Executive Branch web standards except where the Judiciary agrees to another approach. The VCase must be “Section 508” ADA compliant except where the Judiciary agrees to another approach.
f) Justice Reference Architecture ( ) - The JRA provides a set of open national technical standards and guidelines for implementing a complete solution to external data exchanges. It provides recommendations for policies, service level agreements, messaging architectures, etc. Exchanges implementing web services must comply with the latest JRA Web Services Service Interaction Profile (WS SIP), unless the Judiciary approves another approach. Web services intended to be implemented as loosely coupled services should be identified and designed using the two service identification guidelines. Aside from the WS SIP, the JRA should be viewed as a non-mandatory but preferred set of best practices. Vermont reserves the right to require mandatory implementation of specific parts of the JRA during contract negotiation.
4 Master Project Plan
This RFP does not have one chapter for “Scope of Work”. Instead, we have separate chapters dedicated to what we feel are all the major components of the project. While Chapter 14 requires that you structure your response into the major areas that correspond to the chapters of this RFP, we allow you the freedom to propose your methodology, milestones, and deliverables within this structure in a manner that you feel will result in a successful, on-time, and on-budget project that meets the vision of the Judiciary.
The project plan you provide in response to this chapter is the first draft “master” project plan for the whole project, a summary project plan that includes all the major activity areas (e.g., “Tab” titles from your proposal) with the major task areas, milestones, deliverables, and time frames that you propose for each area. This master plan should be a “rollup” master plan which summarizes the more detailed tasks, staffing, timeline plans provided as support for each chapter in the remainder of your proposal. We expect this master plan will print on about two pages, and will roughly parallel the RFP Map chart at the end of Chapter 1.
The Judiciary acknowledges that this will be a “starting” plan, and the successive iterations will become more specific (and accurate) as the project proceeds. The selected vendor will work with the Judiciary’s Project Manager to update specifics in the plan during the 90-Try period. Throughout the project your Project Manager will coordinate with the Judiciary’s Project Manager to keep the Project Plan up to date.
As noted in Chapter 1, your project plan must be structured, to the greatest extent possible, to demonstrate major milestone dates during State fiscal year boundaries (July 1 – June 30). Completion of major milestones, and therefore invoicing, must correspond to the cost spreadsheets in your proposal. We will want to compare the major milestones to the FY cost estimates to get a feel for what work products you expect to deliver in a given FY.
Each year the Judiciary Project Manager, with the assistance of the Key Project Manager, will be required to provide a detailed report to management on what was accomplished in the current FY, and what is projected for the future years of the contract. A risk-adverse project plan will propose to provide functionality in such a way that the project will not spend an entire year working on deliverables and, at the end of the fiscal year, have nothing usable out of that year’s work.
As you work through your project plan please note that we will give extra consideration to those vendors that we believe provide a “realistic” project plan. Organizational change is difficult in any organization – and the widespread sweep of change that VCase brings to us is no exception. We ask for realistic staffing estimates and realistic timeframes based on experience. If you have no experience rolling out your proposed system in a statewide implementation of six jurisdictions such as in Vermont, we ask that you consider this in your plan and explain to us how you will mitigate the risks of a “first time implementation” and address the organizational change issues that are sure to arise.
5 Pre-Contract Trial Period (“90-Try”)
Your proposal must include a specific section detailing the cost to the Judiciary, staffing you plan to have available, the staffing you think we will need, a suggested plan with list of tasks, and an overview of your suggested approach to successfully accomplishing the objective of this trial: to clarify expectations that our teams, using your software and your experience, can successfully accomplish the tasks listed in this RFP, and to significantly lessen the risk for unexpected change orders during the course of the project.
We intend that this 90-Try evaluation will clarify project and system expectations in three major project areas before the contract is finalized and the project is underway:
1. Technical: We have talked with CITRIX and our local CITRIX support vendor, and came to the understanding that there is no sure way to determine that your software will run without issue in our environment without an onsite test. In the 90-Try period, we will establish a CITRIX test-bed in our datacenter and our staff will work with your staff to install your application, web, and database servers and software in our environment. You will assign appropriate technical staff to come to Vermont and participate in the 90-Try period as required to ensure that your software is compatible with our technical environment. We will test compatibility with CITRIX Presentation Server, test server requirements, printing capabilities, and do information bandwidth/speed tests using the software on our network. We will test your integration with our Active Directory. We will test remote access, database install procedures, database logging procedures, backup/restore procedures, and review technical documentation (database schema, data dictionary, helpdesk documentation, and other programmer and system administrator level documentation).
2. Functional: We are aware that very few, if any, of the current thin-client CMS/DMS/e-filing systems have been purchased and installed in a State-wide implementation, supporting six or more jurisdictions within one central database and one copy of the software. Many products have the extensive system administration level flexibility we are looking for, yet the flexibility may lead to setup complexity that we cannot fully understand from watching demonstrations. In the 90-Try period, we will require you to supply an experienced business analyst to work with our test team to use your “out of the box” capabilities to establish two or three court types, case types, locations, user roles, reports or mail merge forms, calendar entries, etc. We will simulate both back office and in-court real-time entry of case information – essentially working through several scenarios, with real-life workflow and business rules definition, from end to end (as much as possible). In this manner, we will have “hands-on” experience with the capabilities of the system and use this time to further verify that the system has the capabilities we believe are necessary to support our courts and the citizens of Vermont.
3. Management: We intend to use the 90-Try period to refine the project management plans. This will include having your project manager working with the Judiciary’s project manager to refine task plans, staffing plans, rollout planning, project methodology, deliverable formats, and so forth. Meetings with the Judiciary’s Steering Committee and other senior staff may be convened to update senior management on the progress of the trial and review updated planning materials. One output from the 90-Try period will be a more refined project and staffing plan to be included in the contract. Your project manager and some of your project team will be required to participate in the Independent Review (defined below) study when requested.
3 Prior Project Experiences
The Judiciary is relying on your team’s experience with implementing similar projects – i.e., modern, statewide, single-system, multi-jurisdictional case management solutions including e-filing and document management functionality. While we will call references as part of the evaluation process, part of your response must detail your experience.
You must include in your proposal a brief discussion of other similar projects that will provide your team with experience applicable to the VCase project.
We recognize that not every project goes according to plan. Therefore, as part of your discussion of your experience, we expect that you will discuss “key learnings” from prior projects – both in terms of what worked well and what did not work well (and what you would do differently).
4 Staffing
1 “Key” Staff
No “key” staff member may be reassigned or otherwise removed early from this project without explicit written permission of the Judiciary’s Project Manager.
The vendor must identify at least 3 “Key” staff members (as defined below) who will remain on this project until completion of the rollout activities defined in Chapter 7, Production System Rollout and Training, unless indicated otherwise in the vendor’s proposal. The vendor may propose other staff members as “Key” if desired.
A minimum of three Key staff members will be: the Key Project Manager, the Lead Business Analyst / Trainer (may be two people), and the Lead Technical Architect (or Programmer).
If the vendor prematurely removes a Key staff member from the contract without Judiciary approval, for any reason other than described below, the vendor will agree to provide 120 hours of additional services to the Judiciary at no charge for the early removal of a Key staff member. In addition, the vendor will make every reasonable effort to ensure that the early removal of a Key staff member has no adverse impact on the successful completion of this project. The penalty will not apply in cases where the Key staff member leaves the contractor's employ, becomes unable to perform job duties due to injury or illness, or the Judiciary requests that the Key staff member be replaced. The Judiciary must approve, in advance, replacements for Key staff members.
2 Project Manager
Your proposal must include the resume of your proposed Project Manager. The Project Manager must have at least 2 years experience with the company and company’s CMS product (either current or prior version). Extra consideration will be given proposals that bid to provide an experienced project manager with PMP or other professional certification. At least one Reference must be from a current or prior client where the project manager held a significant role on the project. Unless otherwise noted in your proposal, the Project Manager will be prepared to stay with the project until the 19 database rollout is complete, and the project manager will be onsite weekly until, at a minimum, the first VTADS database is successfully converted to VCase.
3 Business Analysts
You must propose an appropriate number of junior and experienced business analysts to complete the tasks and deliverables you propose. The resume of the Lead Analyst must be included. The Lead Analyst must have experience with your solution and have worked in a court setting. Including “sample resumes” of your proposed staff is strongly discouraged.
Since our approach is to purchase a “framework” we are assuming there will be an intense up-front effort at the beginning of the project to determine how to properly set up the system (see Chapter 6). You will need to explain what experience your proposed staff has in conducting requirements analysis, gap analysis, configuring your proposed system, and overseeing the rollout of your solution into production.
4 Technical Staff
You must propose appropriate technical staff to train and participate with our technical staff in hardware and telecommunications tuning, building servers, installing and tuning your software, building interfaces, reports, conversion programs, mail-merge forms, help desk and system administration procedures, database administration and tuning, and programming (if required). The resume of the Technical Lead must be included in your proposal. See Chapter 10, Architecture and Support, for more detailed information on Technical Staff expectations.
5 Trainers
The Judiciary expects you to provide technical documentation and functional documentation for the system. Functional documents will include end-user training materials. The trainer(s) you propose must have courts implementation experience, as well as experience with your solution. The trainer(s) you propose will assist in testing VCase before the first rollout, they will develop training materials and other associated training aids (e.g., “tip sheets”, perhaps develop the online help), and will lead “train the trainer” sessions for the Judiciary training staff. End user training is expected to be led by your trainers at first, and then gradually migrate to the Judiciary trainers (your proposal to Chapter 7 should provide plans for this transition). The resume of your Lead Trainer must be included in your proposal. Additional consideration will be given when the proposed trainers have a background with adult learning. At least one of your References must be for a client where the proposed Lead Trainer conducted the onsite end-user training.
6 Judiciary project staff requirements
Throughout the remaining chapters of this RFP we ask for your proposed staffing – both yours and ours. In response to this chapter you will need to summarize your assumptions on the background, capabilities, number and type of staff the Judiciary will need to assign to the project so that we support the timeline you propose. Your proposal must address your recommendations for Judiciary staffing categories including: project and executive management, functional business analysts, functional end-user training, helpdesk/support staff, documentation/help writers, programming staff, dba, and network and infrastructure support staff.
5 Checklist for Responding to this Chapter
Your response to this Chapter must include, at a minimum, the sections listed below. Please provide a complete response, but be as concise as reasonably possible. Your responses must be clearly labeled to correspond to the chapter section and subsection numbers listed above where stated, and be presented in the order listed below. You may add additional information after the last section listed. If you object or disagree with any requirement listed above, please note this in your Exceptions chapter.
1. Master Plan (Major Tasks/Milestones/Deliverables): Provide an initial “master project plan” that shows the major activity areas, tasks, milestones, and deliverables for the VCase project. It must include, and be consistent with, the “RFP Map” provided in Chapter 1 of this RFP. You must print the “master plan” with its Gantt chart bars in your response document; the master plan should span no more than 2 printed pages. You must also provide an overall baseline project plan as a separate .mpp file with your response. You may do a “master plan” and “subplans” (that provide more detail on individual chapters) in MS Project as one connected master/sub, or provide separate .mpp files for each chapter. Additional notes:
a. We will want to cross match your master plan with the cost spreadsheet proposed in response to Chapter 12 (Cost Item #10). We will want to know what tasks/deliverables are proposed by fiscal year.
b. If you do not feel that you can propose a project plan to accomplish all the requirements of this RFP consistent with the functions, timeframes, and milestones specified in Chapter 1, you must clearly state your exceptions in the Exceptions tab of your response (see also Chapter 14).
c. If the activity/task/deliverables you propose deviate from the LifecycleStep “Package Implementation” plan, you must explain deviations and why you propose that your method is advantageous to the Judiciary.
d. You must include a list of your major planning assumptions, entitled: Summary List of Planning Assumptions. This chart may be listed on a separate page and marked Proprietary and Confidential if you so choose.
2. Staffing: You must provide resumes of your key staff. You must provide a summary chart of staffing expectations, by chapter, entitled: VCase Staffing Expectations Summary. Your proposal will provide staffing expectations by timeframe in many of the individual chapters. In effect, this chart will serve as an alternative to putting “Resources” into the Master Plan in MS Project. At a minimum, the introduction to the chart must explain the staffing category abbreviations used (e.g., MBA = my business analyst; JBA = Judiciary business analyst); and, the chart columns must include: Tab (your proposal chapter) Number, Proposed Vendor Staffing by Category, and Recommended Judiciary Staffing by Category. If you have any explanations or assumptions you want to include about how this chart is constructed, you may include these assumptions in the Summary List of Planning Assumptions outlined above.
3. Project Management Methodology: You must explain your project methodology. You must clearly explain any deviations you propose from the TenStep methodology and why you propose that your method is more advantageous to the Judiciary. You must explain the key project management tasks, milestones, and deliverables you propose to deliver. Notes:
• Your Management team, headed by the proposed Key Project Manager and in conjunction with the Judiciary’s Project Manager, will be responsible for creating and maintaining project schedules, plans, and status reports throughout the project. From time to time special presentations may be required, for example, to periodic Steering Committee meetings of senior Judiciary staff.
• Your proposal must address how your Management team will plan, manage and execute tasks in the following areas listed below. You must address each “plan type” in the following order, providing at least a description of your methodologies and deliverables. You may add additional plans/areas as necessary. Initial plans in each of the following areas must be submitted by the selected responder to the Vermont Judiciary not more than 90 days after contract signing;
a) “Baseline” MS Project Plan / Work Breakdown Structure;
b) Status Report Content / Initial Project Meeting Schedule
c) Staffing Plan;
d) Security Plan;
e) Concept of Operations plan;
f) Change Order Procedures (including automated tracking method)
g) Communications Plan and Communications Infrastructure Overview (e.g., project Website outline, Share Point site design outline, online documentation)
h) Organizational Change Management Plan and Strategy Overview;
i) Hardware/Software Procurement and Installation Plan;
j) Beta Project Test Plan and User Acceptance Strategy;
k) Beta Data Conversion and Migration Plan;
l) Beta Training Plan / Strategy;
m) Beta Risk Management and Risk Mitigation Plan;
n) Beta Configuration Management Plan;
o) Beta Deployment, Rollout, and Transition Plan;
p) Beta Operations, Maintenance, Disaster Recovery, and Support Plan.
• In Project Management, the Judiciary believes you will be responsible, at a minimum, for the following Deliverables:
a) Creating and updating, as appropriate, Plans listed above (must include Judiciary Project Management signoff);
b) Coordination and update of all plans over the life of the project; and,
c) All necessary project management tasks to keep the project on-time and on-schedule and meeting quality and scope requirements.
4. Standards: You must explain where your solution will or will not follow generally accepted industry standards.
5. Project Document Library, Calendar, Incident Tracking, and Traceability Matrix: You must provide your detailed proposal on how you will implement and maintain a project document library, project calendar, and incident tracking system accessible to all project members. A strategy and architecture (e.g., software requirements: we recommend using our SharePoint 2007 system but you may propose another solution) must be proposed as part of the baseline system. However, if you propose additional costs for these features, you must propose these costs separately in response to Chapter 12, Costs. A Requirements Traceability Matrix must be built and be maintainable by the Judiciary and your project managers.
6. Cost Project Management Summary: You must provide a detailed list of the tasks and deliverables that are included in your Chapter 12, Cost Item # 10.
7. 90-Try: (Chapter 12, Cost Item #15) You must explain your methodology, proposed activities/tasks/deliverable, staffing, and assumptions for the 90-Try period.
8. Other: You may include other information that you feel is important for us to know about your project management methodology, staffing, timeline, approach, or assumptions.
Core CMS/DMS Requirements
1 Introduction
The Judiciary’s legacy case management system (VTADS) is largely hard-coded by case-type. Software developers modify VTADS to comply with annual statutory changes and to meet the courts’ evolving business requirements. Although VTADS has served its purpose well, the VCase project will include a flexible, generic court records management system (CMS/DMS). The generic CMS/DMS will be configured for each subject matter court and case-type to provide a high level of differentiated case processing. Essentially, the CMS/DMS will be a framework, rather than a compilation of hard-coded case-type modules.
VT anticipates working closely with the vendor to define and configure the CMS/DMS framework. As used in this Chapter, “configure” means to establish CMS/DMS settings by clicking checkboxes, entering values in textboxes, and adding, deleting, or editing records in tables. Configuring the system also may include stand-alone logic statements containing Boolean operators. Configuring the CMS/DMS is distinguished from coding or programming, which requires a software developer to write programming code to produce the desired functionality. The VCase CMS/DMS will be maintained by VT’s software developers and court business analysts. However, the business analysts will be expected to configure the system as needed. Thus, the VCase project is highly dependent upon procuring a configurable CMS/DMS.
For the vendor’s convenience, current versions of various statutes and rules are included with this document. The vendor is required to deliver the system configured consistent with the version of the statutes and rules in effect at the time of delivery.
While in other chapters in this RFP (e.g., Interfaces, Conversion) we ask questions, and then ask for your proposed implementation strategy, staffing estimates, and timeline (and cost in the Cost chapter), that is not our approach for this Core CMS/DMS Requirements chapter. The focus of this chapter is to find out what you can deliver for a flexible courts CMS/DMS framework. We will use the responses to this CMS/DMS requirements chapter to help us to choose the most flexible proposed framework that has the highest chance of success to support the Vermont Judiciary’s operational requirements. The level of effort (and therefore timeframe, staffing and costs) to configure and implement the capabilities you propose are separated into other chapters.
Thus, the following is a review of how the RFP chapters are connected:
• Chapter 4 (this chapter) - Core CMS/DMS Requirements focus is on the capabilities of your proposed CMS/DMS solution. Your definition of the capabilities of your proposed CMS/DMS solution will be defined by your answers to the questions in this chapter and your responses to Attachment 6, Core Capabilities Chart. Unless you state otherwise, we do not expect you to list any costs in the Costs chapter associated with this Chapter.
• Chapter 5 – E-Filing - While e-filing is an important and integral part of the VCase project, over time the team has tended to focus on e-filing requirements, configuration, and construction strategy separately from the CMS/DMS. Therefore, the four base e-filing initiatives are described separately in Chapter 5.
• Chapter 6 – Initial System Configuration and Construction - Focus on CMS/DMS strategy, timeline, and staffing the first months of the project to perform the “as is”, “to be”, system configuration, training class development, documentation, etc. in preparation for going “live”. While e-filing requirements, design, and configuration may (or may not) merge into one “team” in the project, configuration and construction of e-filing is addressed separately in response to Chapter 5.
• Chapter 7 – Production System Rollout and Training - Focus on the strategy, timeline, and staffing to roll out your system into production in the courts statewide. It is in Chapter 7 that we expect the e-filing capabilities to “merge” with the CMS/DMS, and therefore Chapter 7 combines the rollout of capabilities described and configured in Chapters 4, 5, and 6 (and, of course, the production implementation of Interfaces, Conversion, Architecture, etc.)
• Chapter 10 – Architecture and Support - Chapter 10 will ask for your specifics on software versions, installation requirements and staffing, etc. The requirements you respond here, in Chapter 4, must be accomplished by the software you propose in the Architecture chapter.
• Chapter 12 – Costs - We expect that there will be no costs/staffing/timeline associated with this Chapter 4 on Core CMS/DMS Requirements. Tasks, timeline, staffing, etc costs will be associated with the other chapters (e.g., Chapters 6 and 7) as outlined above.
2 Why don’t we have an Extensive Requirements Checklist?
Most RFP’s for courts case management systems focus on “operational requirements”. They often include a chart of hundreds or thousands of checkboxes for the vendor to complete, with the goal of asking: “Does your package include x?”. We found this type of chart would not accomplish the goal of telling us “what you provide” for several reasons including:
• One liner requirements are most often unclear, so the vendor is not sure what the court had in mind when they “check the box”.
• Even when the boxes are checked, it is hard for the court to review thousands of line items and compare them across vendors, since each vendor may propose a different solution to accomplish the perceived function of the line item.
• When the project gets started, the team needs to review and reconfirm all the functionality anyway, usually with a “Gap analysis”. These studies will uncover many more features that were never discussed.
• If the court does not, or cannot prioritize the line items, then it looks like all hundreds (or thousands) of the items are “high priority” which does not help with either the vendor’s bid or the evaluation of the proposal.
• Due to the research we have done (e.g., CTC-10, onsite vendor demonstrations of most leading CMS systems) we have basic knowledge of what all systems can do and do not feel the need to ask most of the basic “checkbox” questions common in most CMS RFPs.
• Lastly, but most importantly, our research into the current status of the CMS marketplace is that most vendor’s new “ground up thin client system rewrites” have produced flexible “frameworks”, instead of hard-coded “packages”. Therefore, we assume that most of the traditional line items are immaterial anyway.
Therefore, this chapter on Core CMS/DMS Requirements focuses on the most important “framework” and operation capabilities by asking a set of specific questions in addition to the Core Requirements Checklist.
3 Capabilities of Your Proposed CMS/DMS
In order to provide us with the information we need to evaluate your offering, we have divided up our Core CMS/DMS Requirements questions into two parts. Your proposal must address both.
• Core Capabilities Chart - Attachment 6 provides a chart of high priority requirements, where we ask if you include these or not (and allow you to make comments if you have additional information.)
• Topics/Questions - Instead of including hundreds (or thousands) of line items in the Requirements Chart, we have included the most important checkboxes in the chart, and we have supplemented the chart with a set of questions below. You must respond to each.
NOTE: Throughout this document, most chapters will ask a set of questions and require that you answer each. You must clearly correlate your answer to our question in all cases. You are encouraged to clip our question into your response and respond to each. If you respond in a Q/A format, please be sure to distinguish our question from your answer, for example, by using a different font or by putting our question in italics.
The following are a set of specific questions that we require you to address. You must answer each in the order presented. Please provide complete and concise answers.
1 Usability
The Court staff needs a system that helps them enter data quickly and accurately. The staff also needs a system that accommodates different approaches and preferences in making entries. This is particularly important because VT’s courts tend to have small staffs, and each staff member performs many functions.
Please respond to the following:
a. Explain how your system accommodates user preferences in navigation and facilitates rapid accurate entries.
b. Does your system provide a keystroke alternative to every mouse driven action? Would VT be able to choose “hotkeys” for selected operations?
c. Does your system return a list of cases in response to a query and allow selecting multiple cases from that list for entering events in multiple cases with a single transaction?
d. Does your system enable users to perform structured and unstructured searches to return a list of cases and participants?
e. Does your system allow a user to leave a case in the middle of making data entries (e.g. lookup another case while answering the phone) and then return to that case without losing data?
f. Does your system allow, in a single transaction, reassignment of scheduled cases from one judge to another, one court reporter to another, one prosecutor to another, and so on?
g. Does your system allow users to see all bail in all cases for a particular defendant on a single screen?
h. Does your system alert users when they attempt to schedule an attorney who is already scheduled at that time in another county?
i. Does your system allow users to create and save their own macros for hearing notices and orders?
2 User permissions
VCase requires detailed control over user permissions for several reasons. All cases in all courts will be processed through a single system, and access should be limited to cases within each staff person’s area of responsibility. Vermont’s courts are disbursed throughout fourteen counties, and many court employees have responsibility in multiple courts.
Please respond to the following:
a. Explain how your system handles user permissions, describing in detail what permissions may be granted or denied.
b. Describe whether permissions may be assigned by court, case-type, and venue, and whether permissions may be assigned to access confidential, sealed, expunged, and redacted case records.
3 Reports
Case management systems often are described as participant centric or case centric, meaning that queries and reports may be configured to describe information about each participant or each case within the database. VCase must be both participant centric and case centric. Additionally, it must be claim centric and request centric. For purposes of this discussion, consider the following relationships:
• One participant may be involved in many cases.
• One case may involve many claims (e.g. criminal charges, civil cause of actions). Each claim is a distinct legal basis for filing a court case.
• One claim may involve many requests (e.g. complaints, motions, petitions, appeals). Each request seeks relief from the court. A request may seek to resolve the entire claim (e.g. a motion to dismiss the claim) or the request may seeker minor relief within the claim (e.g. a motion to continue a hearing).
• One request may involve many filings, hearings, and court decisions/orders. Each request may be adjudicated independent of other requests under the same claim or case. Requests may be filed and adjudicated even after a case is “closed”. For example, post judgment motions and appeals may occur after the trial court “closes” a case.
Please respond to the following:
a. Explain how your system meets VT’s need for reporting by participant, by case, by claim, and by request.
b. How would your system calculate and report elapsed time between: (1) the date when a juvenile abuse petition is adjudicated in favor of the State; and (2) the date when the court issues a disposition order determining the juvenile’s place of residence?
c. How would your system calculate and report the age of all pending Violation of Probation Complaints (VOPs) against a particular defendant? You should assume VOP’s are not new cases, but rather they are post-sentence proceedings under a particular charge in a criminal case.
d. How would your system identify and report the number of small claims cases with at least two motions to continue that were granted?
e. How would your system compare and report elapsed time to a time standard or goal assigned to particular events?
f. How would your system report elapsed time between any two types of events associated with a particular motion, petition, or appeal under a single claim?
g. Provide a list and example of the “stock” reports included with your system.
4 Restricted Information
As information becomes easier to distribute, the public becomes increasingly concerned about restricting access to court records. Restricted access includes records that are classified as confidential, sealed, expunged or redacted by law, and records that are redacted, sealed, or expunged by court order. See Public Access to Court Records Rule 6(b) and Rules Governing Dissemination of Electronic Case Records. Case records at all levels of granularity may be restricted, including:
• all cases within a case-type
• an individual case record
• a portion of a case record (e.g. one criminal charge)
• all documents within a document-type
• an individual document
• a portion of a document
• a data element
• an index of cases
Certain records are always restricted (e.g. social security numbers). Some records become restricted upon an event, such as an order sealing or expunging the record. Some records are initially restricted, but then become public after an event (e.g. a search warrant is confidential until executed and an inventory is filed with the court).
The extent of the restriction also varies widely. Some restricted records are not available to the public, but are available to parties and court staff (e.g. juvenile cases). However, judiciary policy is to provide access to juvenile case records only to court staff who work in the venue where the juvenile case is processed, and only to court staff that actually work on juvenile cases. Some restricted records are available only to some of the participants in a case. Thus, VCase must have extensive requirements to enable VT to restrict access to records by user account and participant role.
Please respond to the following:
a. Please explain how your system would enable VT to meet its need to restrict access to information as described above.
b. How would your system allow court staff to store the names of victims in criminal cases and print victims’ names on hearing notices, but not print victims’ names in Conditions of Release pending trial? How would your system display victims’ names to certain users groups, but not others?
c. How would your system protect restricted information from appearing on user screens or in the results of queries/reports for users without permission to view those records?
d. How would your system provide family court judges access to view sealed records, while providing family court managers and selected court staff access only to indices to sealed records (no access to the actual record)?
e. How would your system change the status of a record from restricted to unrestricted, or vice versa, subsequent to an event in a case? How would your system change which groups of users can access restricted records subsequent to an event in a case?
f. How would your system automatically redact a portion of a document, such as social security number, bank account number, or the name of a witness?
g. Assuming the system is configured with a user account for the general public to access data and documents, how would your system prevent a public user from viewing, printing, etc. each of the records prohibited by Rule 3 of the Rules Governing Dissemination of Electronic Case Records?
5 Events
Your system should enable VT to configure an unlimited number of event-types for each case-type. Events include all filings and other communications received by the court, all hearings, all notices/decisions/orders issued by the court, and all financial transactions related to a case.
Please respond to the following:
a. Explain the function of event-types within your system.
b. What skill level (e.g., power user, end user, programmer,business analyst) is required to configure event-types? How is an event-type configured? What are the parameters/elements/data fields for each event-type?
c. Are pertinent events related to each other? Is a response to a motion related to the motion? Is the court’s decision on the motion related to the motion? Can the system generate reports to describe the status or outcome of related events?
d. Can multiple electronic files be attached to each event?
6 Business Rules and Workflow Rules
Your system should enable VT to configure rules. Each rule should have a trigger and automated response.
Please respond to the following:
a. Explain your rules methodology for both business rules and workflow rules.
b. Does your system use a table, graphical interface, or some other method for configuring rules? What skill level (e.g., power user, end user, programmer, business analyst) is required to configure rules? How is a rule configured? Please attach screenshots to illustrate configuring a business rule and a workflow rule.
c. What are all the possible triggers for invoking a rule? What are all the possible responses?
d. Does your system enable configuration of a warning message (with option to cancel) prior to a response being completed?
e. Do you separate business rules from workflow rules, or does a single method/component/engine control both?
f. Does your system store rules separate from other components of the system? What product do you use for the rules repository? Could the rules repository be replaced with a product from another vendor without disrupting the CMS/DMS?
g. Does the application enable rules to be established for an effective date range? Can multiple versions of rules be created, and will the system select the correct version depending on the date when triggered or depending on the date contained in a data field?
h. Does your system allow rules to be configured for global application? For example, could one rule control the format for all telephone numbers entered on every screen in the system? Could one rule set every case in every case-type to a status of “waiting for judge’s response” whenever a motion is filed?
i. How would your system automatically generate hearing notices and automatically distribute those notices by email to appropriate participants for each scheduled case? Your answer to this question should assume that not all “participants” should receive all notices. For example, a victim may receive hearing notices for some types of events, but not others.
7 Merge Documents
Your system should enable VT to configure merge documents containing boiler plate and data insertions. Ideally, the merge documents also may include conditional boiler plate and data insertions, depending on the user producing the documents, participants in a case, and the value of specified data fields. The merge document should assemble without noticeable delay by the user and appear as a Microsoft Word document. The user must be able edit the MS Word document, prior to printing or electronic distribution.
Please respond to the following:
a. Explain how your system handles merge documents.
b. How is a merge template created? What skill level (e.g., power user, end user, programmer, business analyst) is required? How would a business analyst, without programming skills, configure a merge template and make the template accessible by users? How long would it take for a typical business analyst to configure a hearing notice with 10 data insertions, logic required to display an appropriate address for each participant, and logic required to prepare a notice for only those participants with designated roles in the case.
c. Does the application enable conditional boiler plate and conditional data insertions?
d. Does the application enable merge documents to be established for an effective date range? Can multiple versions of a document be created and will the system select the correct version depending on the date of assembly or depending on the date contained in a data field?
e. What software application extracts data for insertions in the document? Is every data element in the system available for merge documents? Where is the merge performed (i.e. in an application prior to displaying the document in MS Word, or in MS Word)? How does your approach impact the speed of the merge?
f. How quickly does a merge document assemble (time of click to time of the MS Word document appearing on the screen)? Is the delay during assembly noticeable to a user?
g. Does the system allow a user to insert personal (meaning unique to that user) macros into a merge document after it has been assembled?
8 Electronic Document Management
The system must manage electronic documents in all formats. Pertinent documents must be associated to each other. The system must enable users to view, print, play, or email documents.
Please respond to the following:
a. Explain how your system manages electronic documents.
b. Explain how your system will allow users to scan in documents.
c. How do you propose that your scanning/document management solution will replace the Judicial Bureau 1Image system and functionality?
d. What application manages electronic documents? Could the application be replaced with an alternative DMS without disrupting other components of the system?
e. Does the system associate pertinent documents? For example, would a motion filed by Party A, an opposition filed by Party B, an amended motion filed by Party A, and a decision/order issued by the court all be associated to each other? If so, how?
f. Does the system allow electronic documents to be attached to all events in case records? Does the system allow electronic documents to be attached to data fields in the case records?
g. Does the system automatically store a copy of every document generated by the system? Does the system automatically attach each document to a corresponding event in the case record?
4 Checklist for Responding to this Chapter
Your response to this Chapter must include, at a minimum, the sections listed below. Please provide a complete response, but be as concise as reasonably possible. Your responses must be clearly labeled to correspond to the chapter section and subsection numbers listed above where stated, and be presented in the order listed below. You may add additional information after the last section listed. If you object or disagree with any requirement listed above, please note this in your Exceptions chapter.
1. Answer each of the questions presented above in the order presented.
2. Complete the Capabilities chart, Attachment 6, by checking whether your system includes each of the individual requirements. You may add optional comments, called Notes, in a second corresponding table (see explanation above the chart in the Attachment.)
3. Provide a list and example of the “stock” reports included with your system.
4. Provide a list and example of the “stock” merge documents included with your system.
5. Provide an overview of the capabilities of your system.
6. Explain why your solution is the best choice for VT.
E-Filing
1 Introduction
One of the fundamental goals of the VCase project vision is “Access to Justice”. As stated in Chapter 1:
A high priority for the Judiciary is to improve access to the courts by citizens through improving our web capabilities. This includes a combination of electronic filing, electronic forms, and document management functionality to implement the electronic interchange of information between the courts and external stakeholders (e.g., certain members of the Bar, pro-se litigants) to the maximum extent possible. A goal for this RFP is to install the infrastructure and support the move toward paperless case files throughout the Judiciary.
The goal of e-filing is to become as paperless as possible so that, within five years from contract signing, all cases in all dockets in all courts are processed electronically based on electronic data and documents. Our expectation is that the e-filing mechanism will be primarily document based, but we want to take advantage of instances where direct filing of data can significantly improve workflow.
To meet areas of great need, to gain experience in working in a paperless environment and to test paperless workflow in each trial court, four paperless applications will be implemented during the VCase rollout as described in Chapter 7. In this RFP, we have called the design, configuration, construction, and rollout of these four paperless applications “e-filing”.
The expectation is that as the CMS/DMS is rolled out to a District/Family/Superior court “database”, that same rollout initiative will include the appropriate e-filing application(s). Once the rollout activities as described in Chapter 7 are completed, the VCase project will continue with “Phase 2 E-Filing and Probate” activities (described in Chapter 13) to complete the court wide paperless initiative.
2 Judiciary Expectations for the E-Filing Solution
The purpose of this section is to highlight the Judiciary’s major technical approach expectations for the proposed e-filing solution:
• We seek a solution that provides electronic filing “managers” (e.g., “A2J Author” is a type e-filing “manager” software) designed to bridge the gap between the new case management system and any party wishing to electronically file documents.
• We do not require only one “manager” subsystem for all types of e-filing scenarios listed below. We realize that e-filing can be accomplished with a mix of technologies, and unless specified otherwise, you are asked to bid the most effective and least cost approach to each scenario listed below. For example, e-filing may be accomplished by attaching a .pdf file to an email, building a custom web interface form to ask for information and attachments, building an interface that automates the completion of a form by asking the user a series of questions, providing a package that powers a web interface to collect forms and data, or through the use of a “service” which provides a web portal to collect data and then sends the data to the court.
• Vermont does not want you to bid a “service” type (pay by transaction) interface for any of the scenarios listed below. We expect to own the electronic filing “manager” software.
• The A2J Author tool ( ) is required for one pro se scenario below (i.e., it is just one type of e-filing manager.) You may bid this software for other scenarios if you think it would be effective. Our objective is to make the e-filing scenarios listed below free to users for the foreseeable future.
• An e-filing manager may be part of the base CMS or a separate package. We will consider cost-effective options, including:
o A full-featured COTS package that supports most court-oriented e-filing needs;
o A custom module that is already a built-in part of the proposed CMS framework;
o A proposal to build a simple, custom-built e-filing portal and manager that will efficiently meet our needs;
o A proposal to install, configure, construct and implement an open-source e-filing manager;
o A partnership with a third-party to build, support, and host a portal and e-filing manager that we will own. For example, the Judiciary’s electronic ticket payment system, Court Pay, is custom built for us, and supported by the Vermont Information Consortium[1] (e.g., they house the server; they have the merchant account with the bank and transfer the money back to us via nightly ACH transactions).
• We are assuming “tight” integration between your proposed e-filing “manager” and your CMS/DMS. How do we define “tight”? In responses to our prior RFP there was a clear distinction between the CMS and the e-filing piece – each was explained separately, training was bid separately, licensing was separate, support was separate, etc. We know that if you bid a separate package there will be some separation but we will be looking for signs of how well the CMS/DMS and e-filing integrate including areas such as:
o Integrated training during rollout – the CMS and e-filing are “one system” not “two”;
o E-Filing capabilities are integrated into the CMS online help and user manuals where appropriate;
o Integrated security so that defining security roles in the CMS will automatically control security roles in the e-filing system;
o An integrated “CMS/DMS/e-filing” solution assumes one place for our Helpdesk to call for help on any part of the system, especially when the integration between parts has an issue or needs to be upgraded;
o Upon acceptance by the court staff, e-filing attachments are automatically stored in the DMS and attached to the appropriate event record in the CMS; and,
o New filings submitted through the e-filing manager automatically put a message into the CMS workflow engine so that an entry on the appropriate court staff work queue prompts the court personnel to process the filing.
• We are assuming a smooth flow between your interfaces engine and the e-filing manager. As described in Chapter 8, Interfaces, we are looking for an interfaces engine that will consume XML from any source – another agency’s system or an e-filing manager. We require that all e-filing managers that you propose will communicate via industry standard LegalXML (except A2J, which currently uses .anx files, but may eventually communicate via LegalXML) and that they will communicate with your CMS through the standard interface capabilities that you propose for Chapter 8.
• There will be a “door” between the e-filing manager and the CMS. We are looking for a solution that allows the court staff to review all e-filing input – be it data fields or attachments – before they are “accepted” into the CMS/DMS. “Opening the door” to accept each e-filing should be from within the CMS, and be very user-friendly to the user of the CMS. In rare cases where the court staff does not want to accept the e-filing, there must be a user-friendly way in which the court staff can electronically communicate with the party that submitted the e-filing. The system should allow the court staff to correct minor data errors in the e-filing (e.g., assume this would modify the XML) before it is accepted into the CMS.
• The proposed solution must have a flexible e-notification process to notify applicable parties of e-filing.
• The proposed solution should have a way for filers to track the status of their filing.
• The proposed solution must have a way to collect court fees, and fees must be easily configurable by form.
• Adding a new form type to any proposed e-filing manager should not involve other software products, extensive training, and preferably not require programmer-level support.
3 General Capabilities of Your E-Filing Solution
The following are a set of specific questions that we require you to address. You must answer each in the order presented. Please provide complete and concise answers.
a) Does the CMS provider has partnership with an e-filing software firm? If so, which one(s)?
b) Does the CMS provider have experience with A2J Author, HotDocs, and HotDocs version of XML (e.g., .anx files)?
c) How “tightly” integrated are the CMS, DMS, and e-filing capabilities? What specific steps have you taken to integrate the proposed e-filing managers into your proposed CMS version? Explain.
d) Does the CMS provider have a flexible methodology for accepting XML data from any e-filing software method through the standard “interfaces engine” as proposed to Chapter 8?
e) Does each proposed e-filing manager capture any type of data for any type of form, pass data to the CMS via industry standard XML, plus allow user to append attachments, such as .pdf files, and DMS can store the attachments and automatically tie attachments to the corresponding entry in the applicable case?
f) Does each proposed e-filing manager allow the Judiciary to program new forms/data capture capabilities into the e-filing system vs. system requires the CMS provider to program and modify e-filing system for each form?
g) Does each proposed e-filing manager have tight integration with the CMS and DMS solution, yet allows for security so that the public cannot get access to the production CMS and DMS data?
h) Does the CMS provider have a methodology for how the workflow integrates with e-filed forms: e.g., form workflow will be part of CMS vs. will be part of DMS vs. workflow for a form will be part of both the CMS and DMS? If workflow is part of both CMS and DMS, how do the systems integrate?
i) Is there a common approach applicable for all proposed e-filing managers for implementing a “clerk approval step, i.e., the ‘Door’ ” between the e-filing system and acceptance of the XML data into the CMS?
j) Has the CMS provider tested the integration of CMS, DMS, and e-filing at another client site? Is so, explain and provide references.
k) What is the impact on the electronic notification features if the Judiciary does not have scanning? Does the CMS have a built in way to know whether the data/form underlying an entry is electronic or on paper? Would this be reflected on a docket sheet report?
l) Do the proposed e-filing managers have a built in interface to email, especially MS Exchange, to produce automatic email responses to filers? [Note: all lawyers in Vermont must supply the court with their email address.]
m) Does each proposed e-filing manager use the Legal ECF 3.0 or above e-filing XML standard? If not, explain what format XML is generated from each e-filing manager?
n) Are there plans to upgrade all e-filing managers that currently use ECF 3.0 to ECF 4.0? If so, what is the timeframe for the upgrade?
o) If a form is e-filed, how will the end user and a court clerk print out a hard copy?
p) Do the e-filing managers have a methodology for receiving money (which may vary by form) and sending that money to the State Treasurer? If so, explain.
q) Does the e-filing solution propose a Payment Card Industry/Data Security Standards compliant payment processing engine?
r) Who will supply e-filing system training and documentation for both end-users and programmers and will the training be consolidated with the CMS/DMS training as proposed to Chapter 7 (and technical training as requested in Chapter 10?)
s) How will project support, and post-implementation support, be provided to each proposed e-filing manager? Will there be a single point of contact for our Helpdesk for the entire VCase solution, including the e-filing managers? If not, who will be the points of contact (a) during the project and (b) during post implementation?
t) What computer languages and other IT infrastructure would the Judiciary need to have and/or train staff to install, use, and modify each e-filing manager?
u) Do the proposed e-filing managers support electronic signatures? If so, explain how.
v) Are there any proprietary components to your proposed e-filing mangers? [An aside: A2J is completely open source.] If so, explain.
w) List other capabilities of your proposed e-filing solution not mentioned above that you feel make it the strongest e-filing framework to support paperless courts statewide in Vermont.
4 Detailed Requirements for the Baseline E-Filing Initiatives
As stated above in the Introduction, the Judiciary requires the implementation of four paperless applications during the VCase rollout as described in Chapter 7
1 Superior Court – Mortgage Foreclosure Cases
Background
The Vermont Superior Courts process about 817 mortgage foreclosure cases per year (not including Chittenden and Franklin Superior.) Most of these cases are routine and result in default judgments. The largest percentage of these cases is filed by a small number of lawyers who specialize in this work. The procedure for these cases is specified in Rule 80.1 of the Vermont Rules of Civil Procedure. To the extent possible, e-filing of these cases should proceed by electronic forms and standard orders that will be developed by the Vermont Judiciary within six months of the award of a contract. Otherwise, e-filing will be by document. E-Filing will include case initiation, service and collection of filing fees. E-Filing for these cases must be introduced at the same time as the CMS in each county.
Note that 90+% of mortgage foreclosure result in default judgment. Listed below are the documents in such cases:
1. Complaint – Not a form, but content must conform to Rule 80.1(b). With it must be a description of the property (should be in electronic form for reuse) and copies of documents (note, mortgage, assignment, etc.).
2. Motion for default judgment, accounting and order for public sale – Not a form, but should be; must conform to Rule 80.1(f) & (g). With it are many documents – an affidavit of amount owing; affidavit of non-military service; affidavit of attorney’s fees; often a motion for excess attorney’s fees; a proposed order; proof of service.
3. Clerk’s accounting – Done by the clerk from the affidavit above. Counties have forms.
4. Order for default judgment, amount owing, time for redemption and for public sale – Presumably this is signing the proposed order presented and including the information in the clerk’s accounting.
5. Certificate of non-redemption – A form signed by the clerk.
6. Motion for confirmation – Not a form but standard under Rule 80.1(k); includes a proposed order. Attached must be an affidavit of the proceeds and costs of the sale – see Rule 80.1(j).
7. Order of Confirmation – Usually simply the form.
Even in the other few percent where there is a dispute, there are not many more forms. The main additions are:
1. Answer to the Foreclosure Complaint. Not a form.
2. Motion for Summary Judgment – Not a form but governed by Rule 80.1(c).
3. Motion to Extend Time for Redemption – Not a form; governed by Rule 80.1(e).
4. Appraisal – Filed as a report where ordered in the judgment order, see Rule 80.1(I);
5. Request to Appeal – Not a form; Rule 80.1(m).
6. Order Granting/Denying Appeal – Should be a form.
Your Response
Your response to this section must include your methodology, tasks, milestones, deliverables, timeline, proposed staffing, and assumptions for gathering requirements, installing, configuring and/or constructing an e-filing manager to support electronic filing of mortgage foreclosures as defined above. This plan must also include testing, documenting, and preparing training materials for mortgage foreclosure rollout. Ten or fewer forms will be defined according to the list presented above.
Your response to Chapter 7 will include your effort, tasks, deliverables, staffing, timeline estimates, and assumptions for training the court staff in how to process these forms, as well as participating in up to three public training sessions for proper use of the mortgage foreclosure e-filing manager. Extra consideration will be given to those proposals that include ongoing training plans that minimize staffing, such as including the development of online computer based or video training (especially aimed at helping non-court staff use the system without having to contact the court.)
2 Family Court – Juvenile, Children in Need of Care and Supervision (CHINS) and Termination of Parental Rights (TPR) Cases.
Background
The Vermont Family Courts process about 1,000 juvenile (not including delinquency) cases in a year. These cases are largely handled by a small number of lawyers – prosecutors, lawyers for the Vermont Department of Children and Families, public defenders, contract public defenders and assigned counsel. The procedures in these cases are controlled by Vermont Rules for Family Proceedings Rules 1, 2 and 3 and Chapter 55 of Title 33 of the Vermont Statutes Annotated (until December 31, 2008) and Chapters 51, 52 and 53 of Title 33 of the Vermont Statutes Annotated, effective January 1, 2009. The basic pleadings and orders are now issued on forms. In addition, a number of reports are typically filed in paper form. Where forms currently exist for pleadings or orders, these should continue to be used for e-filing. Reports and proposed findings and conclusions should be filed in electronic form. At case opening, a data filing containing basic data on the child(ren) and family should be made to send the data to the CMS. Otherwise, e-filing will be by document. E-Filing for these cases should occur at the same time as the rollout proposed in Chapter 7.
Your Response
Your response to this section must include your methodology, tasks, milestones, deliverables, timeline, proposed staffing, and assumptions for the gathering requirements, installing, configuring and/or constructing an e-filing manager to support electronic filing of TPR and CHINS as defined above. This plan must also include testing, documenting, and preparing training materials for their rollout.
Between June – September, 2008, the Judiciary has a contract with NCSC to conduct a “Juvenile JIEM Analysis” project. The deliverable from this project will be 6 – 10 juvenile docket related IEPDs. Two of the required IEPDs will be for TPR and CHINS. We intend to provide these IEPDs to the set of Vendor Finalists (they will also be posted to the IJIS bulletin board). Your response to this section must assume that we will have done the TPR and CHINS analysis and have both the requirements and the NIEM-compliant XML required to build these exchanges. Your response must include your assumptions on how these IEPDs have influenced your planning to complete the requirements for this e-filing interface.
Your response to Chapter 7 will include your effort, tasks, deliverables, staffing, timeline estimates, and assumptions for training the court staff in how to process this data. Extra consideration will be given to those proposals that include ongoing training plans that minimize staffing, such as including the development of online computer based or video training (especially aimed at helping non-court staff use the system without having to contact the court.)
3 District Court – All Criminal Cases in Two Pilot Courts
Background
E-Filing will be implemented for all District Court cases in two counties, to be chosen by the Vermont Judiciary. Except for a case opening filing to provide basic information on the defendant, all e-filing will be of documents, replicating the filing in the paper environment. The expectation is that the introduction of e-filing in the pilot courts will occur at the same time as the introduction of the CMS, but this expectation, as well as timing of the introduction, will be negotiated between the vendor and the Vermont Judiciary.
Your Response
Your response to this section must include your methodology, tasks, milestones, deliverables, timeline, proposed staffing, and assumptions for gathering requirements, installing, configuring and/or constructing an e-filing manager to support electronic filing of all criminal case materials as defined above (in two pilot courts). This plan must also include testing, documenting, and preparing training materials for rollout to these two courts.
The approach must be to propose a “plain vanilla” e-filing manager interface. Our definition of “plain vanilla e-filing” is essentially a simple method to capture basic data (e.g., filer’s name, filing date, case number, filing type) and allow the filer to attach a document (e.g., a pdf document of text, such as a motion).
The criminal courts workflow includes basic forms such as:
• Charging document (which is a form, comes in from the State’s Attorney; assume this will come to us via an NIEM-compliant XML file generated by their system );
• Affidavit (if hand written at a police station, assume the police will scan it in and submit via your proposed e-filing manager)
• Motions (assume they are free-form .pdf documents attached to an e-filing form)
• Bargain, Plea, and Sentence documents (again, .pdf file attachments)
Your response to Chapter 7 will include your effort, tasks, deliverables, staffing, timeline estimates, and assumptions for training the court staff in how to process these forms, as well as participating in up to three public training sessions for proper use of the criminal court pilot e-filing manager. Extra consideration will be given to those proposals that include ongoing training plans that minimize staffing, such as including the development of online computer based or video training (especially aimed at helping non-court staff use the system without having to contact the court.)
4 Superior and Family Court – Filings by Pro Se Users in Specified Proceedings.
Background
The Vermont Judiciary is committed to using digital technology to improve access to the courts by pro se users. You must propose A2J Author software as the e-filing manager for this purpose. A2J Author software employs a user-friendly Q&A interface, with extensive user help, to construct completed litigation forms and attachments. It is currently used to create completed paper forms for filing into a court. The section below on Technical Notes presents an overview of the expected architecture for the use of A2J with VCase.
Coextensive with the VCase RFP and evaluation process, the Vermont Judiciary has entered into a project to create A2J Author templates (scripts) for forms in family proceedings, and thereafter in civil proceedings. A substantial body of these scripts will be available within a year from the issuance of this RFP, and it is expected that these will be accessible from the Vermont Judiciary website. For similar functionality, bidders are encouraged to view the Idaho Judiciary website. (Note: to try an A2J form on the Idaho Family Law site, choose a form with a “blue i in a circle”, go to form, when you reach a form the “A2J” will appear in the top left corner: )
Technical Notes
The following is a high-level graphic of the expected A2J - VCase architecture:
[pic]
During the rollout described in Chapter 7, the output of the A2J Author software will go into the case management system as it is implemented in the appropriate court and county. The following are the architecture assumptions as shown in the diagram above (starting lower left of diagram):
1. A pro-se user may find an appropriate form on the VCase Web Portal (similar to the Idaho Family Law page referenced above).
2. Once the user has found the appropriate form, they follow the A2J Guided Interview prompts (again, as in the samples you may try on the Idaho Family Law page). Assume: the Vermont Judiciary will complete the required scripts and the Interview pages will be defined on the A2J website for you.
a. Note: The dotted circle in the diagram represents the “front end” A2J software. In the nomenclature of the OASIS ECF technical e-filing standard the A2J front-end acts like a Filing Assembly MDE. Assume: the Judiciary will not take ownership of the A2J Guided Interview software (it will stay housed on their webserver and our portal will merely point to the appropriate forms), and there will be no cost associated with A2J software, since the A2J front-end software is built via grants that allow Courts to use it for free.
3. When the user has completed their “interview” (i.e., all questions for the form are answered), and the user clicks the button to signal they are done, the A2J Interview webpage will send the captured response data in XML format to a server of our choosing, called the VCase XML Server in the diagram above. You must propose level of effort and deliverables to assist the Judiciary in building and testing this server.
a. Note that this is where we deviate from the standard A2J “backend”. In the standard A2J configuration, the XML is sent to the NPADO server, where HotDocs is activated, the XML data is merged into a form template, and the completed form image is sent back to the user to save or print. The NPADO server then deletes the XML file due to security concerns. A diagram of the A2J software and the NPADO server relationship can be found at:
4. Currently, the XML file generated by A2J is in “HotDocs XML format” – a .anx file. However, in the future, A2J may be able to generate other XML standards following industry standards such as OASIS Legal ECF 4.0. Assume: the XML file of interview data may be HotDocs .anx format or Legal ECF format.
5. After A2J sends the XML file of interview responses to the VCase XML Server, a program (e.g., a Unix daemon type routine?) would see that the new file has arrived. This program is represented above as a triangle called “New File?”. You must propose to build, document, and test this program/routine.
6. Besides knowing that a new XML file exists, this New File? routine must perform or call several other functions or programs. You must propose to build, document, test the following routines and processes. The New File program must be able to:
a. Call a routine that will merge the XML into a form template and create a .pdf of the completed form. This routine is a box in the chart above labeled “Merge in XML – Create pdf Form”. (In the standard A2J configuration, this routine would be HotDocs running on the NPADO server.) For VCase, you may propose HotDocs, Ghostfil, Adobe, or another such utility to perform this merge and pdf creation process. However, if you do not propose HotDocs, you will have to propose tasks, deliverables, and level of effort estimates for doing the appropriate transforms from a HotDocs version XML into a format that your proposed utility can process. Once this utility has created a completed .pdf file, it must be able to do two things:
i. Store the pdf into the VCase DMS so that it can be viewed by court staff (e.g., see description of “the Door” below) and later be tied to an event in the CMS; and,
ii. Send a copy of the .pdf back to the user (you can propose method) so that the user can print and/or save the .pdf of the form they just completed.
b. Send a “message” to the CMS workflow engine, so that a note about the existence of the new file will show up on an appropriate staff work queue. The work queue must alert the appropriate court/staff person that will process the XML/form, and the message must supply enough information for the court staff to look up the image of the form in the VCase DMS. The program to compose and insert this message is labeled “Alert into Workflow” in the diagram above.
c. Have the capability to forward the XML file into the Interfaces Engine after the court review approves the document via “the Door” process defined below. The Interfaces Engine (assume the standard interfaces capability as defined for Chapter 8) is represented in the diagram as “Insert XML into CMS via Interfaces Engine”.
d. Call a program/process to collect a filing fee through the web. VCase must be able to initiate an electronic case opening and accept a filing fee, as well as to accept an electronic motion to proceed in forma pauperis with accompanying financial information, with filing subject to a decision from the court. A2J does not have a method to collect money. In the diagram above, the box that is part of the Portal, “VCase Collect Filing Fee Web Pages” is a place holder for filing fee collection. Assume that the New File? process will know which types of forms require a filing fee, and that when the user clicks “done” in A2J, VCase can then supply the next form(s) required to prompt for the appropriate filing fees. You will be required to provide this functionality (as collecting filing fees will be required for any type of e-filing manager, not just A2J).
7. Once a work queue alert is placed into the CMS work flow for the appropriate staff member, that staff member will know that the pro-se user completed a form using A2J. The staff member will want to look at the form, check for the existence of basic information (e.g., a case number if applicable), and then submit the form into the CMS. This review and submission process is called “the Door” in the diamond in the diagram; in OASIS ECF nomenclature this is called the Filing Review MDE. For this RFP, you must assume that the pro-se user will not be required to bring the completed/printed form to the court to begin and/or continue with the processing of the case. As mentioned above, the staff member, based on information in the work queue (supplied by the “message”), will use the VCase DMS to look up the completed image of the form. You must bid the capability to review a filing and allow the court staff to forward the XML to the standard interfaces engine to update the CMS or reject the XML and send an email message back to the pro-se user with comments and a copy of the pdf.
a. Note: The court will rarely reject the form. If it does, you may assume that the user will start again with entry into A2J, since A2J does not save the XML from the original form.
b. If the form is rejected, and the user submits another form (another XML file comes from A2J) for the same case, you must propose a way to mark the version of the form image in the DMS and ensure that only the accepted version of the form gets attached to the appropriate event.
Your Response
Your response to this section must include your methodology, tasks, milestones, deliverables, timeline, proposed staffing, and assumptions for gathering requirements, installing, configuring and/or constructing those required technical components to integrate the A2J e-filing manager as defined above. This plan must also include testing, documenting, and preparing training materials for using the A2J Author processes.
Your response to Chapter 7 will include your effort, tasks, deliverables, staffing, timeline estimates, and assumptions for training the court staff in how to process forms completed via A2J, as well as participating in up to three public training sessions for proper use of the A2J in Vermont. Extra consideration will be given to those proposals that include ongoing training plans that minimize staffing, such as including the development of online computer based or video training (especially aimed at helping non-court staff use the system without having to contact the court.)
5 Checklist for Responding to this Chapter
Your response to this Chapter must include, at a minimum, the sections listed below. Please provide a complete response, but be as concise as reasonably possible. Your responses must be clearly labeled to correspond to the chapter section and subsection numbers listed above where stated, and be presented in the order listed below. You may add additional information after the last section listed. If you object or disagree with any requirement listed above, please note this in your Exceptions chapter.
1. You may reply with any assumptions/alternate approaches to section 5.2.
2. Answer each of the questions presented above in the order presented in 5.3
3. Complete your proposal to each of the four e-filing initiatives as stated above in the sections of 5.4 entitled “Your Response”. Respond to each initiative separately. You must bid Costs in response to Chapter 12, Cost Item #30.
4. Explain why your approach is the best choice for VT.
Initial System Configuration and Construction.
1 Introduction
The purpose of this chapter is to:
• Define what we mean by “initial system configuration and construction” and outline our thoughts about what we expect will happen during this time period;
• Allow you to explain your approach to this topic; and,
• Allow you to describe your proposed activity areas, tasks, deliverables, staffing, and level of effort to accomplish the initial system configuration and construction.
2 What do we mean by Initial System Configuration and Construction?
Initial system configuration and construction are all those activities that take place between contract signing and the start of the first production rollout of VCase into a court. In traditional project management methodologies, this includes project planning and management, requirements analysis and definition, design and setup, construction, and testing. In this RFP chapter, initial system configuration and construct includes specific activities for the new CMS/DMS such as:
• “As Is” vs. “To Be” analysis, including such areas as JAD sessions and iterative prototyping, with the end result including a gap analysis document and an updated project plan;
• Functional testing of the system installation, functional training on subjects ranging from database design to programming language and software tools training, review of baseline user documentation; helpdesk design and setup;
• Power-user system administration training to learn how to configure your system, working with your many reference tables and potential tools to workflow and business rules, merge templates, queries, reports, etc;
• Defining and supporting the decisions required for policy changes;
• Change management in the sense of helping to get the courts ready for the new system and get them involved in the process;
• Project management activities not only include updated project and staffing plans, but also including such plans for testing, communications, rollout, etc.
• Implementing any programming changes necessary in the base CMS/DMS systems (“construction”);
• Design and test necessary reports, merge templates, DMS and e-filing interfaces.
The Judiciary believes that, using the LifecycleStep methodology, one reasonable approach to the VCase project may be a merger of the “Package Selection and Implementation” plan (LifecycleStep section 465.0) and the “Iterative Development Lifecycle” plan (LifecycleStep section 462.0). One reason is that the normal assumption for a “Package” selection is that the operational requirements are well documented, the package is already coded to accomplish most necessary functions, and the vendor selection is based on “picking a package that comes closest to meeting the customer operational requirements out of the box”. We encourage your response to be based on the TenStep and LifecycleStep methodology. If your response to this subsection significantly deviates from the activities outlined in the LifecycleStep methodology found in LifecycleStep sections 462 and 465, you must clearly explain how and why.
It is clear from this RFP that “pick a package, make some modifications, and implement” is not our approach. We don’t believe this is the current state of the courts case management system industry. Based on our “framework” approach, which we have seen in virtually all the new thin-client systems, we are assuming that there will be a significant effort in the beginning of the project to analyze and configure the operational requirements for the system, either via rules and workflow engine languages, drag-and-drop interfaces, coding user exits, and/or extensive system configuration table screens. Also because of the flexible framework approach, we assume there will be more up-front configuration that is critical to the long-term success of the system, with more emphasis on configuration than one traditionally has expected in a “package” based implementation.
We believe one reasonable approach to configuration and construction is to use your framework with an iterative approach to requirements definition, prototyping, and configuration, while at the same time, including many of the more “traditional” deliverables found in any package-based implementation (e.g., a gap analysis document laying out options for coding changes that may be needed/desired to the delivered software.)
3 Your Approach to Initial System Design and Configuration
Your response to the Project Management chapter includes a master project plan of all the major activities you propose to successfully implement VCase. Your response to this subsection allows you to explain in more detail your approach to accomplishing the work outlined in your Project Plan for “configuration” and “construction”.
You must include a detailed project plan in this subsection providing your requirements-related, configuration, and testing related task, staffing, and timing estimates by court. For example, if you expect to take three months to analyze the operational requirements of District Court, you must include estimates of how many working sessions and type (e.g., JAD, other type), timing, staffing needed (yours and ours), assumptions, and resulting deliverable(s) for that court. Your chart must break down requirements, configuration, and testing tasks by the six courts affected by the “19 database” rollout described in Chapter 7: District, Family, Superior, Supreme, Judicial Bureau, and Environmental.
The completion and Judiciary acceptance of a “gap” analysis and updated project plan to complete configuration and construction for all courts, including a comprehensive Requirements Traceability Matrix for use by the project management, must be included in your plan and be a Milestone that will be reflected in your Costs in Chapter 12. We realize that some tasks (e.g., making a construction/programming modification to the system that will be used in several courts) need not be broken by court (and, for costing, can be estimated as a container of hours).
You must provide an “Initial System Configuration and Construction Project Plan” and narrative that is more detailed than the Master Plan presented in Chapter 3, Project Management. This detailed plan will describe how long you estimate all the activities and tasks proposed in this chapter will take, how many simultaneous teams of what staff will be required, what deliverables and milestone we can expect, by timeframe. You also must explain your assumptions and any concerns about risk.
Please accompany your approach with “lessons learned” from other courts when possible. For example, if you designed and configured your thin-client system in another criminal or family court about our size, list the staffing, deliverables, and the process assumptions that were successful in that court and compare them to Vermont. If you have no experience implementing your thin-client system with the approach you outline, then explain how you intend to mitigate VT’s risk in being the first rollout with this approach. Your clear, well presented, lowest-possible-risk methodology presented in this chapter will be crucial to a successful response to this RFP.
4 Initial Configuration Objectives
As outlined in Chapter 1, the vendor will be expected to provide a CMS/DMS framework that can be configured to meet the needs of each of the six listed courts. Note that the focus of this chapter is CMS/DMS; Chapter 5 focuses on the configuration/construction of E-Filing, Chapter 10 on Architecture, etc.
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. The Judiciary expects that our combined business analyst teams will 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).
During the initial configuration of the CMS/DMS software, VT has two objectives.
1. First, VT must assist and guide the vendor to enable the vendor to configure the system to meet VT’s needs.
2. Second, VT’s staff must obtain the necessary skills to configure the system indefinitely.
Our teams must work together to configure all functionality that you list in response to Chapter 4 and marked as “included” in the Core Capabilities Chart (Attachment 6). In evaluating the level of configuration and construction effort, consider Attachment 16, Court Activities Reports, which were assembled from information provided by court managers. The Court Activities Reports are not a complete list of activities in the trial courts, but they do describe most activities. The Court Activities Reports may help you better understand the scope of required functionality for VCase.
5 Parameters for Configuration
During VT’s market research, we learned that each vendor has its own approach to configuring a system. In general, court case management products have many tables that must be configured. Some systems have extensive settings to be made through checkboxes and field entries. Some systems use graphical rules interfaces and stand alone logic statements to define rules. The available products have many similarities and many differences. VT needs to know the capabilities of your system that facilitate flexible system-administration level configuration:
Please respond to the following:
a. What are the most significant 10 tables that must be configured? Describe the purpose of each table and the purpose of each field in each table. This question is limited to 10 tables because some vendors have confidentially concerns. You may describe more tables if you wish.
b. How many different tables must be configured for the system to function correctly?
c. How many different tables are included in the system, including required tables and optional tables?
d. Can VT add a field to each table without customizing the software? Please explain.
e. Other than configuring tables, what is required to configure your system for each case-type?
f. Please estimate how many person-hours it will take you to configure one case-type? How many person-hours will it take VT to configure a new case type in future years as part of maintaining the system consistent with statutory changes?
g. Do you have a list of questions for VT to answer to facilitate defining the configuration for each case-type? If so, please attach list.
6 Sequencing the Configuration and Construction Activities
Once the completion of the as-is/to-be/gap analysis and updated project plan are finished, the sequence of configuration and construction closely relates to the sequence and timing of installation in the courts, called “rollout” in this RFP and described later in Chapter 7. As described in more detail in Chapter 7, VT intends to install the system in a manner that facilitates shutting down one complete VTADS database at a time. This is important because VT has limited IT and Business Analysis staff. Each time a VTADS database is shut down, more resources can be directed to VCase. If only a portion of VTADS database is shut down, VT would still have to maintain the database, which would undermine the goal of directing resources to the new system. In addition, the users in a county would have to be flipping back and forth between the old and new systems because often the same staff in a county work in more than one court.
Most of the 19 legacy databases contain VTADS clones for the District, Family, and Superior Courts, which means that all three courts must be configured prior to the first rollout of any court in any county. On the other hand, the Judicial Bureau, Environmental Court, and Supreme Court each have standalone databases so, technically, each may be configured without regard to the schedule for installation of VCase in any other court.
VT intends to complete the rollout of VCase, as described in Chapter 7, in the following order within 36 months of signing a contract:
• First: District, Family, and Superior Court in each county, moving from one county to the next until all 14 counties are using the new system.
• Second: Judicial Bureau
• Third: Environmental Court
• Fourth: Supreme Court
Your proposal should clearly indicate whether these courts will be configured in series or parallel. With the 36 month timeline, it is likely that the District, Family, and Superior Courts will have to be configured simultaneous. Then, while these courts are being rolled out database by database, the Judicial Bureau, Environmental Court, and Supreme Court may be configured provided we have planned for enough staff.
Again, VT expects all installations will be completed within 36 months of contract signing. You will note in the “RFP Map” presented at the end of Chapter 1 that the estimated date for “Ready for First Rollout” was left as TBD. This will be a critical Milestone for you to present both in your Master Project Plan, as well as a Milestone in the detailed plan in response to this chapter. Whether this Milestone assumes all courts are configured (and then all courts will be rolled out sequentially), or only the District/Family/Superior courts are configured (and the team “splits” to rollout vs. configure the remaining courts), will depend on your assumptions and your courts rollout expertise. In addition, it will depend on your timeframe and staffing assumptions. If possible, you may wish to provide your assumptions with both plans for our review. We are confident that “Ready for First Rollout” will be a critical Milestone for the VCase project.
VT likely will commit a relatively small number of full-time “core” staff to the configuration process. Additionally, many field staff (docket clerks, managers, and judges) will assist and guide the core staff throughout the configuration process. Each core staff person likely will have a role in configuring each court or at least will be kept in the loop for all courts, while field staff likely will be involved in configuring only one court. The important point here is that each court may have a different cast of players interacting with the vendor.
You should expect that the six courts will have six different configuration teams. This creates additional challenges in helping people become familiar with the configuration process and in communicating during the configuration process.
Please respond to the following:
a. Do you intend to perform the “as is, to be” gap analysis, define the configuration, and configure the system for the District, Family, and Superior Courts simultaneously or in series? If simultaneously, is it reasonable for VT to have core staff members with shared responsibility for all courts, or should there be sufficient core staff so that no one person has responsibility for more than one court at a time? If in series, in what order?
b. When will you perform analyze, define, and configure the Judicial Bureau, Environmental Court, and Supreme Court?
c. How long will it take and how much labor is involved in analyzing, defining, and configuring each court?
d. What additional challenges are created by VT having a different configuration team for each of the six courts and how will you handle those challenges? Will you have one team working to define and configure all courts or separate teams for each court?
e. How will your staff and VT’s staff communicate with each other?
7 Checklist for Responding to this Chapter
Your response to this Chapter must include, at a minimum, the sections listed below. Please provide a complete response, but be as concise as reasonably possible. Your responses must be clearly labeled to correspond to the chapter section and subsection numbers listed above where stated, and be presented in the order listed below. You may add additional information after the last section listed. If you object or disagree with any requirement listed above, please note this in your Exceptions chapter.
1. Chapter specific project plan: (Ch 12 Cost Item # 40, Summary Cost by FY) Provide your Configure and Construction project plan including clear staffing assumptions for analysis, configuration, construction, training, testing and documenation. Be clear how the “sequencing” tradeoffs described in 6.6 affect your proposal.
a. The requirements for your proposed milestones, tasks, and deliverables in response to this chapter are designed to correspond to those listed in the LifecycleStep “Package Implementation” Plan for: ANALYSIS, DESIGN, CONSTRUCT, and TEST. Your plan must address the tasks listed in each of these components of the Package Implementation LifecycleStep plan. You may propose alternate methodologies (e.g., an iterative design approach) where you believe alternatives will be beneficial (e.g., lower timeframe, more efficient, less cost, less risk). You must be clear to specify which sets of Lifecycle tasks you propose to replace, how, and why.
b. Reminder: This chapter applies to your “baseline system proposal” for the analysis and construction of six courts: district, family, superior, supreme, environmental, and judicial bureau.
c. Cost Item #41 – Analysis/Design Breakout: From your overall plan, Chapter 12 Cost Item #41 requires you to complete the cost breakout by FY for the tasks/effort proposed to the ANALYSIS AND DESIGN (CONFIGURATION as defined in this chapter).
d. Cost Item #42 – Construct Breakout: From your overall plan, Chapter 12 Cost Item #42 requires you to complete the cost breakout by FY for the tasks/effort proposed to the CONSTRUCT as defined in this chapter).
e. Cost Item #43 – Test Breakout: From your overall plan, Chapter 12 Cost Item #43 requires you to complete the cost breakout by FY for the tasks/effort proposed to the TEST, which includes documentation and training preparation, as defined in this chapter).
2. By Court Plan Breakout – Break out your methodology, deliverables, activities, staffing, timeline, assumptions – BY COURT as defined above – for how you propose that we accomplish the mainly court specific tasks, especially “as is, to be” requirements analysis, gap analysis, any court-specific system configuration activities, court-level User Acceptance testing, documentation, and training preparation. We will assume that “construction” activities, which would involve programming modifications to your system, will be cross-court.
3. Reports and Form Letter Construction: -- (Ch. 12, Cost Item #45) Part of the goal within Chapter 6, Configuration and Construction, will be a review, with VT, of the stock reports and merge documents that come with the proposed system. As a result of this analysis the vendor would define what reports and/or merge documents must be created or changed as part of construction. Explain your methodology, activities, staffing, and assumptions for report (may be printed or online queries) and form letter (e.g., “mail merge”) review, development, design and construction.
Chapter 4 (Section 4.4, Checklist for Responding to this Chapter, numbers 3 and 4) requires you to provide a list of stock reports and stock merge documents for our review. Since the extent of the changes required to the stock reports/merge documents is unknown until the configuration and construction phase, you must provide the cost of 6000 man-hours in Ch. 12 Cost Item #45 (along with your breakdown of rate by staff category). Provide the costs as part of the first fiscal year although VT reserves the right to utilize these hours over the entire contract. These hours will be used to create new reports and merge documents as well as change stock reports and merge documents to meet specifications identified in Configuration and Construction or Rollout, and will be tracked by the contractor as part of the project management process. It will be the option of the Judiciary to select which reports and merge forms are completed and to work with the vendor to allocate the hours and costs appropriately over the life of the contract.
These hours do not include the process of identifying the report and merge document changes as that should be covered as part of the as-is, to-be, gap analysis. These hours also do not cover the CourTools Reports (Core Requirements Chart #114) or NCSC Statistical Reports (Core Requirements Chart #115). The costs for these reports are assumed to be part of the base software license.
4. Propose what your approach to making any necessary coding modifications (“construction”) to your package.
5. Describe in detail your User Acceptance Testing methodology.
6. Explain why your approach is the best choice for VT
Production System Rollout and Training
1 Introduction
The purpose of this chapter is to:
• Define what we mean by “production system rollout” and outline our thoughts about what we expect will happen during this time period;
• Allow you to explain your approach to this rollout; and,
• Allow you to describe your proposed activity areas, tasks, deliverables, staffing, and level of effort to accomplish the production system rollout of VCase.
2 What do we mean by Production System Rollout and Training?
Production System Rollout and Training begins when User Acceptance Test is completed and the team is ready to roll out VCase into the first court(s). Production System Rollout and Training ends when the Judiciary accepts that all courts (listed below in 7.2.1) are in production on VCase, and the project is ready to enter the Post-Implementation Support phase.
It is important to note that the approach discussed in this chapter is based on experience, on talking with other states, and the IMPLEMENTATION section of the LifecycleStep “Package Implementation” project plan. You must present a methodology that addresses all of the activities and deliverables included in the LifecycleStep plan. You may propose an alternate methodology, or alternate tasks, but you must relate what you propose to the Lifecycle plan and explain why your plan is more efficient, less risk, and/or less cost.
In the past when we have asked vendors for their advice on rollout strategy the general answer has been “however you feel comfortable”. We asked this question in our last RFP and got virtually no response to it. Therefore, in the past several months, we have contacted about twenty other state court systems to talk to them about their case management system projects. From this we gained much insight into the generally recommended rollout approaches.
Based on what we have learned, we recommend a “database” oriented rollout strategy in this chapter. Chapter 6, in section 6.6, provided an overview of this strategy and some considerations of how VCase may be configured and then rolled out. You must provide a proposed rollout strategy that takes into consideration the “19 database” structure we have outlined below.
In this RFP, the term “rollout” means the combination of tasks needed to put the VCase baseline system into production, including: production conversion (Chapter 9), implementing interfaces and exchanges (Chapter 8), training court staff (prep is described in Chapter 6), covering court operations during training, production operation of the new CMS/DMS solution, implementing the new software and procedures for the four e-filing initiatives (Chapter 5), and support of court staff after the new system begins. Your project plan, milestones, staffing, tasks, and assumptions in response to this chapter must address each of these areas.
1 List of the 19 Databases
The next two sections provide information on the number of, and relative sizes of, the courts, the court locations, and the volume of each database. The chart below provides a list of the 19 databases that are the core of the rollout strategy.
|Courts Statewide (14 |Court Type |Number of Venues |System Name |Databases for Rollout |
|counties in VT) | | | | |
|1 in each county |District Court (criminal) |14 |VTADS2 |14 |
|1 in each county |Family Court (including |14 |VTADS2 |(included above) |
| |juvenile) | | | |
|1 in each county |Superior (civil) |11 |VTADS2 |(included above) |
| | |(2 counties, | | |
| | |Chittenden and | | |
| | |Franklin, will not | | |
| | |be included; | | |
| | |Washington listed | | |
| | |below) | | |
|Washington county only |Superior (civil) |1 |A separate VTADS2 |1 |
| | | |superior database from | |
| | | |district/family | |
|1 statewide |Supreme Court |1 |VTADS1 |1 |
|1 statewide |Environmental |1 |VTEC |1 |
|1 statewide |Judicial Bureau (“Traffic” |1 |Traffic, and Municipal |2 |
| |and other) | |Ordinance | |
|18 (4 counties have 2) |Probate Courts |18 |None |(See Ch 13, Phase 2) |
|TOTAL | |61 | |19 databases |
2 Court Statistics by Database
In order to gauge the relative sizes of each database, we have provided below a chart that lists:
• The number of staff using each database by court type. Staffing numbers are estimates in round numbers in terms of full-time employees. These numbers do not include all of the people that use VTADS, such as judges, CAO staff, etc. Total estimated staff of VTADS users to be trained in VCase is approximately 400 – 450 people. The numbers below may change, and are solely meant to give you a feel for the relative size of the full-time staffing (“FTE”) using each database. Note that breakdown numbers by court may not add up to the Total because some staff is double counted if they support multiple courts.
• The number of Cases Added in each database for the 12 months ending 6/30/2007.
You can see more statistical information, including breakdowns by court by docket types, by going to our website at:
Court Staffing and Cases Added Estimates (** = statewide court database)
|Database |Total Staff FTE |District |Family |Superior |
| |(using VTADS, not | | | |
| |incl judges) | | | |
|1.a |Web Server |Quad-Core Xeon Processor |Window Server 2003 Standard |EX |
| | |16GB RAM |IIS Web Server | |
| | |2x160GB Disk Space | | |
|1.a |Database Server - |Quad-Core 3G Xeon Processor |Window Server 2003 Standard |EX |
| |Production |32GB RAM |Oracle Enterprise Edition | |
| | |2x72GB Disk Space – O/S | | |
| | |500GB Disk Space - Storage | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
3 Checklist for Responding to this Chapter
Your response to this Chapter must include, at a minimum, the sections listed below. Please provide a complete response, but be as concise as reasonably possible. Your responses must be clearly labeled to correspond to the chapter section and subsection numbers listed above where stated, and be presented in the order listed below. You may add additional information after the last section listed. If you object or disagree with any requirement listed above, please note this in your Exceptions chapter.
1. Answer each of the questions presented above in Section 10.3.
2. Include your detailed Architecture Plan: approach/methodology, task plan, staffing, timeline, and assumptions for installation, test, implementation, documentation, technical training and support of the proposed system as defined above in Section 10.5.
3. Include a detailed architecture list as specified in Section 10.6.
4. Include a sample of your system administration documentation (that corresponds to your thin-client application) and your logical data model (10.3.9 d).
5. Specify, in Chapter 12, Costs, Cost Item #80, costs for deliverables and effort proposed in response to section 10.5. Do not specify hardware costs in response to Chapter 12.
6. Specify, in Chapter 12, Costs, Cost Item #85, the 8 year costs of every software package you propose. Include in your response to this chapter (Chapter 10), the following chart to explain what the dollar number is in each equivalent cell in Chapter 12. Be sure to make clear the difference between new and maintenance licenses. Be sure to include the algorithm you use for figuring longer term costs (e.g., 15% of original purchase price each year, with 2% increase each year after 3rd maintenance year.)
|# | |Cost Item |FY2010 |FY2011 |FY2012 |FY2013 … |
| | | | | | |FY2017 (each must be a |
| | | | | | |separate column) |
|85 |Ch 10 |Software Licenses | | | | |
|85.1 |Ch 10 |VCase CMS License |New, 50 user |New 150 users |New, Upgrade to |Maintenance (costs out each|
| | | | | |Enterprise Version |fy, include estimated |
| | | | | | |algorithm for figuring |
| | | | | | |costs) |
|85.2 |Ch 10 |VCase report writer, Software X, |New, unlimited |Maintenance (with |Maintenance |etc |
| | |vendor, Version x.2 |users |algorithm) | | |
Post Implementation Support
1 Introduction
This chapter asks you to describe how you propose to support VCase for the longer term after the completion of Rollout as described in Chapter 7. Post implementation support includes user and technical helpdesk communication, technical support, user conferences, continuing system education, software update schedules, and so forth.
2 Approach to Post Implementation Support
Your response to this chapter must present your methodology for long term VCase system user and technical support. The answers to many of the questions below may vary, depending on if you are going to support your entire solution, or if you have partnered with other firms and propose a solution based on the integration of several packages. If you have proposed several packages, you must answer each question below (where applicable) for each vendor/vendor package.
1. Provide an overview of your offerings and policies for post-implementation support.
a. What is your standard level of support option (e.g., Mon – Friday, 9 – 9)? Explain what is included. What are the other levels of support available? Note: If you have additional cost “premium support” options, you must indicate the cost of each as an Option in Chapter 12, Costs.
b. Are annual legislative changes included in the base proposed maintenance plan? If so, how do you cost these (by the hour, a set of hours?)
c. What services can you provide if we need additional consulting? For example, if a user needs a special reports and our programmer cannot figure out how to program the report, what services do you offer to help? (Note, again, if programming type help is an option, please bid a cost as an Optional cost.)
2. The proposed system must have a defined upgrade path, maintenance and support structure. Explain the following:
a. How are the application upgrades supplied? How often? What is included with published major and minor updates?
b. What level of effort is required and expected to upgrade the proposed system? (Please identify each piece if proposing a series of separate products.)
3. What methodology is used to test specific user environments before rolling out updates?
4. What effect does local customization have on system upgrades?
5. What are your policies for the following:
a. Fixing reported errors? Explain.
b. Bug escalation policies? Explain.
6. How is your Helpdesk structured? Do you have a separate support team for application questions versus technical issues?
7. What are your suggested support strategies for Vermont? For example, do you propose that we have a central first-line helpdesk? What type of helpdesk staffing requirements do you recommend that we need to support users (aside from technical staff support).
8. Will there be ONE place for our helpdesk to call for support on all application components of your solution? If not, how many helpdesks will we have to contact (for example, if there is a different support structure for the DMS than for the CMS)?
9. If you are proposing the combination of multiple vendor application systems, and you do not propose to handle the support for all applications, how will you handle an issue where is it not clear what part of the application is having a problem?
10. Do you have a User Group? If so, how often does it meet? What other Judiciary’s are members? Have you attached the agenda and/or minutes of the last meeting to your response?
11. How do you collect update/new feature requests from clients? How do you prioritize these requests? Do you publish the list of update requests and keep the list updated with progress on when you will/will not implement each request?
12. What types of ongoing end user training to you provide? If you provide training classes, where are these classes held? How often? About how much do they cost? Do you offer computer based or online training materials (e.g, CBT downloads, “web-ex” type online demos, etc)?
13. Do you have an online knowledgebase of FAQ about your solution? What other types of user training material do you have for free download on your website?
3 Checklist for Responding to this Chapter
Your response to this Chapter must include, at a minimum, the sections listed below. Please provide a complete response, but be as concise as reasonably possible. Your responses must be clearly labeled to correspond to the chapter section and subsection numbers listed above where stated, and be presented in the order listed below. You may add additional information after the last section listed. If you object or disagree with any requirement listed above, please note this in your Exceptions chapter.
1. Your response must address each question listed above in 11.2.
2. Baseline post-implementation support costs must be bid in Chapter 12, Costs, Cost Item 90 (out through FY2017). Optional costs must be bid as Options and clearly explained in response to this chapter.
3. You may include additional information on post implementation support that you believe will be beneficial to the Judiciary in evaluating your proposal.
Costs
1 Introduction
It is standard State purchasing practice to ask vendors to separate their “technical” proposal from their “cost” proposal. Your response to Chapter 12, Costs, must be separate from your response to the rest of this RFP. Chapter 12 provides a spreadsheet format where you will provide your fixed price and optional rates that correspond to the various deliverables and levels of effort you have proposed in response to the other chapters of this RFP.
Your response to this RFP must assume a “baseline bid”. As you prepare your plans and assumptions in response to this RFP assume:
• The “baseline” strategy, required milestones, deliverables, timelines, staffing, and assumptions that correspond to the “baseline” fixed price bid below. The Judiciary requires that, unless otherwise labeled as an Option, the baseline approach you propose in your response to this RFP is your optimal, most cost-effective, and risk-averse solution. All of the proposed system functionality must be able to be demonstrated to us should you be chosen as a Vendor Finalist. You must supply a consolidated list of those portions of your proposal that are not likely to be completed by October 1, 2008 and might not be available for demonstration to the Judiciary in the stated Vendor Finalist demonstration period; and,
• Optional or alternate approaches to the baseline bid must be clearly labeled (in your RFP technical response) and bid separately below. In your technical proposal you must give each option a “name” (e.g., Conversion Option 1, Rollout Option 1A, etc), and be sure options are clearly delineated, and costs for these options are labeled as such in response to this Costs chapter. We have required you to respond to some Options, which are listed later in this chapter, and you may add other Options. If you propose Options, you must indicate not only your expected cost of the option, but also include an estimate of how much choosing the Option may raise or lower the overall baseline fixed cost of the system.
Your baseline and optional costs specified in this chapter must be all-inclusive. You may assume the Judiciary will provide conference rooms, desk space, and access to a telephone and a printer for your onsite staff. The Judiciary will not supply computers or copies of productivity and development software (e.g., Microsoft Office, MS Visual Studio) to your staff.
Cost is an important factor in evaluating proposals. However, the VT Judiciary does not have a fixed budget for this project. The VT Judiciary has received and continues to receive a stream of funding through an initial legislative appropriation, a court technology fund, and various grant opportunities. Our project budget includes costs for the amount of the successful bid, plus hardware, Judiciary staffing, etc.
The concepts of “framework” and “configuration” are reiterated throughout this document. The court CMS/DMS industry clearly is moving toward a new breed of highly configurable frameworks. The framework approach provides an important opportunity for courts to gain greater control over the development of the product upon installation and thereafter. The framework approach also injects two additional considerations related to cost.
The first consideration pertains to risk. Since court CMS/DMS frameworks are new, the VT Judiciary will, to some extent, become a pioneer for this technology. The VT Judiciary encourages vendors to value its participation in this regard and price their bids accordingly.
The second consideration pertains to shifting the work. In the past, vendors have proposed “off the shelf” products with custom software modifications to meet the customer’s needs. In a framework, these modifications largely should be replaced by configuration. Thus, the framework approach creates an opportunity for the vendor and customer to agree to shift configuration work to the customer. The VT Judiciary encourages vendors to help it reduce costs and become more self-sufficient in maintaining its CMS/DMS by performing much of the configuration work. Of course, the successful vendor must train VT’s business analysts to perform this work.
The Judiciary will give strongest consideration to bids in the range of $5 to $7 million. Bids exceeding $8 million are discouraged and likely will not be selected. A vendor may improve its chances of selection by offering thoughtful suggestions to help the VT Judiciary reduce project costs.
2 Cost Spreadsheet Assumptions Grids
Every cost you present must be accompanied by a very brief explanation what that cost number represents, and a reference back to the section(s) of your technical response that represent the plans, milestones, activities, deliverables, staffing, and assumptions that are represented by that cost. This section provides a format for connecting the costs presented in the next section below with your technical response.
Baseline Fixed Cost Spreadsheet Assumptions
|Item # |For FY |This cost represents… |RFP Reference(s) – |Proposal Reference(s) -|Vendor Notes |
| | | |optional |required | |
| | | | | | |
| | | | | | |
| | | | | | |
Optional Cost Spreadsheet Assumptions
|Option # |This cost represents… |RFP Reference(s) - |Proposal Reference(s) -|Vendor Notes |
| | |optional |required | |
| | | | | |
| | | | | |
| | | | | |
3 Cost Spreadsheet Grids
The following grid format must be used to present your baseline VCase system fixed cost bid, and the costs associated with Options.
Costs must be split out across fiscal years (July 1 – June 30). Assume the project will start work on July 1, 2009 – which is the start of state FY2010. Assume the work that you are costing for this RFP will end by June 30, 2012 – the end of FY2012. Because Post Implementation Support (referenced in Chapters 10 and 11) will extend past the onsite work, the costs must be shown for eight fiscal years – FY2010 – FY2017.
Where activities may span multiple fiscal years – e.g., Project Management, Production System Rollout and Training, Architecture and Support, Post-Implementation Support – you must calculate costs for the activity, estimate how much of the activity you plan to accomplish within a fiscal year, and then allocate the costs accordingly. You must state your cost allocation assumptions so that we clearly understand how you have calculated and spread out the costs.
You are to bid to include all proposed activities, deliverables, and staffing except those in Chapter 13. You are not to bid any costs for the effort described in Ch 13, Phase 2 E-Filing and Probate. Your response to Ch 13 is your overview approach to addressing those tasks and we expect to refine plans and cost estimates later in the project and address this work in future contract extensions.
You are strongly discouraged from bidding a large “up front” loaded cost in the first year for an enterprise license to your solution. We believe it will be some time after contract signing before we have a significant number of users on your system, and therefore we do not wish to pay for a full license until we have a substantial number of users actually using your system. In addition, due to our continually funded “tech fund” approach, we will have to fund the project over time. If you object to this approach you must clearly outline your objections in your Exceptions chapter.
You are strongly encouraged to propose a plan and assumptions that will help spread out the costs over the 36 months of effort (except, of course, for the ongoing post-implementation support).
If you choose to bid a cost that represents a “set of hours” in response to a milestone or deliverable, you must be clear about how many hours and what the number of hours represents in your corresponding “Assumptions Table” entry (as defined in the section above). If your assumptions under a cost are proprietary, you may separate those assumptions out to a separate page marked Proprietary and Confidential.
The baseline cost grid below can be submitted either as a Word chart or an Excel spreadsheet (Excel 2003 is preferable). Besides including this spreadsheet as part of your printed Cost Proposal, you are also required to submit the baseline and optional cost spreadsheets as individual files in your electronic submission.
Columns are as follows:
• #: This is our Cost Item number. You must include it in your Cost spreadsheet to identify those mandatory cost items we specified. You may add additional numbers if you break down our items into a finer level of detail. For example, we have “Initial Configuration and Construction” as # 40. You may break this into something like “#40A – Analysis of District Court as-is”, “#40B – Analysis of Family Court as-is”, etc. In short, you may use our Cost Items as “headers” if you choose to further break down costs within an Item.
• Project Plan WBS or Milestone Number: the Work Breakdown Structure or Milestone Number you have assigned to this cost item in your technical proposal. This may also be a Deliverable Number if you wish. Your Cost response may break down costs to a finer level of detail than shown here if you wish. The items listed below are the minimal mandatory cost items for your response.
o As presented below, we have specified what we believe is the corresponding chapter in the RFP where we speak to the requirements of this Cost Item. We include references to specific Cost Item numbers, where applicable, in the sections of each chapter entitled “Checklist for Responding to this Chapter”. You must change our chapter references below to correspond to your “Tab” chapters and your project plan WBS, Deliverable, and/or Milestone numbers.
o We encourage you to break down costs to a finer level where possible, using our Cost Item number/name as a header.
• Cost Item Name: short description of cost item, or deliverable or milestone name.
• FY column: You must break out costs into the FY your plan expects to incur them. You must have columns for FY2010 – FY2017. We will not pay “monthly” invoices. You will submit invoices for deliverables and/or milestones, and we will pay for services/deliverables that are accepted by Judiciary. The Judiciary will require 10 working days to review and approve all deliverables, except those deliverables that require new policies or involve documents greater than 20 pages where we will require a longer period to be determined during contract negotiations.
Baseline VCase Fixed Costs
|# |Project Plan WBS or|Cost Item |FY2010 |FY2011 |FY2012 |FY2013 … |
| |Deliv/ Milestone | | | | |FY2017 (each must be a |
| |Number | | | | |separate column) |
|10 |Ch 3 |Project Management | | | | |
|15 |Ch 3 |“90 Try” period - Insert fixed price cost |xx |xx |xx |xx |
| | |here: $ __________ | | | | |
|20 |Ch 4 |Core CMS/DMS Requirements (Note: we think there| | | | |
| | |are no costs associated with this chapter) | | | | |
|30 |Ch 5 |E-Filing | | | | |
|40 |Ch 6 |Initial Configuration and Construction (Overall| | | | |
| | |plan) | | | | |
|41 |Ch 6 |Analysis/Design - Configure | | | | |
|42 |Ch 6 |Construct | | | | |
|43 |Ch 6 |Test (including documentation and training | | | | |
| | |preparation) | | | | |
|45 |Ch 6 |Design/Code/Test of Reports and Form Letters | | | | |
|50 |Ch 7 |Production System Rollout and Training | | | | |
|60 |Ch 8 |Interfaces (baseline, see Options below) | | | | |
|70 |Ch 9 |Conversion (baseline, see Optional additional | | | | |
| | |support below)) | | | | |
|80 |Ch 10 |Architecture and Support | | | | |
|85 |Ch 10 |Software licenses | | | | |
|90 |Ch 11 |Post-Implementation Support | | | | |
| | |TOTAL fixed baseline cost for fiscal year -( | | | | |
Optional VCase Costs
|State Option|Your Option Number |Cost Item |Cost |Affect on baseline |
|# | | | |fixed cost? |
|O-10 | |Ch 9 - Cost for additional analyst and/or programming | | |
| | |support for Conversion | | |
|O-22 | |Ch 8 - Single Interface, Same documentation as Exchange| | |
| | |006 | | |
|O-23 | |Ch 8 – VT IEPD (GJXML) to NIEM.20 | | |
|O-24 | |Ch 8 – Judiciary provides NIEM 2.0 IEPD | | |
| | | | | |
| | | | | |
|V-10 | |(additional Vendor Option) | | |
4 Checklist for Responding to this Chapter
Your response to this Chapter must include, at a minimum, the items listed below. Please provide a complete response, but be as concise as reasonably possible. Your responses must be clearly labeled to correspond to the chapter section and subsection numbers listed above where stated. You may add additional information after the last section listed. If you object or disagree with any requirement listed above, please note this in your Exceptions chapter.
1. Your response must provide fixed and optional Assumptions and Costs grids as supplied above.
2. You must answer the following questions:
a. What is the TOTAL BASELINE FIXED COST (FY2010 – 2012) bid: $ _______
b. What deliverables or activities would you recommend deleting if we wanted you to lower your Total Baseline Fixed Cost by $1million?
c. If we allowed the timeframe for Total Baseline Fixed Cost activities to change from 3 years to 5 years, how would this impact your project plan? What would be the impact on Total Baseline Fixed Cost? Would this significantly lower risk? What would be the impact on staffing requirements?
d. What are the three costs/cost areas listed above that you feel are the most volatile, and why? What do you expect the range of these costs may be?
e. What are the three major suggestions you have for the Judiciary to contain costs in this project?
f. In response to Chapter 13, what is your approximation (high – low range) of cost for Phase 2 – E-Filing and Probate Court rollout. You must include an explanation of how you estimate these costs. You must break down the range of costs for system wide e-filing vs. probate court rollout.
3. Additional costing information that will assist the Judiciary in assessing your proposal.
Project Phase 2 - E-Filing and Probate
1 Introduction
As specified earlier in this RFP, the 36 month project described is a step to the ultimate goal of reaching a paperless court within five years. The vision also includes an electronic casefile that includes a digital audio or video capture of all in-court activity with respect to the case. The e-filing and electronic casefile features to be implemented within the 36 month period are intentionally spread into the main trial courts – superior, district and family – and in different types of cases to give the judiciary experience in implementing e-filing in various applications to better develop its vision for a paperless court. We expect, however, that we will continue the framework approach specified in this RFP and e-filing “will be configured for each subject matter court and case-type to provide a high level of differentiated case processing.” See section 4.1 in this document.
2 Phase 2 E-Filing Description
We cannot now define the vision sufficiently for you to bid a fixed cost for Phase 2 at this time. For planning purposes, however, we do ask each vendor to give us an approximation of the cost of Phase 2, again without hardware costs, or an explanation of how that cost can be calculated. It is our expectation that we will sign a contract for proposals to the current RFP only if we are confident that we have, or will raise, the resources for Phase 2. It is also our expectation, however, that the e-filing software and applications you deliver in response to this RFP will be sufficiently flexible that we can adapt them to other types of cases without further vendor actions, and, thus, a substantial part of vendor costs for Phase 2 will be included with the current proposal. For example, introduction of the e-filing initiatives as described in Chapter 5, despite the continuation of the paper files, is intended to pave the way for the introduction of a judiciary wide paperless system. The presence of a set of e-filing managers in response to the initiatives described in Chapter 5 will be a major consideration in evaluating the e-filing component of the bid. The Judiciary expects to continue its policy of no document scanning in the courts (except in the Judicial Bureau.)
We expect that within two years of contract signing, we will prepare and publish detailed specifications for Phase 2. We reserve the right either to continue into Phase 2 with the winning vendor of this VCase RFP or to publish a new request for proposal for a competitive bidding process for Phase 2.
3 Phase 2 Probate Court Description
The application of VCase to the probate courts requires separate description and specification. We are committed to providing a modern CMS/DMS to the 18 probate courts, which currently have either or no system or a very rudimentary one. We have concluded, however, that it would be unwise to provide a generic system in the probate court because of the nature of its business processes, the high dependence on forms, and the extensive pro se users. The Vermont Rules of Probate Procedure contain almost 200 official forms, and Rule 59(g) specifies that the parties must use “applicable official forms contained in these rules unless otherwise permitted by the court.” Although some business in the probate court is conducted in response to individually-crafted filings, the vast majority of business activity is conducted in response to form filings. Also, consent to actions, as provided on forms by interested parties, routinely obviates the need for court action.
Thus, the Vermont Judiciary has concluded that the introduction of the CMS/DMS system into the probate court should be coextensive, in Phase 2, with the introduction of a paperless environment with extensive on-line forms. To improve access for pro se users, the Vermont Judiciary intends to continue the A2J script development process from the superior and family court initiatives into the probate court with the expectation that A2J input will be available for all probate forms used extensively by pro se probate court users within 36 months after contract signing.
Vendors should not bid the introduction of VCase into the probate courts in response to this RFP. Instead, they should answer the questions for Phase 2 below with the understanding that Phase 2 includes both the introduction of a CMS/DMS system for the probate court and the introduction of a judiciary wide paperless environment, dominated by filing of on line forms electronically or by the filing of A2J script output to populate the forms.
4 Checklist for Responding to this Chapter
Your response to this Chapter must include, at a minimum, the items listed below. Please provide a complete response, but be as concise as reasonably possible. Your responses must be clearly labeled to correspond to the chapter section and subsection numbers listed above where stated. You may add additional information after the last section listed. If you object or disagree with any requirement listed above, please note this in your Exceptions chapter.
1. In response to section 13.2 above, you must include a cost estimation and description in Chapter 12, section 12.4, bullet # 2 – f.
2. In response to section 13.2 above, provide your approach, expected major tasks and milestone, staffing level of effort, timeline, and assumptions for completing a judiciary-wide paperless system.
3. In response to section 13.3 above, provide your approach, expected major tasks and milestones, staffing level of effort, timeline, and assumptions for completing the probate court rollout.
Vendor Response Content and Format
1 Proposal Content
The Judiciary has established certain requirements with respect to proposals to be submitted for contracted services. Whenever the terms “will”, “must”, “shall”, or “is required” are used in this RFP, the referenced specification/requirement is a mandatory requirement. Failure to meet any mandatory requirement may cause rejection of the proposal.
The proposer’s response to the RFP will be considered as the proposer’s formal offer.
The proposal must include the requested information in sufficient detail to allow the Judiciary to evaluate the proposal based solely on the information provided. References to the RFP text in the proposal must contain the same section number and title as used in this RFP.
By submission of a proposal, the responder warrants that the information provided is true, correct and reliable for purposes of evaluation for potential contract award. The submission of inaccurate or misleading information may be grounds for disqualification from the award, subsequent cancellation of the contract, if awarded, as well as subject the responder to suspension or debarment proceedings as well as other remedies available by law.
2 Required Format of the Proposal
Failure by any Vendor to include the following information or statements in its proposal may result in the proposal being declared unacceptable or non-responsive, and it will receive no further consideration for award of the contract.
NOTE: Throughout this document, most chapters will ask a set of questions and require that you answer each. You must clearly correlate your answer to our question in all cases. You are encouraged to clip our question into your response and respond to each. If you respond in a Q/A format, please be sure to distinguish our question from your answer, for example, by using a different font or by putting our question in italics.
Proposals must include the information prescribed herein and be organized in the following manner. Additional information about some “Tab” content is provided later in this chapter.
Tab 1 Title Page
Each copy of the proposal will have a title page with the following:
A. Title of Proposal and Submission Date
B. Vendor's Name
C. Name, Title, Phone Number, E-mail and Mailing Address of the person who will respond to inquiries regarding the proposal.
D. Address of the Vendor headquarters
E. Address of the location responsible for the Judiciary’s accounts
Tab 2 Addenda Acknowledgment
Provide a list of any addenda received identifying the date of receipt.
Tab 3 Letter of Transmittal and Vermont Tax and Insurance Certificate Form
(RFP Attachment 2)
Tab 4 Table of Contents
Tab 5 Management Summary - This tab presents an Executive Level description of what you intend to accomplish and your approach to ensuring a successful implementation. Tab 5 must contain the completed Proposal Summary Chart as listed in section 1.7. Your response must include a detailed narrative description of how you believe that your proposed solution will satisfy the functions described by the Project Vision (section 1.6), indicate the major functionality you propose to address in the CMS, DMS, and E-Filing requirements, and describe your vision on how all these processes will come together in the new VCase. You must note where third party packages and/or significant modifications to your system would be required to satisfy the vision. Attached at the end of the Management Summary will be the Company Background form as found below in section 14.3.
Tab 6 CMS/DMS/E-Filing Experience - Explain, in detail, your company and proposed team experience with the full system life cycle configuration of multi-court case management systems implementation efforts, your experience helping courts move to “paperless case” files, and other relevant systems experience that relates to the functionality and expertise needed to successfully complete the VCase Vision outlined in this RFP. If you have proposed a new CMS that has been substantially reworked in the last three years, provide background on the major goals of the rewrite and the major differences between the currently proposed system and your last generation system. If Vermont should buy your system, and we are likely to be the first production implementation of the new version of your system, explain how you intend to mitigate the inherent risks of being the first to implement your new framework.
Tab 7 Project Management – Provide your response to Chapter 3 as outlined in the Checklist at the end of the chapter. This chapter will include your discussion of proposed staffing. Please provide an overview of the capabilities of each proposed staff member in the response, but provide resumes as an Attachment to your proposal.
Tab 8 Core CMS/DMS Requirements - Provide your response to Chapter 4 as outlined in the Checklist at the end of the chapter. We have provided a Word version of the RFP text so that you can copy our questions into your response if you choose. Please place your response to the Core Capabilities Chart (RFP Attachment 6) as an Attachment to the body of your response.
Tab 9 E-Filing - Provide your response to Chapter 5 as outlined in the Checklist at the end of the chapter.
Tab 10 Initial System Configuration and Construction - Provide your response to Chapter 6 as outlined in the Checklist at the end of the chapter.
Tab 11 Production System Rollout and Training - Provide your response to Chapter 7 as outlined in the Checklist at the end of the chapter.
Tab 12 Interfaces - Provide your response to Chapter 8 as outlined in the Checklist at the end of the chapter.
Tab 13 Conversion - Provide your response to Chapter 9 as outlined in the Checklist at the end of the chapter.
Tab 14 Architecture and Support - Provide your response to Chapter 10 as outlined in the Checklist at the end of the chapter.
Tab 15 Post Implementation Support - Provide your response to Chapter 11 as outlined in the Checklist at the end of the chapter.
Tab 16 Phase 2 E-Filing and Probate - Provide your response to Chapter 13 as outlined in the Checklist at the end of the chapter.
Tab 17 References - Provide at least five references where you have built similar case management systems, document management systems, and/or e-filing systems within the last 10 years. At least three references must be from a large county (greater than 500,000 people) or tribal or state courts. Note: Extra consideration is given to references of states of a similar size to Vermont (i.e., we have found that very large court experience in states like California does not translate well to a small state project like Vermont.) Explain if less than five references are provided. If you propose a teaming arrangement, include at least one reference where your proposed team worked together (if possible). References must include: (a) a description of the project, (b) an explanation of why you chose to include the reference and why you think the reference is applicable or comparable to the Vermont project, (c) an overview of the functions provided and technology used, (d) approximate cost, (e) number/category of team members assigned to the project, (f) project timeframe, and (g) name, title, current phone number, and current email address of the person who can speak to the vendor’s work on the project. Your references section must also provide a complete client list for the last 3 years.
Tab 18 EXCEPTIONS - You must list all exceptions you have to this RFP (e.g., legal exceptions, technical exceptions, functional exceptions), in one consolidated chapter of your proposal entitled EXCEPTIONS.
Tab 19 Warranty Periods - You must specify exactly what services you propose to offer during the required one year warranty (all parts and labor included). You must also address the Judiciary’s options for continuing past the one-year warranty/support period to supply standard support and, optionally, system maintenance including making legislative changes to the system. In your description of your warranty period capabilities include: length of warranty, days and hours of coverage, types of support (telephone, chat, remote software support, etc), service response times, hardware preventive maintenance include (if applicable).
Tab 20 Required Forms - The required Vermont Tax Certificate and Insurance Certificate (Attachment 2), Offshore Outsourcing Questionnaire (Attachment 3), Use of Recycled Materials or Products Report (Attachment 4) and Mercury Content Certification Forms (Attachment 5).
Put the following in a separate, or multiple separate electronic files. Do not combine with your electronic version of Tabs 1 – 20.
Tab 21 Vendor Standard Contract and/or Licensing Agreements - Attach copies of your Standard Contract and/or Licensing agreements as Attachments (or as a separate document) to the body of your response. Also, include a sample of all applicable support and maintenance agreements.
Tab 22 Samples of Documentation - Include samples of documentation, as Attachments to your proposal (preferably in a separate document) such as: training manual, user manual, system administration manual, system architecture documentation, warranty service level agreement.
Tab 23 (Other) You may include additional Tabs that contain information that you believe are important for Vermont in evaluating your proposal.
(SEPARATE DOCUMENT) Cost Proposal – Provide your response to Chapter 12, Costs, in a clearly labeled separate document.
3 Summary of Background and Experience Form
Each bidder (primary and partners, if applicable) must provide, at a minimum, the following information about their company so that the Judiciary can evaluate the Bidder’s stability and ability to support the commitments set forth in response to the RFP. The Judiciary may require additional documentation to support and/or clarify requested information.
Company Background
Company Name Primary Vendor (Y/N)
Office Address Serving the State of Vermont
Headquarters Address
Contact Representative Title Telephone and E-mail
a. How many years has your company provided software applications?
1) Court System Solutions _____Years
2) Legal Systems Solutions _____Years
3) Other System Solutions _____Years (Explain)
b. How many employees does your company have?
TOTAL: ____
Concentrating on Judicial Case Management Systems: _____
Concentrating on E-Filing, E-Forms, and Document Mgmt: _____
Training: _____
CMS/E-Filing/Doc Mgmt Support: _____
Other areas related to work required in this RFP (specify): ______
c. What is the total number of installed sites of your proposed system?
1) Statewide Court _______
2) County-wide Court _______
3) Legal _______
4) Other _______ (Explain)
d. How many organizations are currently installing your proposed system but have not completed the installation/conversion?
e. What is your company’s largest caseload system completed installation? Please provide caseload statistics and court name. If no caseload system installation, please provide the same information for your largest, similar system installation.
f. Provide a brief history of your company and a description of your company’s present organizational structure. Include a statement indicating your understanding of government procurement practices and policies.
g. Provide a summary of any litigation, previous or outstanding, relating to your company’s performance of professional services contracts, or an account of why this information is not provided.
h. Provide a list of all incidents within the past three (3) years in which a contract was terminated or not renewed.
e. Provide financial information (e.g., Dunn and Bradstreet report if applicable) that indicates the financial stability of your company.
f. Performance Bond available? Attached?
Proposal Submission Instructions
You must submit:
• Ten (10) bound printed copies of your technical proposal, plus;
• Ten (10) bound printed copies of your cost proposal, plus;
• One hardcopy of the complete technical and cost proposal as an unbound master (suitable for running through a copy machine, no inserted tabs or clips), with a signed tax certificate and a signed transmittal letter as part of the Cost proposal. NOTE: Our copiers and printers are black and white – we discourage the use of heavy color charts that will not print and/or copy well in black and white; and
• One (1) electronic copy of all files related to the technical proposal on one CD; the cost proposal on a separate CD clearly marked “cost proposal”.
FOR THE ELECTRONIC COPY OF FILES -- you must:
• Include the MS Office for Windows Word 2003 or above document of your technical and cost proposals in unlocked and in editable form. Separate files of project plans in MS Project 2003 or above, as well as Excel spreadsheets, may be included as necessary and also must be unlocked and editable; and,
• Include a .pdf version of your technical and cost proposals.
Screen samples, sample documents, etc can be submitted as separate Attachments in Word or .pdf files. The document(s) may be zipped into separate zip files (e.g., Word version, pdf version, Attachments like sample training materials in a third zip file). You must combine individual files into as few files as reasonable (i.e., please do not include each chapter as a separate file within a zip file, or each resume as a separate file); however:
• NO SINGLE TECHNICAL OR COST PROPOSAL DOCUMENT (WORD OR PDF) MAY BE LARGER THAN 2 MEG (2,000 K). We often send the files to people internally as email attachments, and huge attachments fill mailboxes. If the body of your technical proposal is large, you may break the Word file in two or more files and label the files appropriately (VendorY-TechnicalProposal-Part1.doc, VendorY-TechnicalProposal-Part1.pdf, VendorY-TechnicalAttachments-Part1.doc, VendorY-TechnicalProposal-Part2.doc, VendorY-TechnicalProposal-Part2.pdf etc.);
• If you must put a very large .pdf of a training document or sample user guide on the CD that will be OK, since we will not send that around as an email attachment.
• Your company name (e.g., “VendorY” in the example above) must be the first part of all electronic file names. It must be clear what files fit together and in what order they should be printed.
• Be sure to package and label the unbound masters and include the CDs in the envelope with the masters (It is not necessary to include CDs with every bound copy): “Master Judiciary VCase Technical Proposal” and “Master Judiciary VCase Cost Proposal”.
Please note that any and all pages of your proposal containing confidential and proprietary information must be clearly marked “Proprietary and Confidential.” After completion of this bid process, all proposal materials are in the public domain and confidentiality cannot be guaranteed. Proposals shall not have entire chapters marked “Proprietary and Confidential”. Proposals shall not be marked “Proprietary and Confidential” in their entirety.
Submissions must be received according to the schedule outlined in Section 2.1. You must clearly identify all packing material as “Judiciary VCase Proposal.” You must submit the proposal copies to the Contact listed on page 1 of this RFP at the address below.
1 Closing Date
The closing date for the receipt of proposals is listed in Section 2.1, Schedule. Bids must be delivered to:
Mr. Rick Conklin
VCase Project Manager
State of Vermont Judiciary
2418 Airport Road, Suite 4
Barre, VT 05641
Proposals or unsolicited amendments submitted after that time will not be accepted and will be returned to the vendor. The bid opening will be held at 2418 Airport Rd, Suite 4, Barre, VT, and is open to the public. Bid amounts will not be disclosed at the bid opening.
2 Sealed Bid Instructions
BID ENVELOPES MUST BE CLEARLY MARKED ‘SEALED BID’ AND SHOW THE PROPOSAL TITLE (Judiciary VCase Proposal), OPENING DATE AND NAME OF BIDDER.
All bidders are hereby notified that sealed bids must be in the office of the RFP Contact by the time of the bid opening. Bids not in possession of the RFP Contact at the time of the bid opening will not be considered.
• SHIPPING NOTE: Berlin, VT is not on the “arrive by 10:30” am schedule of the major delivery companies. Deliveries are expected here by 1pm., but they sometimes arrive later. Also, we do not know of a local company that could print and deliver your response in an emergency. The proposal due time is set for 2pm. However, you should remember that is it your responsibility to have your proposals delivered ON OR BEFORE the due date. The Judiciary encourages you to consider early delivery of your proposal if possible.
The Judiciary may, for cause, change the date and/or time of bid openings or issue an addendum. If a change is made, the Judiciary will make a reasonable effort to inform all bidders by posting at the bid website and sending an email to those who register with Intent to Bid.
All bids will be publicly opened. Any interested party may attend bid openings. Bid results may be requested in writing and are available once an award has been made.
3 Delivery Methods
U.S. MAIL: Bidders are cautioned that it is their responsibility to originate the mailing of bids in sufficient time to ensure receipt by the RFP Contact prior to the time of the bid opening.
EXPRESS DELIVERY: If bids are being sent via an express delivery service, be certain that the RFP designation (Judiciary VCase Proposal) is clearly shown on the outside of the delivery envelope or box.
HAND DELIVERY: Hand carried bids must be delivered to the office of the RFP Contact prior to the bid opening.
ELECTRONIC: While an electronic copy of the bid is required (as explained above), electronic bids will not be accepted.
FAX BIDS: Faxed bids will not be accepted.
Description of Attachments
Attachments are in a separate document that accompanies this RFP. The following list explains the contents of each Attachment:
Attachment 1: State Contracting Addendum – This attachment will be part of the contract. If you have any exceptions and/or comments on any area of Attachment 1, please clearly explain your exception and/or comment in the EXCEPTIONS chapter of your proposal.
Attachment 2: Vermont Tax Certificate and Insurance Certificate – You must complete this form and return a signed original (along with your cover letter) with your hard-copy submission.
Attachment 3: Offshore Outsourcing Questionnaire – This attachment contains a form that is used by the State Purchasing Dept to gather statistics. It has no bearing on a vendor’s right to bid or the State’s evaluation of proposals.
Attachment 4: Use of Recycled Materials or Products Report – This attachment is required by the State’s Purchasing Department for all RFPs. Please complete as applicable.
Attachment 5: Mercury Content Certification Form – This attachment is required by the State’s Purchasing Department for all RFPs. Please complete as applicable.
Attachment 6: Core CMS/DMS Requirements Chart – This chart accompanies Chapter 4. You must complete this chart. Instructions are at the top of the chart.
Attachment 7: Public Access Rules – This attachment contains the text of the Public Access to Court Records Rule 6 and the Access to Electronic Case Records Rules.
Attachment 8: Overview of VTADS and the Data Warehouse - Attachment 8 presents an overview of the functionality found in VTADS and the programming approach used to build it.
Attachment 9: VTADS Events and Data Structure Summary - This attachment provides a list of VTADS2 “Events” and VTADS Table and Column names for the VTADS2 tables, for the VTADS1 Supreme Court system, and the Traffic system. VTADS2 will be demonstrated at the Bidder’s Conference.
• Conversion Note: VTADS2 was created when disk space was relatively expensive and it was designed to use as little as possible. One method employed was the bitlist, which essentially uses a string to store elements of an array. For example, the string '1-4,6,8-10' would be parsed as 1,2,3,4,6,8,9,10. It is often part of a composite foreign key, usually with the value of a *_docid column. So a probation warrant issued event could reference a single dispute (eve_disls = '2') or, to use the bitlist example cited above, '1-4,6,8-10' , it could reference 8 disputes. Since the bitlist could complicate the source to target mapping in any data migration, we wish to alert bidders of its existence.
Attachment 10: Judicial Bureau System Overview – This attachment presents a description of the processing in the Judicial Bureau taken from the July, 2000 RFP to purchase the scanning/imaging system.
Attachment 11: DMV Exchange – This attachment provides the definition of the exchange requirements, provided by the DMV, for Judiciary data being sent to the new DMV system.
Attachment 12: VTADS Interfaces Definitions – This attachment contains the file layouts of the VTADS interfaces as listed in the spreadsheets presented in Chapter 8, Interfaces.
Attachment 13: Information Filing IEPD Summary – This attachment contains the Word document overview of the GJXDM 3.0-compliant IEPD finished last year for the Information Filing exchange.
Attachment 14: VTADS2 Forms List – This attachment provides a list of the “merge” forms generated from VTADS2.
Attachment 15: VTADS2 and Traffic Screen Summary Presentation - This attachment contains the Power Point slides that were used in the first RFP Bidder’s Conference to provide an overview of VTADS2 and Traffic. We will talk through, and answer questions above, these slides at the July Bidder’s Conference.
Attachment 16: Court Activities Reports - This attachment contains two reports that list most of the various activities in all courts except Supreme and Probate. The activity data was gathered from a survey of the court managers in spreadsheet format and then loaded into an MS Access database for reporting and use by the VCase project. The reports presented in this attachment are:
1. Events By Court-Docket-When (first 43 pages of the pdf) -- The major report break (listed in bold at the top of the page) is Court. Next level break is Docket within the Court. Within Docket, the activities are divided into the general order of the flow of a case called “when”. The When definitions are:
a. Before A Case Is Opened
b. When A Case Is Opened
c. Pre Adjudication
d. Adjudication of the Merits
e. Post Adjudication, and,
f. Anytime during the case flow.
2. Demo Script Events (sort by When and Event) – This second report presents the activities sorted in major order of “When”, as defined in the list above (and may be used by the Judiciary as a basis for developing Demo Scripts for the Vendor Finalist Demos.) The activities are sorted in alphabetic order under each “When” heading and each report line contains an activity name, a docket where in which that activity occurs, and a court where the activity occurs.
-----------------------
[1] Vermont Information Consortium (VIC) is the state of Vermont's partner for online services. VIC assists Vermont government entities by providing online services on their behalf. Vermont Information Consortium is a subsidiary of NIC USA, Inc.
[2]. Two superior courts are not using the OCA-sponsored court case application, VTADS2.
-----------------------
LOAD #2
Intermediate
Conversion
File
Common Extract Database
VTADS Databases
Data warehouse
“CLEANERS”
Extractor
High-Level Judiciary View of Conversion Process
LOAD #1
A2J Guided Interviews (web pages)
A2J web server
VCase XML Server (replaces NPADO server)
User answers interview prompts via A2J web pages
VCase CMS/DMS database
New File?
XML
“Door”
Alert into CMS Workflow
Merge in XML-Create pdf Form
Pdf To DMS
Insert XML into CMS via Interfaces engine
Send completed form copy back to user
MESSAGE
Court looks at form image in DMS
XML
To CMS
XML
VCase Web Portal
VCase Collect Filing Fee Web Pages
To CMS
XML
.pdf Form image
A2J Author
VCase
Database
-----------------------
Supreme Court of Vermont
Office of the Court Administrator
109 State Street
Montpelier, VT 05609-0701
(Phone) 802-828-3278
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.