RFI

THE COMMONWEALTH OF MASSACHUSETTS EXECUTIVE OFFICE OF ENERGY AND ENVIRONMENTAL AFFAIRS 100 CAMBRIDGE ST, BOSTON, MA 02114

REQUEST FOR INFORMATION (RFI) REGARDING DRAFT REQUEST FOR RESPONSE (RFR) DOCUMENT TITLE: ENERGY AND ENVIRONMENT INFORMATION AND PUBLIC ACCESS SYSTEM (EIPAS) – PHASE II DOCUMENT NUMBER: RFI ENV-IT-2014-823 AUGUST 23, 2013

THIS RFI AND ALL RESPONSES HERETO WILL BECOME PUBLIC RECORD EIPAS II RFI EEA-IT-2014-823

Page 1 of 103

TABLE OF CONTENTS 1.

2.

REQUEST FOR INFORMATION (RFI) .................................................................................. 7 1.1

Intent and Goals of this RFI ........................................................................................... 7

1.2

Method of RFI Response Submission ........................................................................... 8

1.3

Vendor/Interested Party ............................................................................................... 9

1.4

Additional Information .................................................................................................. 9

1.5

Costs ................................................................................................................................ 9

1.6

Review Rights ............................................................................................................... 10

1.7

EEA Ownership of Submitted Materials .................................................................... 10

1.8

RFI is NOT a Contract or Agreement for Services ................................................... 10

EIPAS REQUEST FOR RESPONSE...................................................................................... 13 2.1

RFR Procurement Background and Scope.............................................................. 13

2.2

Background Information ............................................................................................ 13

2.3

Scope Overview and Details ..................................................................................... 16 2.3.1

2.4

RFR Procurement Details ............................................................................................ 19

2.5

Number of Awards ...................................................................................................... 20

2.6

Acquisition Method(s) ................................................................................................. 20

2.7

Contract Duration ....................................................................................................... 20

2.8

RFR Procurement Calendar (estimated).................................................................. 20 2.8.1

3.

Access to Comm-PASS Online Bidder Forum .............................................. 21

INSTRUCTIONS FOR RESPONSE SUBMISSION ................................................................. 22 3.1

Bid Response Deadline ............................................................................................... 22

3.2

Response Delivery ....................................................................................................... 22

3.3

Response Format ......................................................................................................... 23 3.3.1 3.3.2 3.3.3

Introduction ...................................................................................................... 23 Technical Response Format ........................................................................... 24 Cost Response Format .................................................................................... 25

3.4

Environmental Response Submission Compliance ................................................. 26

3.5

Vendor Presentations/Demonstrations..................................................................... 26 3.5.1 3.5.2

4.

Scope Details: System Requirements and EIPAS Project Phases .............. 17

Presentations .................................................................................................... 26 Final Oral Presentations/Product Demonstrations of a Prototype Development Exercise .................................................................................... 28

POST-RESPONSE PROVISIONS ....................................................................................... 29 4.1

Firm Offer; Duration; Response Withdrawal ............................................................. 29 4.1.1

Procurement Cancellation ............................................................................ 29


Page 2 of 103

4.1.2 4.1.3 4.1.4 4.1.5 5.

Review and Evaluation Process..................................................................... 29 Evaluation Criteria ........................................................................................... 31 Disqualification of Responses......................................................................... 32 Contractor Selection and Notice of Award ................................................ 33

RFR TECHNICAL AND COST RESPONSE CONTENT AND FORMAT ................................. 34 5.1

Overview ...................................................................................................................... 34

5.2

Vendor Response Checklist ....................................................................................... 35

5.3

Technical Response Cover Letter ............................................................................. 35

5.4

Attachment X: Requirements Tables & Narrative Technical Response ............... 35

5.5

Alternatives to Technical Requirements................................................................... 36 5.5.1 5.5.2 5.5.3

Alternative Project Timeline............................................................................ 36 Alternative Approach to a Technical Requirement ................................... 36 Assumptions, Qualifiers, and/or Constraints of Proposed Solution ........... 36

5.6

Master Service Agreement ........................................................................................ 37

5.7

Vendor‟s Cost Response ............................................................................................ 37 5.7.1 5.7.2 5.7.3 5.7.4

Cost Response Narrative ................................................................................ 38 Price Matrix ....................................................................................................... 38 Retainage ......................................................................................................... 39 Labor Rate Table ............................................................................................. 40

5.8

Standard Forms and RFR Requirements ................................................................... 40

5.9

Executive Order 515, Establishing an Environmental Purchasing Policy .............. 40

5.10 Environmental Plan ..................................................................................................... 41 6.

EIPAS PROJECT IMPLEMENTATION PLAN ....................................................................... 42 6.1

Phased Implementation Approach to Project ....................................................... 42

6.2

Means to Demonstrate Success Quickly.................................................................. 43

6.3

Roadmap ..................................................................................................................... 44

6.4

Project Planning........................................................................................................... 44 6.4.1 6.4.2 6.4.3 6.4.4

7.

Project Plan ...................................................................................................... 44 Task Orders – Required Components ........................................................... 44 Task Orders – First Year Requirements ........................................................... 45 Risk Management Plan ................................................................................... 46

PROGRAM MANAGEMENT ............................................................................................ 46 7.1

Adherence to CommonWay..................................................................................... 46

7.2

Vendor Program Manager Qualifications and Responsibilities ............................ 48 7.2.1 7.2.2 7.2.3 7.2.4

7.3

Responsibilities .................................................................................................. 48 Communications ............................................................................................. 49 Refinement of Project Plan ............................................................................ 49 Change Orders ................................................................................................ 50

Project Documentation Repository .......................................................................... 50


Page 3 of 103

7.4

Vendor Performance Evaluation .............................................................................. 50 7.4.1

8.

VENDOR QUALIFICATIONS ............................................................................................ 52 8.1

Vendor (and Significant Subvendor) Background ................................................. 52

8.2

Vendor (and Significant Subvendor) Relevant Experience .................................. 56 8.2.1 8.2.2 8.2.3

8.3

8.4

Vendor (and Significant Subvendor) Descriptions of Experience ............ 56 Vendor (and Significant Subvendor) Experience with SOA ...................... 57 Vendor (and Significant Subvendor) Stakeholder Experience ................. 58

Vendor (and Significant Subvendor) Project Team ............................................... 58 8.3.1 8.3.2 8.3.3

9.

Personnel Replacement ................................................................................. 51

Vendor (and Significant Subvendor) Project Team Organization............ 58 Vendor (and Significant Subvendor) Staff Continuity ................................ 59 Vendor (and Significant Subvendor) Key Staff Qualifications, Responsibilities, and Resumes ........................................................................ 59

Other Significant Subvendor(s)Requirements ......................................................... 60

EIPAS SOLUTION – PHASE II SPECIFICATIONS ............................................................... 61 9.1

Introduction .................................................................................................................. 61 9.1.1 9.1.2

9.2

Technology Architecture and Data Schema ......................................................... 63 9.2.1 9.2.2

9.3

Proposed Project Approach .......................................................................... 62 Proposed Solution ............................................................................................ 62 Technology Architecture Proposal ............................................................... 64 Data Schema ................................................................................................... 65

Business Components: Overview .............................................................................. 66 9.3.1 9.3.2

Business Components  Detailed Specifications ........................................ 68 Business Components Requirements ............................................................ 69

9.4

Portal Development .................................................................................................... 72

9.5

GIS.................................................................................................................................. 73 9.5.1

9.6

GIS Integration ................................................................................................. 73

Data / Reporting Warehouse(s) ................................................................................ 73 9.6.1

Data / Reporting Warehouse(s) Specifications ........................................... 74

9.7

Permitting/Licensing/Authorizations ......................................................................... 74

9.8

Entity Management / Identity Management .......................................................... 75 9.8.1 9.8.2 9.8.3

9.9

Required Capabilities ..................................................................................... 75 Highly Desirable Capabilities ......................................................................... 76 CROMERR Compliance .................................................................................. 76

Application Development ......................................................................................... 77 9.9.1

Application Development Requirements .................................................... 78

9.10 Data Migration, Mapping, Cleansing, and Synchronization ................................ 79 9.11 Device and Browser Compatibility and Support .................................................... 80 THIS RFI AND ALL RESPONSES HERETO WILL BECOME PUBLIC RECORD EIPAS II RFI EEA-IT-2014-823

Page 4 of 103

9.12 Compliance with Enterprise Accessibility Standards.............................................. 81 9.13 Quality Assurance, Acceptance and Testing Criteria ........................................... 83 9.13.1 9.13.2 10.

Quality Assurance............................................................................................ 83 Software Quality Assurance (SQA) Methodology ...................................... 83

PROPOSED TECHNOLOGY ENVIRONMENT ................................................................... 87 10.1 Hosting Requirements ................................................................................................. 87 10.1.2

Assignability of Hosting Contract .................................................................. 89

10.2 Version and Environment Management ................................................................. 89 10.3 Data and System Security .......................................................................................... 90 10.4 Data Ownership........................................................................................................... 90 10.5 Data Backup, Data Loss Prevention and Recovery ............................................... 91 10.6 Business Continuity/Disaster Recovery ..................................................................... 91 10.7 Database Management ............................................................................................ 91 10.7.1 10.7.2

Audit Trails ......................................................................................................... 91 Data Validation ............................................................................................... 92

10.8 System Availability and System Response Time ...................................................... 93 10.8.1 10.8.2 10.8.3 11.

System Availability ........................................................................................... 93 System Response Time .................................................................................... 93 Externally Hosted/Cloud Availability ............................................................. 93

TRAINING AND DOCUMENTATION................................................................................ 94 11.1 Training .......................................................................................................................... 94 11.2 System Documentation .............................................................................................. 94 11.3 Knowledge Transfer..................................................................................................... 95

12.

MAINTENANCE............................................................................................................... 95 12.1 Definition of Maintenance Requirements ................................................................ 95 12.2 Maintenance Tools...................................................................................................... 96 12.3 Maintenance and Support Agreements for COTS Software Components ........ 96 12.4 Maintenance and Support Services ......................................................................... 97 12.5 Scope of Maintenance and Support ....................................................................... 97 12.6 Maintenance , Support and Hosting Costs............................................................ 100 12.7 Maintenance for Versions and New Releases ...................................................... 100

13.

REPRESENTATIONS AND WARRANTIES ..........................................................................101 13.1 Requirements ............................................................................................................. 101

14.

NONCOMPLIANCE WITH REQUIREMENTS ....................................................................103


Page 5 of 103

TABLE OF EXHIBITS Exhibit 1: RFI Response Calendar ......................................................................................... 8 Exhibit 2: Procurement Detail Summary ........................................................................... 19 Exhibit 3: Procurement Calendar (Subject to Change) .................................................. 20 Exhibit 4: Proposed Technology Architecture: Six Individual Architectures.................. 64 Exhibit 5: Business Component Model ............................................................................... 68 Exhibit 6: Severity Level Table.............................................................................................. 99

ATTACHMENTS AND APPENDICES


Page 6 of 103

Notice to Interested Parties Request for Information (RFI) for Comments on DRAFT RFR for EIPAS Phase II 1.

REQUEST FOR INFORMATION (RFI) This Request for Information (RFI) seeks comments on the enclosed draft Request for Response, referred to herein as the (RFR). The purpose of this RFI is to solicit the input of interested parties regarding the proposed upcoming solicitation by the Commonwealth of Massachusetts, through the Executive Office of Energy and Environmental Affairs (EEA) with respect to the proposed services/proposed project as described throughout this RFI in its entirety. Any comments provided by interested parties in response to this RFI shall serve solely to assist EEA to understand the current state of the technology and marketplace with respect to the proposed solicitation and/or to inform EEA in connection with the development of a final RFR to be posted on Comm-PASS in the future. The issuance of this RFI for comments on the RFR, and any review of commentary presented in response by interested parties, does not in any way obligate or require EEA to issue, amend, or include any information provided by responding parties in any future solicitation. Responses to this RFI are purely voluntary and will in no way affect or alter EEA‟s consideration of any future response to the final RFR if/when it is posted in the future, nor will responses to this RFI serve as an advantage or disadvantage with respect to any responding Vendor in a future solicitation. This RFI is not a Contract or Contract solicitation, and submission of a response to this RFI does not create any obligations, Contractual or otherwise, on behalf of EEA with respect to the responding interested party. 1.1

Intent and Goals of this RFI In order to determine whether the RFR, together with all proposed attachments and appendices, provides interested parties with sufficient and clearly articulated information and guidance as to EEA‟s goals, objectives, and requirements for the Energy and Environmental Information and Public Access System (EIPAS) Phase II Project, EEA is issuing this RFI to solicit responses from interested parties so that EEA might evaluate all commentary/input prior to posting the RFR on Comm-PASS in its final form. All responses to this RFI should be limited to the questions presented in the next section, and EEA will not respond to any questions or suggestions relating to possible system requirements, solution alternatives or any related matter that is not responsive to the RFI questions. All responses to this RFI will be public record under the Commonwealth‟s Public Records Law, M.G.L.


Page 7 of 103

c. 66, §10, regardless of confidentiality notices set forth on any writings to the contrary. RFI Questions for Response by Interested Parties: EEA is seeking responses to the following specific questions regarding the proposed scope and content of the RFR: 1.1.a

Is there material in the RFR materials (including all attachments and appendices) that is not clear to a potential Vendor? Examples include:

1.2



Does the Vendor understand how to respond to the EIPAS Quick Win(s) approach?



Does the Vendor understand the EIPAS goals of transforming EEA legacy applications? (Project II Project Goals and their responsibilities?



Does the Vendor understand the EIPAS Implementation Phase approach, ideally 6 months or less in duration?

1.1.b

Are there RFR requirements that a potential Vendor would find unduly burdensome to respond to, or would impose other difficulties in responding to the RFR? Please identify the specific locations in the RFR document, Appendices and Attachments and present specific questions (or additional information requested) for each point of clarification.

1.1.c

Is the draft proposed timeline in Section 2.8 Procurement Calendar appropriate, given the overall requirements of the RFR?

Method of RFI Response Submission 1.2.a

This RFI has been posted on August 23, 2013.

1.2.b

Response Submissions: All responses to this RFI are due no later than noon (EST) on September 13, 2013. Respondents must submit one (1) paper hard copy of their submission and (1) electronic copy to the contact person listed in Section 1.2.e below. All responses must include the official name of the firm or entity submitting the response on the first page of the response submission. Please consecutively number all pages of the RFI response.

1.2.c

RFI Response Schedule: The following table outlines the schedule for RFI responses: Exhibit 1: RFI Response Calendar Date


Page 8 of 103

Release of RFI on Comm-PASS

August 23, 2013

Deadline for RFI response (close date)

September 13, 2013 Noon, EST

1.2.d

Response Format: EEA requests that all RFI responses be submitted with a point-by-point response to each RFI numbered subsection on which the respondent wishes to comment set forth above in Subsection 1.1.

1.2e

Contact Information Victoria Phillips Director, Enterprise Information Office Massachusetts Department of Environmental Protection One Winter Street Boston, MA 02108 [email protected]

1.3

Vendor/Interested Party Please provide a description of your company and contact information for the purposes of this RFI. Please include at a minimum, the following information: Company Name Company Address Representative Contact Information, including title Telephone number and email address Years in existence

1.4

Additional Information EEA retains the right to request additional information from respondents, either individually or from all respondents, with respect to the RFI response submissions.

1.5

Costs By submitting a response, respondents agree that any cost incurred in responding to this RFI, or in support of activities, shall be the sole responsibility of the submitting respondent. EEA shall not be held responsible for any costs incurred by respondents in preparing their respective responses to this RFI.


Page 9 of 103

1.6

Review Rights EEA reserves the right to have a review performed of any and all responses to this RFI. Said review may be conducted by, but is not limited to, officials in EEA or any Massachusetts state agency and any independent consultants retained by EEA.

1.7

EEA Ownership of Submitted Materials Any RFI responses submitted by a vendor become the property of EEA and are maintained by and made accessible to outside parties at the discretion of EEA.

1.8

RFI is NOT a Contract or Agreement for Services This RFI is not an open solicitation for any products or services, but rather is an informational inquiry by EEA into the current technological capabilities of new and recent remote sensing, monitoring and reporting services/technology. This RFI is NOT a contract or a contract solicitation. Submission of a response to this RFI does NOT create any obligations, contractual or otherwise, on behalf of EEA. Submission of a response to this RFI does NOT create any type or level of agency or partnership or any employer/employee relationship between the submitting respondent and EEA.


Page 10 of 103

This page intentionally left blank


Page 11 of 103

THE COMMONWEALTH OF MASSACHUSETTS EXECUTIVE OFFICE OF ENERGY AND ENVIRONMENTAL AFFAIRS 100 CAMBRIDGE ST, BOSTON, MA 02114

DRAFT REQUEST FOR RESPONSE (RFR) DOCUMENT TITLE: ENERGY AND ENVIRONMENTAL INFORMATION AND PUBLIC ACCESS SYSTEM (EIPAS) – PHASE II DOCUMENT NUMBER: Please Note: This is a single document associated with a complete Solicitation that can be found on Comm-PASS. All Bidders are responsible for reviewing and adhering to all information, forms and requirements found in all tabs and related forum records for the entire Solicitation. To locate the Solicitation associated with this document, go to www.comm-pass.com, select the “Search for solicitations” link, enter the above Document Number in the “Document Number” field, and select the “Search” button. Vendors who need help regarding Comm-PASS navigation may refer to the Comm-PASS Resource Center at www.mass.gov/osd for documents and guides. Vendors may also contact the Comm-PASS Helpdesk at [email protected] or the Comm-PASS Helpline at 1-888-MA-STATE. The Helpline is staffed from 7:30 AM to 5:00 PM Monday through Friday Eastern Standard or Daylight time, as applicable, except on federal, state and Suffolk county holidays.


Page 12 of 103

2.

EIPAS REQUEST FOR RESPONSE 2.1

RFR Procurement Background and Scope The objective of this Request for Response (RFR) is to procure the services of a Vendor to develop and implement the Energy and Environmental Information and Public Access System Phase II Project (EIPAS Project). The EIPAS Project requires the Vendor to propose and develop a technology architecture designed to support a new integrated database architecture upon which 100+ legacy applications will be transformed and migrated. In addition to developing the integrated architecture and migrating/transforming the legacy applications and migrating data, the Vendor will be required to provide appropriate training, maintenance and support services for the completed system. The EIPAS Project will utilize a Master Services Agreement upon which subsequent task orders will be developed. The description of the MSA and Task Orders are detailed in subsequent sections in this RFR document. The EIPAS Project will be subject to an Independent Validation and Verification (IV&V) process during system development and implementation. EEA, through a separate procurement, will hire a Vendor to perform the IV&V function. Throughout the lifecycle of the EIPAS Project, the EIPAS Project Vendor will be required to provide documentation and to meet with the EIPAS Program Management Team and the IV&V Vendor to review the EIPAS Project progress. This RFR is being issued by the Executive Office of Energy and Environmental Affairs (EEA), and the resulting Contract will be available for use by EEA. Issuance of this RFR does not commit EEA to pay any costs incurred by Vendors in the preparation of a response to this RFR, or to procure or Contract for services. EEA reserves the right to accept or reject any and all responses received as a result of this RFR, to negotiate with any or all qualified Vendors, and to cancel this RFR, in part or in its entirety, if it is in the best interest of the Commonwealth to do so.

2.2

Background Information The Executive Office of Energy and Environmental Affairs (EEA), a Secretariat of the Commonwealth of Massachusetts, is issuing this RFR. EEA requires an information technology (IT) solution that will advance, align, expand, and transform the manner in which EEA‟s six secretariat agencies execute timely, predictable, and cost-effective business functions. The EIPAS Project is intended to facilitate transparent sharing of data, through an integrated data system providing common functionality, and features throughout EEA, as well as fully serving the information needs of the public,


Page 13 of 103

registered individuals, regulated entities, energy and environmental professionals, Commonwealth partners, Federal oversight agencies, and other stakeholders. This RFR represents the second phase of the Energy and Environmental Information and Public Access System - EIPAS Phase II, otherwise known as the “EIPAS Project.” The specifications for EIPAS Phase II are based on the recommendations and conclusions developed in EIPAS Phase I, which concluded in February 2012. EEA and the Massachusetts Department of Environmental Protection (MassDEP) contracted with xFACT (a global public sector management firm) to develop a roadmap regarding development of a new integrated information technology and application architecture, and application platform. xFACT developed Enterprise Information Architecture documentation and a roadmap to facilitate the transformation of existing EEA‟s application environment. The full text documenting EIPAS Phase I appears in Attachment 1: EIPAS Phase I Documents. NOTE TO VENDORS: EEA, as a whole, has adopted the EIPAS Phase I documents; therefore, all references to MassDEP in the EIPAS Phase I Documents are applicable to all EEA agencies. The intent and required outcomes of this RFR are based upon the contents of the EIPAS Phase I documents and Vendors must familiarize themselves with the EIPAS Phase I documents and understand that EEA requires the outcome of the EIPAS Phase II Project to reflect the outcomes identified in the EIPAS Phase I documents and this RFR. (Note: the procurement resulting in the selection of xFACT specifically stated that the winning Vendor would not be precluded from bidding on subsequent EIPAS procurements.) The envisioned EIPAS Phase II Project is based on integrated business processes; focuses on end user needs; and promotes online collaboration and information sharing among EEA agencies, regulated businesses and individuals, environmental stakeholders, and the public. While further details can be found in the attached EIPAS Documents Attachment 1: EIPAS Phase I Documents, the benefits of the envisioned EIPAS Project are summarized in the following bullets. 

Reduced uncertainty, cost and time to meet, address and/or respond to business needs



Improved Stewardship of the Commonwealth‟s Energy and Environmental Resources



Agency staff doing more with less through enhanced technology investments


Page 14 of 103



Increased transparency and civic engagement for regulated entities, interested stakeholders, and the public



Enhanced EEA collaboration with other agencies, Federal Government and municipalities



Improved revenue collections



Continuing benefits/improvements from technology investments

Foundational principles for the EIPAS Phase II Project include: 

Adopt a functional, not program-based, approach: New functionality should be planned and implemented on a business process basis using a Service Oriented Architecture (SOA). Once a common service is designed and implemented through SOA, it should be capable of being reused or extended to support other programs in the enterprise whose programs and systems require similar functionality.



Promote continuity with legacy systems: While new system functionalities are being designed and implemented, the existing core legacy system functionality needs to be maintained. Implementation activities need to account for the concurrent running of legacy and new systems until legacy systems can be retired in full.



Utilize quick wins to show progress: Foundational projects and the initial applications targeted for migration will take time to properly plan and implement. These activities should be paired with discrete, achievable quick win projects that show progress and serve as proofs of concept of the selected technologies and architectures. The selection of quick win projects should take into consideration the competing EEA resource needs to maintain legacy systems while new EIPAS functionality and applications are developed.



Minimize changes to legacy systems: Implementation approaches should be identified that minimize the degree of coding changes to the existing legacy systems while they are being migrated and transformed onto the new EIPAS architecture. The staggered retirement of legacy systems should be a significant factor in prioritizing implementations to limit the overall support burden on EEA/IT.



Begin with foundational governance and technology projects: EEA needs to, with Vendor support, adopt enterprise governance and technology approaches to manage the


Page 15 of 103

decisions and change that will result from the new system‟s implementation. This includes the adoption of a new enterprisewide technical architecture to guide this and other future EEA/IT application development efforts. 

Reform business practices to maximize the value of IT innovation: i.e., adopt data standards, including standardized naming conventions, to ensure information can be stored and shared in a consistent manner.

MassDEP, as the primary agency partner for this project, currently utilizes approximately 100 + disparate applications with varying degrees of integration, which contain approximately 20+ years of data. These applications and their corresponding data will need to be cleansed, migrated and transformed within the new data architecture as part of the EIPAS Phase II Project. Approximately 40 applications from the remaining 6 EEA agencies will also be migrated and transformed onto the new EIPAS architecture within the EIPAS Phase II Project scope. 2.3

Scope Overview and Details The scope of the EIPAS Phase II Project includes, but is not limited to design, development, configuration, implementation, deployment, operation, documentation, training, system maintenance, and hosting of the EIPAS solution (“EIPAS”). The EIPAS Project must be developed on integrated technology architecture and application architecture intended to support all future EEA applications and allow for incremental expansion and enhancement of systems as business needs evolve. Included within the scope of the EIPAS Project is the migration/transformation of 100+ applications onto the newly developed integrated technology architecture and integrated database schema. The applications that will be migrated/transformed onto the new architecture include manual processes, spreadsheets, and databases, as well as complex, integrated databases written in Oracle and SQL. The applications, and their corresponding data that must be cleansed, migrated/transformed into the new EIPAS solution are identified in Attachment 8: Applications List with Screenshots. The EIPAS Project scope includes knowledge transfer and documentation throughout the Project by the Vendor to EEA. Training is also a critical component of the Project and includes EEA end user and EEA IT staff training, utilizing various mechanisms including, but not limited to classroom training, web training and train-the-trainer sessions.


Page 16 of 103

This RFR in its entirety is representative of the breadth and complexity of the processes, features, applications and data that the EIPAS Architecture must encompass. 2.3.1

Scope Details: System Requirements and EIPAS Project Phases EEA requires Vendors to propose an integrated technical architecture, data model and database schema in conjunction with a Service Oriented Architecture (SOA) that will support common business components upon which portals, applications and workflows will be built. The EIPAS Project requires the Vendor to propose a host environment for the EIPAS Architecture that supports EEA‟s security, redundancy and responsiveness requirements. EEA also requires Vendors to offer alternate terms that would, at EEA‟s option, allow it to host the EIPAS System at ITD MITC. EEA requires the Vendor to propose a phased/modular implementation approach to the EIPAS Project, with each implementation phase supporting a particular function and/or adding to functionality developed in a previous phase. The Vendor must identify “quick hit” functionality (ies) to show immediate progress towards goals with clearly identifiable implemented solutions available within a year of Contract award. Ideally, each implementation phase should be 6 months or less in duration. Each implementation phase must have a plan for data cleansing, seamless data migration and application migration and transformation. The application migration and transformation plan must reflect business requirements based on EEA needs while maintaining legacy system functionality until full migration/transformation is complete, noting that many existing applications are part of existing integrated data systems. Together with training, knowledge transfer and documentation, these Vendor deliverables will empower EEA to achieve higherquality service and better environmental and energy outcomes faster and more effectively. Detailed requirements of the EIPAS Project specification are provided in this RFR in subsequent sections. In addition, Attachment 1: EIPAS Phase I Documents provides Vendors with additional detail regarding the scope, goals and objectives of the EIPAS implementation process.


Page 17 of 103

EEA encourages RFR responses from Vendors that include either or both custom and proprietary solutions; including turnkey commercial-off-the-shelf (COTS) and infrastructure-as-a-service (IaaS) solutions, Platform-as-a-service (PaaS) solutions, as well as software-as-a-service (SaaS) solutions, which may already meet many of the requirements of the EIPAS Project. The Vendor must meet the RFR requirements with respect to the configuration and customization to these existing products and services. In addition to complying with all legal requirements of this RFR, all existing systems and custom development must comply with requirements of this RFR including Appendices and Attachments.


Page 18 of 103

2.4

RFR Procurement Details Exhibit 2: Procurement Detail Summary RFR Name:

Energy and Environment Information and Public Access System (EIPAS) Phase II

RFR Number:

RFR -XX.

Purchasing Department:

Executive Office of Energy and Environmental Affairs (EEA)

Procurement Type:

Single Department Procurement

Acquisition Method:

The Contract will be a fixed-price Contract with a maximum obligation amount.

Procurement Category:

Information Technology – Related Equipment, Services and Supplies/Equipment, Software and Services – All Others not Shown or Combinations -

Procurement Management Team Contact Person:

Procurement Contact Person: Victoria Phillips Director, Enterprise Information Office MassDEP One Winter Street Boston, MA 02108 [email protected] The Procurement Contact Person will be the sole contact person for any issues pertaining to this RFR and this project.

Anticipated Duration of Contract and Renewal Options:

The maximum term of the Contract is five (5) years, plus 2` additional years maintenance support for a potential total of seven (7) years.

Number of Awards:

EEA will award a Contract to one primary Vendor. The primary Vendor may subcontract, but Subvendor participation may not exceed 80% of the total Contract value. Any subcontracts must be in writing, authorized in advance by EEA, and comply fully with the requirements set forth in Attachment 5: RFR Required Terms and Conditions, specifically with respect to Article 9 of the Commonwealth‟s Terms and Conditions.

Acquisition Method(s):

The Contract will be a fixed-price Contract with a maximum obligation amount. However, Vendors must provide hourly rates for resources that will be deployed in this engagement. EEA reserves the right to enter additional task orders with the winning Vendor for work included and/or necessarily related to but not expressly referenced in this RFR.

RFR Availability:

Vendors may access all information about this RFR, including updates, changes, and responses to questions, on the Commonwealth Procurement Access and Solicitation Site (Comm-PASS) at www.comm-pass.com.


Page 19 of 103

2.5

Number of Awards EEA will award a Contract to one primary Vendor. The primary Vendor may subcontract, but Subvendor participation may not exceed 80% of the total Contract value. Any subcontracts must be in writing, authorized in advance by EEA and comply fully with the requirements set forth Attachment 5: RFR Required Terms and Conditions, including, in particular, Article 9 of the Commonwealth‟s Terms and Conditions.

2.6

Acquisition Method(s) The Contract will be a fixed price Contract with a maximum obligation amount.

2.7

Contract Duration The maximum term of the Contract will be for five (5) years, plus 2 additional 2 year renewals for a potential total of nine (9) years. During the initial and the renewal terms, depending on the nature of the bid selected by EEA, the Vendor will provide a combination of maintenance, hosting, SaaS, PaaS or IaaS services.

2.8

RFR Procurement Calendar (estimated) The following table outlines the schedule for important procurement dates when the final RFR is released. Times are Eastern Standard/Daylight Savings (US), as applicable. Any changes in the Procurement Calendar that EEA makes after posting the RFR on Comm-PASS will not result in amendments to the Procurement Calendar. Such changes will appear only on the Solicitation‟s Summary tab and/or related ages on Comm-PASS (commpass.com). Vendors are responsible for checking the Solicitation‟s Summary Tab and related pages on Comm-PASS for Procurement Calendar updates. Exhibit 3: Procurement Calendar (Subject to Change)

These dates are illustrative until RFR is issued in final form Event Release of RFR on Comm-PASS EEA presentation and Q&A with Vendors Q&A start date: begin date for Vendor submission of written questions on CommPASS Q&A end date: deadline for Vendor submission of written questions on CommPASS Posting of answers to Vendor questions on Compass Deadline for RFR response submission (close date) Presentations by PMT selected Vendors

Date Friday October 4, 2013 Thursday October 10, 2013 Friday October 4, 2013

Monday October 28, 2013, at TIME

No later than Friday November 8, 2013 Noon, Friday November 29, 2013 Monday and Tuesday January 6th and 7th 2014


Page 20 of 103

EEA/Vendor prototype development exercise Prototype development exercise presentation Announcement of Apparent Successful Vendor on Comm-PASS Estimated Contract start date

2.8.1

Begins January 9th 2014 January 13, 2014 January 31 , 2014 or as soon as a determination is made April 2014 or as soon as a contract is signed

Access to Comm-PASS Online Bidder Forum The online Bidder Forum is the only means by which Vendors can ask written questions and receive written answers from the Procurement Management Team (PMT) regarding this solicitation with the exception of any questions asked during the EEA Presentations and Q&A Session. All questions and answers presented during the EEA Presentations and Q&A Session will also be posted on Comm-PASS. Vendors may ask questions only between the Q&A Start and End dates, when the Ask a Question link (located in the right-hand corner above the forum‟s Question/Answer tab) is available. Vendors are responsible for checking Comm-PASS for EEA‟s answers. Only finalized response(s) posted on a Bidder Forum will be binding on the Commonwealth. The most recent entry in a Forum‟s Summary tab indicates whether answers are final. Note that EEA will not accept – and will not respond to – any verbal or written questions submitted to the PMT outside of Comm-PASS Bidder Forum; this includes any other medium such as mail, fax, email, or voicemail. To reduce the number of redundant or duplicate questions, Vendors should review all questions previously submitted to determine whether the Vendor‟s question has already been posted by another Vendor. Vendors are responsible for entering content suitable for public viewing since all of the questions are immediately accessible to the public. Vendors must not include any information that could be considered personal, security sensitive, inflammatory, incorrect, collusory, or otherwise objectionable, including, but not limited to, information about the Vendor‟s company or other companies. The PMT reserves the right to edit or delete any submitted questions that raise any of these issues or that are not in the best interest of the Commonwealth or this Solicitation. To access the online Bidder Forum: Go to www.Comm-PASS.com.


Page 21 of 103

Select the “FORUMS” tab from the main navigation bar. Note: The “FORUMS” tab is separate from the “SOLICITATIONS” tab in Comm-PASS. When viewing this solicitation in Comm-PASS, you will not see a link to the applicable forum. Instead, you must separately search for it under the “FORUMS” tab. Select the “Search for a Bidder‟s Forum” link. Enter the Document Number appearing on the front of this document in the “Referenced Solicitation Number” field. Select the “Search” Button. Select the search results link appearing at the top of the Search page. Select the view icon (eyeglasses) to access the forum. There may be more than one bidder forum for a solicitation.

3.

INSTRUCTIONS FOR RESPONSE SUBMISSION 3.1

Bid Response Deadline All Bids must be received by EEA before the specified date, month, year and time displayed on the Comm-PASS Solicitation‟s Summary page, and Section 2.8 RFR Procurement Calendar within the Close Date field. Times are Eastern Standard/Daylight Savings (US), as applicable. LATE RESPONSES WILL NOT BE CONSIDERED.

3.2

Response Delivery Responses must be mailed or delivered by hand to EEA‟s Procurement Contact Person. All responses must be addressed and labeled clearly on the outside of the sealed packages as follows. Victoria Phillips Director, Enterprise Information Office Massachusetts Department of Environmental Protection One Winter Street Boston, MA 02108 [email protected] RE: Response to RFR ### EIPAS Phase II [Vendor Name]


Page 22 of 103

3.3

Response Format 3.3.1

Introduction All responses must comply with each of the following conditions. 3.3.1.a

Each Vendor‟s RFR response must include 2 (two)electronic copies (one PDF format and one in Microsoft Office format), 11(eleven) paper copies, and 1 (one) paper original of both the Technical Response and the Cost Response.

3.3.1.b

The Vendor‟s Technical Response and the Vendor‟s Cost Response must be submitted in separate envelopes, and clearly labeled in accordance with the response format instructions. Each Vendor response must include a SEPARATELY packaged, labeled, and sealed Technical Response and Separately packaged, labeled and sealed Cost Response. Package labeling should include the RFR number, type of response contained (Technical or Cost) and “RFR Response” on each package.

3.3.1.c

Text type must be a font size of at least 10 point. Text in tables and/or graphics may be smaller font size provided it is legible. Text in the Pricing Matrix and Requirements Table must be no smaller than 8 point.

3.3.1.d

The paper copies of the Vendor‟s response (both Technical and Cost) must be double sided on 8 ½ x 11” paper. The RFR response will be evaluated based on content, not length.

3.3.1.e

At least 1 paper copy of the Technical and Cost Responses, respectively, must contain originals of any documents that are signed by the Vendor‟s authorized signatory. The submission containing the originals of signed documents must be labeled clearly as “Original” on the cover. A Vendor must label all other paper copy submissions by a number from Copy 1 to Copy11. All packaging should be clearly labeled as “Technical Response” or “Cost Response.”


Page 23 of 103

3.3.2

3.3.1.f

Electronic files must be in Microsoft Word , Excel , or Project (versions 2000, 2007 or 2010) and PDF format on CD or DVD. Each jewel case or other wrapping for the electronic media must clearly indicate the name of the Vendor, RFR Name, RFR number, and “Technical Response” or “Cost Response.” Electronic files, Microsoft Office or PDF, must be named according to the convention given in RFR Attachment 2: Vendor‟s Response Checklist. The Microsoft Office Electronic files must not be encrypted, password protected, or otherwise restricted. Vendors must not format their responses to restrict or prevent EEA from printing or copying electronic copies in whole or in part.

3.3.1.g

All paper attachments to a response must be identified clearly and separated by tabbed dividers and all electronic files must be identified clearly.

3.3.1.h

Responses must not include videotapes, animation, audiotapes, software, or promotional information.

Technical Response Format The Technical Response contains all of the Vendor‟s response to the RFR EXCEPT cost and pricing information. No cost data may be in the Technical Response package. The Technical Response original, copies, and electronic version must be submitted in sealed packaging clearly labeled “Technical Response.” Maximum page limits referenced are for single-sided pages, so a maximum of 20 pages is equal to 10 double-sided pages of text. Page limits include all printable materials and attachments, figures, screen shots, and tables. Page limits are maximums, not minimums, and brevity is encouraged. The Technical Response should be presented in the order described below. 3.3.2.a

Cover Letter in response to Section 5.3: (2 pages)

3.3.2.b

Vendor Response Checklist in response to Section 5.2 using Attachment 2, Vendor‟s Response Checklist

3.3.2.c

Tables of Contents and Attachments


Page 24 of 103

3.3.3

3.3.2.d

Vendor Background in response to Section 8.1: (max. 15 pages)

3.3.2.e

Project Team and Key Personnel (including, but not limited to, resumes) in response to Section 8.3: (max. 50 pages)

3.3.2.f

Relevant Experience (including, but not limited to, references) in response to Section 8.2: (max. 15 pages)

3.3.2.g

Proposed Project Approach in response to Section 9.1.1: (no page limit)

3.3.2.h

Proposed Solution and Alternatives in response to all of Section 9.1.2 and Section 5.5 (no page limit)

3.3.2.i

Requirements Table per Section 5.4 using Attachment 4: Requirements Table

3.3.2.j

Assumptions, Qualifiers, and Constraints to Proposed Solution in response to Section 5.5.3: (max. 10 pages)

3.3.2.k

Proposed Master Service Agreement using Attachment 7: Master Service Agreement Template (no max.)

3.3.2.l

Proposed Initial Project Plan in response to Section 6.4.1: (30 page limit)

3.3.2.m

Task Orders , in response to Sections 6.4.2 and 6.4.3: (30 page limit)

3.3.2.n

Commonwealth Standard Forms, including but not limited to Standard Contract Form and Commonwealth‟s Terms and Conditions (executed by the Vender), located as Attachment 5: RFR Required Terms and Conditions.

Cost Response Format The Cost Response original, copies, and electronic version must be in a sealed package separate from the technical response and clearly labeled “Cost Response.” The Cost Response must follow the instructions provided in Section 5.7 and include, but not be limited to, a narrative and a completed Attachment 4: Pricing Matrix and Rate Table.


Page 25 of 103

3.4

Environmental Response Submission Compliance In an effort to promote greater use of recycled and environmentally preferable products and minimize waste, all responses submitted should comply with the following guidelines:

3.5

3.4.a

All copies should be printed double sided.

3.4.b

All submittals and copies should be printed on recycled paper with a minimum post-consumer content of 30% or on tree-free paper (i.e. paper made from raw materials other than trees, such as kenaf). To document the use of such paper, a photocopy of the ream cover/wrapper should be included with the response.

3.4.c

Unless absolutely necessary, all responses and copies should minimize or eliminate use of non-recyclable or non re-usable materials such as plastic report covers, plastic dividers, vinyl sleeves and GBC binding. Three ringed binders, glued materials, paper clips and staples are acceptable.

3.4.d

Vendors should submit materials in a format which allows for easy removal and recycling of paper materials.

3.4.e

Vendors are encouraged to use other products which contain recycled content in their response documents. Such products may include, but are not limited to, folders, binders, paper clips, diskettes, envelopes, boxes, etc. Where appropriate, Bidders should note which products in their responses are made with recycled materials.

3.4.f

Unnecessary samples, attachments or documents not specifically asked for should not be submitted.

Vendor Presentations/Demonstrations 3.5.1

Presentations In its sole discretion and at its option, the PMT may require Vendors to conduct presentations and/or demonstrations of their proposed solutions at EEA‟s offices in Boston and will provide relevant instructions to Vendors, as appropriate. EEA may limit the number of presentations and/or demonstrations requested. The purpose of presentations and/or demonstrations is to enable EEA to better understand and evaluate the solution proposed in the Vendor‟s RFR response. Failure to agree to a presentation and/or demonstration may result in the disqualification of a Vendor. The information EEA obtains from the presentations will be considered in the overall


Page 26 of 103

evaluation of the RFR responses. Key personnel proposed for the project should participate in any presentations and demonstrations. EEA reserves the right to apply restrictions to the structure and content of Vendors‟ product demonstrations and oral presentations. Demonstrations and presentations shall not be open to the public nor to any competitors, but any documentation submitted by Vendors will become part of the procurement file and therefore will become public records at the conclusion of the RFR process. EEA reserves the right to videotape the presentation, at their expense. The videotape will become public record at the conclusion of the RFR process. The schedule of the solution demonstrations and oral presentations will be arranged directly with the Vendors selected by the PMT. Vendors should have staff attend that possess the technical expertise to make modifications to the configuration of the product. Vendors must use publicly released products and operating systems in their demonstration. No pre-production products (e.g., “beta”) should be demonstrated. All Vendor-proposed and/or Vendorowned products used in the course of the demonstration must have been previously identified in the RFR response and must have been included and priced within the Cost Response. The demonstration must be completed in person, using the Vendor‟s laptop or remote system. The Vendor should be prepared to complete their demonstration using their equipment and identify all software tools utilized to complete the demonstration. In person oral presentations and/or demonstrations are to be given by the Vendor at EEA‟s office in Boston, Massachusetts (exact address to be provided to Vendors providing presentations and/or demonstrations). The demonstration audience will be the PMT and other appropriate agency staff. The PMT may be comprised of Commonwealth staff from multiple agencies and disciplines and will be able to evaluate the product from the perspective of all business and technical requirements. The demonstrations will be included in the evaluation criteria for the project and the demonstrations will contribute to the overall score given to the Vendor‟s RFR proposal. Failure of a Vendor to agree to a date and time or to appear at the scheduled time of the presentation may result in disqualification, reduction of points or other action that the PMT deems appropriate. THIS RFI AND ALL RESPONSES HERETO WILL BECOME PUBLIC RECORD EIPAS II RFI EEA-IT-2014-823

Page 27 of 103

3.5.2

Final Oral Presentations/Product Demonstrations of a Prototype Development Exercise In its discretion, EEA may invite the top one (1) to three (3) Vendors whose RFR responses have been judged competitive and responsive in the course of the PMT‟s evaluation process to participate in a facilitated oral presentation, including a prototype demonstration, of their proposed solution. During the prototype demonstration portion, Vendors will be asked to work with identified PMT members as the software is utilized to develop and modify the outcome defined in the scenario provided in Attachment 9 and to explain how they propose to provide the solution that will provide the functionalities required by the scenario, which also contains the flexibility to meet/adjust to EEA‟s evolving future business needs. The intent of the working session with EEA is to determine if the proposed solution meets the flexibility and agency required adaptability as defined in Attachment 9. The PMT may use these demonstrations and oral presentations to clarify aspects of the Vendor‟s RFR response or to inquire as to the Vendor‟s approach, recommendations, and experience and product maturation. The PMT may adjust their scoring of a prospective Vendor based on the Vendor‟s performance during production demonstration and/or oral presentation. EEA reserves the right to apply restrictions to the structure and content of Vendors‟ product demonstrations and oral presentations. Demonstrations and presentations shall not be open to the public nor to any competitors, but any documentation submitted by Vendors will become part of the procurement file and therefore will become public records at the conclusion of the RFR process. The schedule of the solution demonstrations and oral presentations will be arranged directly with the Vendors selected by the PMT. Vendors should have staff participate who possess the technical expertise to make modifications to the configuration of the product. Vendors must use publicly released products and operating systems in their demonstration. No pre-production products (e.g., “beta”) should be demonstrated. All Vendor-proposed and/or Vendorowned products used in the course of the demonstration must have been previously identified in the RFR response and must have been included and priced within the Cost Response. The demonstration must be completed in person, using the Vendor‟s laptop or remote system.


Page 28 of 103

The Vendor should be prepared to complete their demonstration using their equipment and identify all software tools utilized to complete the demonstration. In person oral presentations and/or demonstrations are to be given by the Vendor at EEA‟s office in Boston, Massachusetts (exact address to be provided to Vendors scheduled for presentations and/or demonstrations). The demonstration audience will be the PMT and other appropriate agency staff. The PMT may be comprised of Commonwealth staff from multiple agencies and disciplines and will be able to evaluate the product from the perspective of all business and technical requirements. The demonstrations will be included in the evaluation criteria for the project and the demonstrations will contribute to the overall score given to the Vendor‟s RFR proposal. Failure of a Vendor to agree to a date and time or to appear at the scheduled time of the presentation may result in disqualification, reduction of points or other action that the PMT deems appropriate.

4.

POST-RESPONSE PROVISIONS 4.1

Firm Offer; Duration; Response Withdrawal By submitting a response to the RFR, the Vendor agrees that its response is a firm offer and shall remain effective unconditionally for 365 days after the RFR Response Submission Deadline, unless EEA requests additional time. However, upon written notification to the Procurement Contact Person, a Vendor may withdraw its RFR response at any time prior to notification of the Contract award. 4.1.1

Procurement Cancellation EEA may notify Vendors on Comm-PASS at any time prior to the execution of the Contract, for any reason and without penalty, of the rejection of all RFR responses and the cancellation of the procurement. The notice need not state the reason for the cancellation. The PMT is not required to return any RFR responses if the procurement is cancelled.

4.1.2

Review and Evaluation Process The PMT will conduct a comprehensive and impartial evaluation of the responses received in response to this RFR. EEA reserves the right to alter the composition of the PMT or to designate other staff to assist in the evaluation process.


Page 29 of 103

EEA shall select the Vendor whose proposal, in the aggregate, provides the best value for EEA and the Commonwealth. Cost will be among several factors in this consideration; however, EEA is not required to choose the Vendor that proposes the lowest costs. EEA will not release any scores or evaluation information, such as the number of points that will be assigned to any item or the weight given to the Cost Response in relation to the Technical Response, prior to the Contract award. The PMT will evaluate all RFR responses in the manner described below. 4.1.2.1

Compliance with Minimum Submission Requirements EEA will complete an initial review of the RFR responses for the following administrative requirements. Should a RFR response be deemed incomplete, the PMT will determine, in its discretion, whether or not to request the additional information needed to fulfill the minimum requirements of the RFR. The criteria for meeting the minimum RFR Response submission requirements are as follows: 

Response has been received by the submission deadline



Response contains a sealed Cost Response separate from the Technical Response



Response contains all required documents



Technical Response does not include any cost information



All documents requiring an original signature have been signed and are included



Response complies with and does not alter the Commonwealth‟s Terms and Conditions and/or other required RFR Requirements, including but not limited to, Attachment 5: RFR Required Terms and Conditions and Attachment 6: Additional Contractual Requirements.

It is the Vendor‟s responsibility to ensure that all required materials are included in their Response. Failure to do so may cause rejection of the Vendor‟s response.


Page 30 of 103

The PMT will substantively evaluate the RFR responses that meet the minimum submission requirements in accordance with the evaluation criteria set forth in this section. The PMT will evaluate each RFR response on each requirement area and assign points based on the quality of the RFR response with respect to specific RFR requirements, as well as evaluate the RFR response as a whole regarding the likely performance of the proposed EIPAS solution. 4.1.3

Evaluation Criteria 4.1.3.a

Ability to Meet System Requirements and Vendor’s Technical Approach – The PMT will evaluate each RFR response to determine whether the response meets or exceeds the requirements for the EIPAS Project and whether the response demonstrates an understanding of the challenges and the ability to manage and satisfy the Project‟s requirements. This review will include, but is not limited to, an evaluation of the quality of the proposed technology architecture, integrated data architecture, application architecture, application development plan, migration/transformation plan, functional completeness, usability, performance, security, maintainability, ease of customization, potential project risks, and reliability, as well as the Vendor‟s approach to design, usability, quality assurance, risk management, and project management.

4.1.3.b

Alternative approaches –Vendors proposing alternative approaches or additional products/services which provide substantially better or more cost effective performance than achievable under the stated RFR requirements, or Vendors that propose discounts, uncharged services, or other benefits in addition to the RFR requirements may receive a preference or additional points with respect to this portion of the evaluation process, at the discretion of the PMT.


Page 31 of 103

4.1.4

4.1.3.c

Qualifications and References – The PMT will review the references and responses to evaluate each Vendor‟s ability to meet the requirements of the RFR based on each Vendor‟s experience with projects similar in size and scope; the Vendor‟s past track record for delivering similar services on time and within budget; and the qualifications of the proposed Vendor program manager and project staff. The PMT will use the information to evaluate each Vendor‟s ability to complete the EIPAS solution on time (or on an accelerated time basis), furnish logical timelines, establish and maintain communications with their customers, monitor project progress, assess/mitigate risk, and develop contingency plans where needed. The PMT will assess the Vendor‟s ability to understand their customers‟ needs and their technical ability to fulfill them.

4.1.3.d

Overall Cost – The PMT will evaluate the Cost Responses for overall cost to the Commonwealth over the term of the Contract, and/or on an accelerated Contract term.

4.1.3.e

Supplier Diversity Plan (SDP) (formerly Affirmative Market Plan) – In accordance with Commonwealth guidelines as described in Supplier Diversity Program Plan, SDP participation will account for no less than 10 percent of the total available evaluation points. Vendors must submit SDP Plan Forms that evidence significant and measurable commitments to SDP Plans.

Disqualification of Responses The following section identifies the criteria by which EEA will disqualify the Vendor‟s response: 4.1.4.a

Late Responses – The PMT will disqualify late responses.

4.1.4.b

Inclusion of Costs in Technical Response – The PMT may disqualify any RFR response that contains costs, or information sufficient for the PMT to identify or calculate costs, as part of the Technical Response.


Page 32 of 103

4.1.5

4.1.4.c

Noncompliance of Response – The PMT may disqualify any RFR response that it determines to be non-responsive to, or that fails to comply with, material or mandatory terms, specifications, or requirements of the RFR (including, but not limited to, the instructions governing the submission or format of responses), unless the PMT determines that the non-responsiveness is insubstantial, in which case the PMT may seek clarification of the response from the Vendor prior to full RFR response evaluation. A request by the PMT for clarification of a response should not be construed as a waiver by the PMT to deem, in its discretion, that the Vendor‟s RFR response should be disqualified for failure to satisfy minimum requirements of the RFR.

4.1.4.d

Debarred Vendor or Subcontractor – The PMT may disqualify any response submitted by a Vendor who is subject at that time to any state or federal debarment order or determination, or any response that designates a subcontractor subject to any such order, including, but not limited to, an order or determination under Executive Order 147, MGL Chapter 152, Section 29F and MGL Chapter 152, Section 29C. If the Vendor replaces the designated subcontractor without a material effect on the Vendor‟s response, the PMT may give the Vendor the opportunity to select another subcontractor prior to Contract execution.

4.1.4.e

Correction and Clarification of Responses - In its sole discretion, the PMT may determine whether noncompliance with any of the above requirements is insubstantial. In such cases, the PMT may seek clarification, allow the Vendor to make minor corrections, reflect the deficiency during the evaluation, or apply a combination of all 3 remedies. The PMT will retain full discretion to allow corrections or clarifications to a response.

Contractor Selection and Notice of Award The PMT will notify the apparent Successful Vendor in writing. No Vendor may make any public announcement concerning its selection for the Contract prior to EEA‟s release of that information on Comm-PASS.


Page 33 of 103

Notice to a Vendor that it has been awarded the Contract does not constitute acceptance of all the terms of a Vendor‟s RFR response by EEA and does not impose any Contractual obligation on EEA. Contract award is contingent upon the successful conclusion of negotiations and EEA‟s Contract execution with the Vendor.

5.

RFR TECHNICAL AND COST RESPONSE CONTENT AND FORMAT 5.1

Overview The purpose of the RFR is to obtain detailed information from each Vendor that will enable the PMT to determine which proposed solution will provide the Commonwealth with the best value. To accomplish this end, each Vendor must submit all documents listed in Attachment 2 : Vendor„s Response Checklist. Each RFR response must be clear, complete, and sufficiently detailed to enable the PMT to determine if the Vendor is qualified for and capable of developing and implementing the EIPAS solution. Responses must be focused and must not contain unrequested information or sales or public relations material. Responses must be unambiguous and must address the requirements directly. Failure to abide by these guidelines may result in the disqualification of the RFR response. EEA reserves the right to reject any and all RFR responses that are non-responsive. Vendors‟ RFR responses must include all of the information required in this RFR and all Appendices and Attachments. NOTE: EEA‟s intent is that the EIPAS solution will meet all of the functional objectives identified in Attachment 1: EIPAS Phase I Documents. Vendor‟s RFR response must address all mandatory requirements set forth in this RFR, as written, or the Vendor may present in its RFR response alternatives that provide for the substantially equivalent functionality that fully meet the objectives of this RFR, Appendices and Attachments. While Vendors may propose alternative methods of achieving the requirements other than those specified in this RFR, Vendors may present such alternatives only in the manner specified through this RFR. EEA has provided high-level solution requirements in this RFR, Appendices and Attachments with the expectation that, after Contract award, the Vendor will refine these highlevel requirements and create detailed requirements and technical specifications, as governed by Task Orders, during the design phases of the project. Throughout their Technical Response, Vendors must reference the specific requirements being addressed in this RFR. Such references must include the


Page 34 of 103

specific section and/or page number in this RFR, Appendices and Attachments. 5.2

Vendor’s Response Checklist Attachment 2:Vendor‟s Response Checklist specifies all the items that the Vendor must include in the RFR Technical and Cost Response. As part of the response, the Vendor must submit a completed copy of the Vendor Response Checklist indicating on the checklist itself that the Vendor‟s RFR Response includes every item. This checklist should be submitted with both the Technical Response and the Cost Response.

5.3

Technical Response Cover Letter The Vendor must submit a cover letter with the Technical Response. The cover letter must be completed on the Vendor's letterhead, signed and dated by the Vendor‟s representative who is authorized to execute Contracts on behalf of the Vendor, and should not exceed two (2) pages. The cover letter will serve as a transmittal letter for the Technical Response, and must state that the Vendor agrees to the terms of this RFR.

5.4

Attachment 3: Requirements Table & Narrative Technical Response In their response to this RFR, Vendors must complete Attachment 3: Requirements Table. This document lists, by section and/or page number, all the technical requirements contained in this RFR, Appendices and Attachments. The intent of the Requirements Table is to ensure that Vendors submit information that is responsive to all RFR, Appendices and Attachment requirements, which fully explain the unique aspects of each Vendor‟s proposed approach and solution Vendors must indicate in the Attachment 3, Requirements Table, whether their proposed solution will meet the functional objectives of the requirement as stated or whether the Vendor will provide an alternative that can fully meet the functional objectives of the requirement in a different manner than that specified in the RFR. Vendors proposing alternative solutions/capabilities must follow the instructions in RFR. The Vendor is also expected to provide a narrative response customized to the EIPAS Project. The Vendor‟s technical narrative response should be organized by Section and/or page number and should be brief and customized to the RFR. Generic system or company literature will not be considered an acceptable response except as supplemental material to the customized narrative.


Page 35 of 103

5.5

Alternatives to Technical Requirements 5.5.1

Alternative Project Timeline EEA requires that all Vendors propose solutions that support all the detailed specifications and functional objectives described in this RFR, Appendices and Attachments. EEA is anticipating and planning for a project which is five (5) years to completion. EEA recognizes, however, that a Vendor may have an alternative approach which could minimize the project time to three - four (3-4) years. The Vendor may propose an ADDITIONAL, alternate solution which proposes a shorter alternative timeframe. Any such alternative approach must be described in comparison to the mandatory requirements set forth in this RFR and documented in Attachment 3: Requirements Table and Attachment 4 – Pricing Matrix and Rate Table.

5.5.2

Alternative Approach to a Technical Requirement Vendors may propose more than one way to meet any one specific requirement. However, Vendors must clearly explain how the alternative approach to the requirement meets all elements of the stated requirement, and all advantages and/or disadvantages of the alternative(s). All proposed alternative approaches to meet requirements must be clearly identified in Attachment 3 Requirements Table and Attachment 4 – Pricing Matrix and Rate Table. Vendors may submit alternative responses that include, but are not limited to, custom build, COTS solutions and/or a combination thereof, which the Vendor‟s experience indicates will provide a functionally equivalent, better than, and/or more cost effective that is also responsive to the RFR‟s requirements. Vendor alternatives may also include related commodities or services that may be available to enhance system performance during the term of the Contract. EEA will evaluate any alternative(s) proposed by Vendors in response to this RFR in relation to how/whether and to what extent the proposed alternative(s) meet, or exceed, the system requirements and the business goals of EEA, at an equivalent or reduced cost that provides the best value to the Commonwealth.

5.5.3

Assumptions, Qualifiers, and/or Constraints of Proposed Solution Vendors must clearly disclose all assumptions (e.g., expected level of EEA effort, roles, resources, and scope issues), qualifiers (e.g., functionality limits on certain transactions), and/or constraints (e.g.,


Page 36 of 103

maximum number of reports, forms, notices, types of correspondence, workflows, or rules included with the solution) that Vendors utilized to develop their responses to this RFR. In particular, Vendors must describe with specificity the specific EEA roles required for particular phases of the project. For all assumptions, qualifiers and/or constraints identified in the responses, Vendors must: (a) identify in their response the corresponding requirement(s) from the RFR or its attachments, (b) provide a description of the assumption(s) used, and (c) indicate the significance or impact to the project as a result of such assumptions, qualifiers and/or constraints, including, but not limited to, any impacts to the Vendor‟s proposed costs for the project. EEA is not required to accept, reject or otherwise respond to any Vendor assumptions, qualifiers and/or constraints during its review of RFR responses. In the event that the apparent successful Vendor has included any of the above-referenced limitations as part of its RFR response, EEA will revisit these issues during the negotiations preceding final Contract award. 5.6

Master Service Agreement Attached to this RFR as Attachment 7 is a Master Service Agreement (MSA) Template. The Vendor‟s RFR response must include the submission of the draft completed version of the Master Service Agreement in REDLINE for EEA‟s review and consideration as part of the Vendor‟s Technical Response Proposal. As part of their RFR Response, Vendors should also submit a copy of the their standard agreement for managed services (if such services are being proposed as a component of the RFR response), which will be negotiated and incorporated into the Master Service Agreement. After Contract award, and at EEA‟s discretion, the MSA may also include any negotiated terms and a finalized version of the Vendor‟s high-level project plan with deliverables, dates and scheduled payments. The final MSA will become part of the Contract.

5.7

Vendor’s Cost Response The RFR Response will be based on a fixed price for the creation of the EIPAS system. Ongoing maintenance and support for the system as a


Page 37 of 103

whole, for COTS components, or cloud services will be paid on a fixed rate basis. In addition, Vendors must provide hourly rates for all resources to be deployed on this engagement. EEA reserves the right to expand the scope of the Contract to include additional tasks and deliverables included and necessarily related to this RFR but not explicitly referenced in this agreement. After execution of the Contract, payments to the Vendor will be made on the basis of an agreed upon payment schedule, and, in the case of the service required to create EIPAS, upon EEA‟s receipt, and acceptance of, project plan deliverables once all project plan components have been finalized by EEA and the successful Vendor. COST INFORMATION SHOULD NOT BE INCLUDED IN THE TECHNICAL RESPONSE SUBMISSION. INCLUSION OF COSTS IN THE TECHNICAL RESPONSE SUBMISSION ARE GROUNDS FOR IMMEDIATE DISQUALIFICATION. 5.7.1

Cost Response Narrative The Vendor is expected to provide a cost response narrative with the Vendor‟s RFR submission of Attachment 4: Pricing Matrix and Rate Table, customized to the EIPAS Project. The Vendor‟s narrative response should be organized by Section and/or page number and should be brief and customized. Generic system or company literature will not be considered an acceptable response except as supplemental material to the customized narrative.

5.7.2

Pricing Matrix and Rate Table In the Cost Response, Vendors will present their pricing proposal by completing and submitting Attachment 4: Pricing Matrix and Rate Table. Vendors must present cost breakdown for the EIPAS solution by component/by module, as well as by Contract year. In presenting the Cost Response, each Vendor‟s pricing must be itemized by the categories in the Attachment 4: Pricing Matrix and Rate Table to aid the PMT in comparing Cost Responses. Note that all licensing, hosting, and maintenance costs must be itemized by Vendors. All costs must be included and Vendors must explain any assumptions used to allocate costs between the categories. Because Vendors will bring different technical approaches in their RFR responses, deliverables will be in part Vendor-specific based upon the proposed solution. Therefore, each Vendor will identify and describe their specific deliverables and timing of delivery in their proposed initial project plan. In the Cost Response narrative, each Vendor will also identify the major deliverables for their proposed system that will trigger a payment once the deliverable is


Page 38 of 103

finally accepted by EEA after any required testing, modification, and re-testing. Vendors will provide in their Cost Response the price for each major deliverable identified in their initial project plan. Vendors must also include Maintenance and Support costs (for COTS solutions) and, based on the type of their response, SaaS, IaaS or PaaS fees as part of the Cost Response. Vendors must describe the key features of their maintenance and support plan in their technical response, including, but not limited to, their proposed performance objectives required in providing maintenance and support costs. In the Cost Response, Vendors must include in Attachment 4: Pricing Matrix and Rate Table a rate schedule that specifies a fixed cost for maintenance and support services (hours per year) for the completed system. Vendors must determine the size of the fixed cost based on the number of hours required to provide the required maintenance and support functions. Hours that are not used for the maintenance and support functions in each year may be used, at EEA‟s discretion and direction, for changes or other support functions for the system, or these hours may be carried over into the next Contract year to be utilized for maintenance/support services. (After Contract award, EEA, in its discretion, may also add to maintenance/support hours at any time during the Contract term to support additional changes or other support for the implemented system). The maintenance, support and hosting proposal plan must extend from the date of expiration of the one year warranty period following EEA‟s final acceptance of the completed system and terminate at the end of the contract term and include all extensions. The Cost Response (must specify the cost to EEA for each year (or portion of year)) that the maintenance, support and hosting plan is in effect through the remaining time period of the Contract including all contract extensions. Further details regarding the Vendor‟s maintenance support and hosting plan, including the cost of the plan per Contract year for the completed system, will be negotiated by EEA and the successful Vendor prior to the final execution of the Contract. 5.7.3

Retainage EEA will retain 10% of the total amount due to the Vendor on each invoice related to the creation of EIPAS for implementation/installation services. EEA will retain these amounts whether or not the Vendor‟s performance is timely or the


Page 39 of 103

deliverable has met all of the requirements for acceptance. Retainage is excluded for the amount due for hardware, COTS software components provided by any third party (any person or entity other than the Vendor or its affiliates) or cloud subscription agreements. EEA will release all of the retained amounts for system design and development upon final written acceptance of the completed project, including any training, documentation and knowledge transfer deliverables. After the system has been completed, EEA will release all of the retained amounts for each Commonwealth fiscal year at the time of the last performance review for said fiscal year described in this RFR, under Vendor Performance Evaluation, Section 7.4, subject to the outcome of the review. If the terms of the Contract are not met to EEA‟s satisfaction, EEA will keep the amount(s) retained. Acceptance of Vendor deliverables shall not be unreasonably withheld by EEA. 5.7.4

Labor Rate Table As part of its Cost Response, Vendors must also provide a per-hour rate table for all individuals/roles proposed for the project. These rates must be provided for the full five year Contract term, as well as for the accelerated Contract term, and include rate increases if applicable. Vendors will use Attachment 4: Pricing Matrix and Rate Table as the template for presenting the labor rates, expanding the table as needed for each resource. EEA reserves the right to expand the scope of the Contract to include deployment of Vendor resources at an hourly rate to accomplish tasks and deliverables related to but not expressly referenced in this agreement.

5.8

Standard Forms and RFR Requirements The Commonwealth‟s standard RFR requirements, as well as mandatory standard Contract forms that Vendors must complete and submit as part of their Technical Response, are located in Attachment 5. In addition, the Vendor must agree in the RFR Response to adhere to the additional Contractual Requirements found in Attachment 6 to this RFR. The required forms, and instructions for their completion, appear in Attachment 5: RFR Required Terms and Conditions.

5.9

Executive Order 515, Establishing an Environmental Purchasing Policy Products and services purchased by state agencies must be in compliance with Executive Order 515, issued October 27, 2009. Under this


Page 40 of 103

Executive Order, Executive Departments are required to reduce their impact on the environment and enhance public health by procuring environmentally preferable products and services (EPPs) whenever such products and services perform to satisfactory standards and represent best value, consistent with 801 CMR 21.00. In line with this directive, all Contracts, whether departmental or statewide, must comply with the specifications and guidelines established by OSD and the EPP Program. EPPs are considered to be products and services that help to conserve natural resources, reduce waste, protect public health and the environment, and promote the use of clean technologies, recycled materials, and less toxic products. Questions concerning the Executive Order or the appropriate specifications may be directed to OSD‟s EPP Procurement Program, www.mass.gov/epp. The Order can be seen at: www.mass.gov/governor/legislationeexecorder/executiveorder/executive -order-no-515.html. 5.10

Environmental Plan Beginning the first year of the Contract and throughout the life of the Contract, awarded Vendors must agree to work with the EEA Program Management Team to examine the feasibility of implementing an environmental plan. The objective of this requirement is to actively encourage suppliers to incorporate sustainable practices throughout their business operations and further market such practices to Contract users. Such a plan may include, but not be limited to, the following: Implementing energy efficiency initiatives at the corporate level in line with Executive Order 484, such as lighting retrofits, purchase of energy from renewable sources, use of bio-heat fuel, and other energy reduction technologies. Encouraging environmental initiatives at a corporate and/or manufacturing level for the purpose of reducing the impact of manufacturing on the environment; such as clearly identifying recycled content of packaging on the packaging, providing product life cycle assessments, working toward the elimination of ozone depleting chemical usage in the manufacturing or refining process (where applicable), and conducting internal environmental auditing related to pollution control. Adopting standards and/or obtain certifications, where applicable, for product development and manufacturing processes such as but not limited to, LEED, ISO 14001, Cradle to Cradle (C2C) Protocol, Green Seal, Environmental Choice, and others.


Page 41 of 103

Using alternative fuel vehicles for delivery or transportation purposes and/or vehicles equipped with diesel emission control devices and operating such vehicles with guidance on anti-idling initiatives. Working with the Program Management Team to develop and distribute information and/or materials to Commonwealth customers on the Awarded Vendor‟s environmental practices and initiatives throughout the term of the Contract. Developing a plan to implement the recycling of materials used or produced in normal business operations. The PMT may award points to Vendors who provide evidence that measures and initiatives such as these are already in place within their operations, and/or for written proposals submitted with their Response detailing a commitment to action contingent upon receipt of a Contract award. (See the Additional Environmentally Preferable Products / Practices form on Comm-PASS).

6.

EIPAS PROJECT IMPLEMENTATION PLAN 6.1

Phased Implementation Approach to Project In the RFR Technical Narrative Response, the Vendor must describe how it will structure delivery of the solution in an incremental and iterative manner, without jeopardizing EEA‟s business and technical operations. Vendors must identify and describe implementation approaches that minimize the degree of coding changes to the existing the legacy systems while they are being migrated and transformed onto the new EIPAS architecture. The staggered retirement of legacy systems should be a significant factor in prioritizing implementations to limit the overall support burden on EEA/IT. In the RFR response utilizing the Attachment 3: Requirements Table and in the Technical Response Narrative, the Vendor must affirm that they will comply with these requirements and describe their process for achieving the following: 6.1.a

EEA requires an incremental implementation of EIPAS to mitigate the risk of waiting for  and the potential failure of  an entire solution. Instead of starting with development of a complete core architecture, the Vendor must achieve quick wins to show progress.


Page 42 of 103

6.2

6.1.b

Each stage of development must include only those core foundation capabilities required to support specific requirements of the current Task Order(s). Each phase must result in expanded functionality and will serve as an additional proof of concept for selected technologies and architectures.

6.1.c

EEA envisions that the first phase of development will support permitting functions and online portals. Later in the development of EIPAS, the Vendor must develop new applications that migrate/transform the functionality of the 100+ existing EEA applications listed in Attachment 8: Application List with Screenshots.

6.1.d

During the course of this Contract, EEA reserves the right to modify the list of applications to suit changing business needs. EEA will collaborate with the Vendor to ensure that the new application(s) do not increase the level of required effort.

6.1.e

The Vendor must carry out each Task Order with an understanding that the deliverables must become a stepping stone for delivery of future business components and applications. Early Task Orders may deliver components that have limited functionality, with the assumption that future Task Orders will expand their capabilities. It is equally important that all deliverables do not impede the implementation of other functionality required to satisfy the Contract.

Means to Demonstrate Success Quickly In the RFR Technical Narrative Response, the Vendor must indicate how the project will be designed to demonstrate success quickly. Foundational projects and the initial applications targeted for migration will take time to properly plan and implement. The Vendor must pair these activities with discrete, achievable quick win projects that show progress and serve as proofs of concept of the selected technologies and architectures. The selection of quick win projects should take into consideration the competing EEA resource needs to maintain legacy systems while new EIPAS functionality and applications are developed. 6.2.a

In the RFR Technical Response Narrative, the Vendor must describe the methods by which it will have clearly identifiable functions in production use within/before one year after Contract Execution.


Page 43 of 103

6.3

Roadmap In the RFR Technical Narrative Response, the Vendor must explain how it would execute/modify the roadmap as described in the EIPAS Phase I Documents Attachment 1 to meet the needs of EEA as identified in this RFR, Appendices and Attachments.

6.4

Project Planning 6.4.1

Project Plan The EIPAS Project will be governed by a project plan based on task orders. The Vendor must develop and submit all project schedules using Microsoft Project 2010. The Vendor must change to a new version of Microsoft Project when and only when EEA requests or agrees to such a change.

6.4.2

6.4.1.a

In the RFR Technical Response Narrative, the Vendor must propose a draft project plan for all components of the EIPAS Project for the duration of the project lifecycle.

6.4.1.b

In the RFR Response, the Vendor must describe the process and rationale by which the Vendor developed the plan and any assumptions qualifiers and constraints of the project plan.

Task Orders – Required Components The project plan will be implemented through a series of task orders. In the RFR Technical Narrative Response, the Vendor must ensure, at a minimum, that each task order includes the following components: 

Deliverable Name



Deliverables



Estimated duration, with begin date and due date



Due date plus 10 business days



Indication if this Deliverable is concurrent with another Deliverable and the Name of that Deliverable



Description and Metric of Acceptance



Vendor and EEA resources responsible for each component



Vendor and EEA Responsibilities


Page 44 of 103



6.4.3

Phase gates for each set of formally defined activities, work products and artifacts

Task Orders – First Year Requirements As part of the RFR Response the Vendor must propose the first year‟s set of Task Orders, based on a detailed and thorough understanding of EEA‟s requirements as presented in this RFR, Appendices and Attachments. EEA anticipates that several concurrent Task Orders are required for Project Year 1. 6.4.3.a

In the RFR Response, the Vendor must propose multiple tasks that will encompass the work required for year 1 of the EIPAS Solution, and will meet EEA‟s requirement of having clearly identifiable functions in production use within/before one year of Contract execution. Vendor‟s Task Order 1 must encompass the activities necessary to establish the EIPAS solution‟s foundation, structure and traceability.

6.4.3.b

In addition to complying with the minimal requirements for all Task Orders set forth in subsection 6.4.2 above, the Vendor must provide a narrative description of the following components for the first year‟s proposed task orders.

6.4.3.c

Describe how the Vendor will validate the assumptions that the Vendor relied upon to develop the proposed solution.

6.4.3.d

Describe how the Vendor will ensure bidirectional knowledge transfer occurs between the Vendor and EEA throughout the project.

6.4.3.e

Describe Vendor‟s proposed kick off for the EIPAS project.

6.4.3.f

Describe Vendor‟s proposed Installation of project management tools, processes, and procedures.

6.4.3.g

Describe the proposed development, in coordination with the established EIPAS program governance, a SOA Governance Framework.

6.4.3.h

Identify and revisit project risks and reaffirm and refine mitigation strategies.

6.4.3.i

Validate proposed project scope and recommend adjustments, indicating their potential impact on costs.


Page 45 of 103

6.4.4

6.4.3.j

Validate the proposed project plan, staffing plan, and facilities requirements.

6.4.3.k

Propose how to develop, in conjunction with EEA, a data migration, cleansing and synchronization strategy that takes into account the existing relationships (data exchanges) between some existing applications and business component development strategy.

6.4.3.l

Identify what Business component(s) – or subsets thereof – will be addressed, in the first year of the Project, (business components are described in Section 9.3 and Attachment 1 EIPAS Phase I Documents).

6.4.3.m

Identify what application(s) that are listed in Attachment 8: Applications List with Screenshots will be addressed in the first year of the Project and how the Vendor will manage concurrent environments to support the EIPAS implementation phase (2.3.1) of 6 months or less in duration.

6.4.3.n

Describe how each successive Task Order will ensure Integration with the results/functionalities developed through previous/concurrent Task Orders.

6.4.3.o

Develop an EIPAS Project Communication Management Plan that is applicable both within each Task Order and across all Task Orders as a whole.

Risk Management Plan In the RFR Technical Response Narrative, the Vendor must identify the top ten issues that the Vendor believes represents a risk to the project's success in terms of schedule, cost, scope, and/or quality. The Vendor must provide a plan in the RFR Technical Response Narrative that describes its approach for avoiding and/or mitigating each of these risks over the life of the project. This plan will be reviewed and refined during the Project lifecycle. Note: all cost details associated with the Risk Management Plan should be defined ONLY in Attachment 4: Pricing Matrix and Rate Table.

7.

PROGRAM MANAGEMENT 7.1

Adherence to CommonWay In the RFR response, the Vendor must affirm their adherence to the CommonWay Methodology, described in this Section.


Page 46 of 103

During the term of the Contract, the Vendor must implement CommonWay, the Commonwealth and EEA project management methodology, including its practices, forms, and other components. In the event that the Vendor wishes to provide services above and beyond what CommonWay supports, the Vendor may provide supplementary materials, given EEA approval. A description of the CommonWay methodology is available at the following link: https://wiki.state.ma.us/confluence/display/commonwaylite/CommonWa y+project+Management+Methodology 7.1.a

All project plans must implement CommonWay forms and procedures as much as possible. For more information on these templates, refer to: https://wiki.state.ma.us/confluence/pages/viewpage.action?pa geId=69894234

7.1.b

In particular, the Vendor must use CommonWay templates in the following sub sections:

7.1.c

The Vendor must employ and keep up to date the RACI Chart (available at https://wiki.state.ma.us/confluence/download/attachments/6989 4234/RACI+Sample.pdf?version=2&modificationDate=1259597781 000) to specify the entities who must be responsible, accountable, consulted, and informed over the course of the EIPAS project.

7.1.d

The Vendor must employ and keep up to date a Risk Register in CommonWay format (available at https://wiki.state.ma.us/confluence/download/attachments/6989 4234/Risk+Management+Plan+SAMPLE.pdf?version=1&modificati onDate=1253731664000)

7.1.e

The Vendor must employ the Weekly and Monthly Status Reports (available at https://wiki.state.ma.us/confluence/download/attachments/6989 4234/Weekly+Status+Report.doc?version=4&modificationDate=13 22688450000 and https://wiki.state.ma.us/confluence/download/attachments/6989 4234/Monthly+Status+Report.doc?version=6&modificationDate=1 267111894000)


Page 47 of 103

7.2

7.1.f

The Vendor must employ the Capital Budget Report format (available at https://wiki.state.ma.us/confluence/download/attachments/6989 4234/Capital+Budget+Sample.pdf?version=1&modificationDate= 1267048097000

7.1.g

The Vendor must employ the Change Management Plan format (available at https://wiki.state.ma.us/confluence/download/attachments/6989 4234/ChangeManagementPlanSample.pdf?version=2&modificati onDate=1256654292000)

Vendor Program Manager Qualifications and Responsibilities The successful Vendor will be required to comply with the following section. For the EIPAS project, the Vendor must appoint a Program Manager who must be responsible for comprehensive oversight and day-to-day management of the project throughout the life of the project. The Program Manager must have at least five to seven years of experience managing enterprise-level software development and integration projects. In addition, it is desirable that the Program Manager have the Project Management Professional (PMP) certification from the Project Management Institute (PMI). 7.2.1

Responsibilities In addition to the program management obligations imposed by the MSA, the Vendor‟s Program Manager will: 7.2.1.a

Be responsible to EEA‟s EIPAS Program Manager for the day-to-day management of this project and the EIPAS project goals.

7.2.1.b

Drive achievement of the EEA EIPAS Project goals as defined in this RFR, Appendixes and Attachments and MSA.

7.2.1.c

Be directly responsible for comprehensive oversight of the project.

7.2.1.d

Serve as the main interface between EEA EIPAS Program Manager and all Vendor personnel participating in this engagement.

7.2.1.e

Manage and encourage identification and timely resolution of project issues, including problem escalation within the Vendor‟s organization.


Page 48 of 103

7.2.2

7.2.1.f

Develop and Manage the project plan, in collaboration with the EEA EIPAS Program Manager, making changes as required based on information gathered during status meetings.

7.2.1.g

Be responsible for administering this Contract and the comprehensive oversight and day-to-day management throughout the life of the Project under this Contract.

7.2.1.h

Be responsible for the management and deployment of Vendor personnel

Communications The Vendor Program Manager is responsible for initiating and facilitating timely EEA EIPAS Project -Vendor communication:

7.2.3

7.2.2.a

The Vendor must develop a Communications Management Plan (as part of the initial project plan and initial task orders) that details the mode, frequency, and content of project communication.

7.2.2.b

The Vendor must maintain regular contact with the EEA EIPAS Program Manager and the EIPAS Project Managers in person and via telephone, email, conference calls, and teleconferencing/webinars.

7.2.2.c

The Vendor must issue invitations to key meetings at least three (3) days in advance, specifying the date, time, and location, as well as including an agenda listing the topics, purpose, and desired outcomes.

7.2.2.d

The Vendor must report on project status as described in and as specified by CommonWay.

7.2.2.e

The Vendor must give notice of requirements for EEA resources no less than five (5) business days in advance of the event requiring EEA support.

Refinement of Project Plan During the course of the project, the Vendor‟s Program Manager shall collaborate with the EEA EIPAS Program Manager on refinement of the initial project plan, including but not limited to: 7.2.3.a

Specifying all tasks required to implement each feature and each deliverable.


Page 49 of 103

7.2.4

7.2.3.b

Performing a stakeholder analysis to ensure participation of all key EEA personnel.

7.2.3.c

Developing a detailed schedule in collaboration with the EEA EIPAS Program Manager.

7.2.3.d

Updating the project schedule to account for new levels of detail during project implementation.

Change Orders As work progresses, a need for a change of scope or function may arise. At that point, the EEA EIPAS Program Manager may suggest the change in writing to the Vendor Program Manager. Similarly, the Vendor Program Manager may present a written request for a change in scope to the EEA EIPAS Program Manager. Together, the two Program Managers must determine how the change impacts the schedule and costs. If both Program Managers agree on the change, they must write a Change Order and submit it to the EEA Executive Sponsors. The Program Managers must receive written approval from the Executive Sponsors before commencing any change. The process for the submission and acceptance of Project Change Orders will be set forth in more detail in the MSA.

7.3

Project Documentation Repository During the term of the Contract, the Vendor shall maintain a library of all project documentation, including the full contents of this RFR; the project schedule; identification and contact information of team members; all status reports, change orders, meeting agendas, and minutes; and any other documentation the EEA EIPAS Program Manager deems necessary. The Vendor shall store all these documents in the EEA‟s internal SharePoint content management architecture. Upon Contract execution, the Vendor shall identify any personnel who require access to the repository.

7.4

Vendor Performance Evaluation During the course of the Contract, EEA will evaluate the Vendor‟s performance based on the following factors, at a minimum. 

Adherence to the terms of the Contract, including prescribed due dates and budget



Quality of deliverables



Reliability of the system


Page 50 of 103

7.4.1



Timeliness of corrections



Effectiveness of the Vendor‟s Program Manager



Flexibility of Vendor



Demeanor when dealing with EEA personnel



Responsiveness to EEA requests or complaints



Timeliness and accuracy of invoices



Commitment to the Vendor‟s Supplier Diversity Program (SDP) Plan

7.4.a

EAA requires that the Vendor‟s Program Manager meet at least quarterly with EEA‟s Program Management Team to review the Vendor‟s performance. EEA will use these evaluation meetings to make determinations regarding the payment of retainage.

7.4.b

EEA will identify specific performance and reliability criteria for the system in consultation with the successful Vendor and incorporate these into the MSA.

7.4.c

Please note that the Vendor‟s Supplier Diversity Program Plan commitment is subject to audit by EEA. The Vendor must submit reports to EEA‟s Program Manager on a timely basis and they will be used in the quarterly evaluation process. If the dollar amount or percentage of use reported is less than the commitment, the Vendor must provide EEA with an explanation that demonstrates the Vendor‟s diligence in attempting to meet the commitment.

Personnel Replacement The EEA EIPAS Project Management Office (PMO) reserves the right to require that the Vendor replace key Vendor personnel if the EEA EIPAS PMO judges that: 

Any individual does not perform at the skill level required to meet Contract specifications.



Any individual‟s work does not conform to the performance standards stated in the Contract.



Any individual does not regularly respond to requests and questions – especially with respect to issues raised in the status meetings – to the satisfaction of the EEA EIPAS Program Manager and Executive Sponsors.



Personality conflicts hinder effective execution of the Contract.


Page 51 of 103



8.

The individual does not conform to the Commonwealth‟s standards for workplace conduct.

VENDOR QUALIFICATIONS EEA requires that the Vendor selected for the EIPAS project has the financial and organizational strength to successfully complete the work involved over the course of the Contract. Therefore, each Vendor must provide the information listed below about its organization. EEA requests that Vendors limit the use of marketing materials when responding to these requirements. The Vendor must also provide the identical information for each of its significant Subvendors, which includes all organizations that have responsibility for 20% or more of the project deliverables. 8.1

Vendor (and Significant Subvendor) Background In the RFR Response, the Vendor must provide the following information: 8.1.a

The name, address, telephone number, fax number, and email address of the Vendor‟s EIPAS RFR contact.

8.1.b

The Vendor‟s legal name, Federal Tax Identification Numbers (FTINs), headquarters office address, telephone number, fax number, and website address.

8.1.c

A description of the Vendor‟s company, including when it was established, the number of years it has been in the application software and development industry, the number of employees, and its annual revenue.

8.1.d

A description of the types of solutions and services the Vendor delivers.

8.1.e

A description of Vendor‟s customer base and geographical areas served, including customer size.

8.1.f

A list of the Vendor‟s industry and professional certifications relevant to the implementation of software solutions, particularly related to its proposed solution.

8.1.g

A description of the attributes that distinguish the Vendor's organization from others in the market.


Page 52 of 103

8.1.h

A Certificate of Good Standing from the Massachusetts Secretary of State. If the Vendor does not currently conduct business in Massachusetts, it must provide a Certificate of Good Standing from the state in which such entity is incorporated or otherwise registered to do business and/or the state that serves as the principal place of business for such entity.

8.1.i

A description of any litigation in which the Vendor is or has been involved in, including but not limited to litigation related to proposed solution. This description must include:

8.1.j



Any criminal conviction against the Vendor in any jurisdiction in the current and past 5 years.



Any pending criminal investigation in any jurisdiction of which, to the Vendor‟s knowledge, the Vendor is a target of any pending criminal action in any jurisdiction against the Vendor.



Any civil judgment against the Vendor in the current and last five (5) years or any pending civil action against the Vendor that: o

Would affect the Vendor‟s ability to perform any of its obligations under the Contract

o

Relates to any current or past Contract between the EEA and the Vendor

o

Resulted from a suit brought by any local, state, or federal authority

If the aforementioned bullets do not apply, Vendors must provide a written statement that to the best of their knowledge, there is no such conviction, investigation, judgment, or action and that the Vendor has never been subject to any state or federal debarment order or determination. Note: the following categories of crimes will disqualify a Vendor or any of their employees or subcontractors from providing services under a Contract resulting from this RFR: 

Data Security/Privacy – Violation of any state or federal law or regulation pertaining to data security and/or privacy, including, without limitation and for example, the Fair Information Practices Act, M.G.L. ch. 66A, and the privacy and security provisions of the


Page 53 of 103

Federal Health Information Portability and Accountability Act (HIPAA). 

Wiretaps – Violation of the state wiretap law, M.G.L. ch. 272, sec. 99, or its Federal counterpart, 18 U.S.C. sec. 2511.



Computer Crimes – Violation of Federal or State laws specific to computer crime, including without limitation and for example, the Federal Computer Fraud and Abuse Act, 18 U.S. C. sec. 1030 and the Massachusetts state law prohibiting electronic transmission of threats, M.G.L. ch. 269, sec. 14.



Crimes using information technology – Violation of any federal or state criminal laws if follow-up communication with applicant discloses that information technology (computers, networks, and peripheral devices) was used to commit the acts on which the conviction was based. The following are examples of state laws under which crimes committed using computers could theoretically be prosecuted: M.G.L. ch. 272, sec. 29B (dissemination of child pornography);



M.G.L. ch. 272, sec. 29C (possession of child pornography); M.G.L. ch. 265, sec. 43 (stalking) and 43A (harassment). M.G.L. ch. 275, sec. 2 (threat to commit crime); M.G.L. ch. 266 sec. 30 (larceny statute used in hacking and other data theft cases); M.G.L. ch. 266, sec. 12 (willful and malicious destruction of property, for use in website defacement and other hacking cases); M.G.L. ch. 266, sec. 30 (theft of intellectual property); M.G.L. ch. 266, sec. 37E (identity fraud); M.G.L. ch. 266, sec. 120F (unauthorized access to computer system).



Intellectual Property – Violation of laws pertaining to trade secrets, copyrights, patents, or any other form of protection of intellectual property.



White Collar Crime – Violation of federal or state criminal laws pertaining to theft, fraud, misrepresentation, tax evasion, and other forms of white collar crime.


Page 54 of 103



Felony Convictions for Crimes of Violence – Violation of laws pertaining to felonies committed with violence.



Identity Theft – Violation of “An Act Relative To Security Freezes And Notification Of Data Breaches,” M.G.L. ch. 82 of the Acts of 2007.

8.1.k

The Vendor must disclose in the RFR Response all details of any circumstances over the past five (5) years in which the Vendor has caused a breach of the security, confidentiality, or integrity of a customer's data.

8.1.l

The Vendor must provide the following financial background information, including: 

A Dun & Bradstreet's Comprehensive Report (http://www.dnb. com/us) for the Vendor‟s organization, which must be dated no earlier than two months prior to the RFR Response date. The Vendor is responsible for paying the costs associated with this report.



Audited financial statements of the Vendor for its last three fiscal years. If the Vendor does not have audited financial statements, it must provide unaudited financial statements that include the following: o

The types of financial statements or schedules generally provided by audited organizations, including balance sheets, income statements, and a statement of cash flow

o

Explanation of the size and financial stability of the Vendor's organization



A signed un-audited financial statement by an officer of the Vendor's organization who is comparable to the Chief Financial Officer of a publicly traded organization.



A statement that the Vendor has not been in bankruptcy in the last 3 calendar years and has no present intent to file for bankruptcy.



A Statement on Standards for Attestation Engagements (SSAE) No.16, Service Organizations Audit in order to provide an understanding of the control environment of the company.


Page 55 of 103

8.2

Vendor (and Significant Subvendor) Relevant Experience This RFR is seeking Vendors whose proposed project teams have significant demonstrable experience in providing the type of system and services sought. To allow evaluation of Vendor qualifications, Vendors must supply the information outlined below in their RFR Response. Vendors must describe their experience implementing similar projects. Vendors must describe five (5) projects, each for a different client. The projects must be similar in scope and requirements to EIPAS. The Vendor must have successfully completed the prior projects by or before the issue date of this RFR, either as the prime Vendor or as a principal Subvendor which is defined as a Subvendor responsible for more than 50% of the described project. If a project is being completed in phases, Vendors may describe a project that is not yet completed but has one or more completed phases, provided that the completed phases constitute accepted deliverables that have been implemented by the client. It is highly desirable that the Vendor‟s prior clients include state/federal government entities and organizations in the energy and environmental arenas. At least two of the Vendor‟s listed projects in response to Section 8.2.1 must be projects implemented for a government entity. If the Vendor has been awarded a contract in the Commonwealth of MA in the past 60 months for a government entity, that entity must be listed as a reference. At least one of the Vendor‟s listed projects in response to Section 8.2.1. must be a SOA implementation. 8.2.1

Vendor (and Significant Subvendor) Descriptions of Experience For each of the prior five (5) projects listed, the Vendor must provide the following information: 8.2.1.a

Client organization

8.2.1.b

Organization Name, and indication if the client is a subsidiary or division within an larger organization (identify the larger entity)

8.2.1.c

Size

8.2.1.d

Geographic location

8.2.1.e

Industry

8.2.1.f

Solution delivered, including:


Page 56 of 103

8.2.1.g



Description of the solution



Technical environment



Software development

Scope of the Vendor effort in terms of: 

Start and end dates of the project



Total project cost (to the client)



Team size (Vendor‟s resources and client resources)



Final results of the project



Role of Vendor in the project



Role of all Subvendor(s) with 20% or more responsibility of the project



Vendor‟s collaboration with the client on the project

8.2.1h Information about the client representative whom the EIPAS PMT may, in its discretion, contact regarding the project and/or governmental experience, including:

8.2.2



Name and title



Address



Telephone and fax numbers



Email address



Client representative role in project

Vendor (and Significant Subvendor) Experience with SOA The Vendor must describe its prior SOA experience with the abovereferenced clients, and provide the following information: 8.2.2.a

Migrating major business applications to a SOA solution

8.2.2.b

Implementing an SDLC as part of a migration of major business applications to a SOA solution

8.2.2.c

Defining and implementing a SOA governance framework during the implementation of a major business application, including SOA governance tools used in implementing the SOA governance framework


Page 57 of 103

8.2.2.d

8.2.3

Adopting/modifying architectural processes while implementing a migration of major business applications to a SOA solution including the roles and responsibilities of both the Vendor and the client

Vendor (and Significant Subvendor) Stakeholder Experience For the prior projects listed by the Vendor, describe the roles and responsibilities of various stakeholders (such as the Information Technology Unit and Agency/business unit(s)) in the implementation of the SOA governance framework, including an identification and description of the role of business, technology, and executive management stakeholders.

8.3

Vendor (and Significant Subvendor) Project Team Vendors must propose a qualified project team that is appropriately staffed and readily available to work on the EIPAS project. The Vendor must also include and clearly indicate any Subvendor organizations and personnel that will be part of the project team. The EIPAS project assumes that key Vendor personnel will work on-site in Boston Monday through Friday until the project completion. Vendors must identify any alternative staffing arrangements in the RFR Technical Response narrative and corresponding Price narrative and Pricing Matrix and Rate Table. 8.3.1

Vendor (and Significant Subvendor) Project Team Organization The Vendor‟s proposed project organization must align to the governance structure described in Appendix 3: EEA EIPAS Governance. In this the RFR response , the Vendor must include the following items: 8.3.1.a

Provide an organization chart of the Vendor‟s EIPAS team, including the various entities (departments/groups/roles) that will participate in the EIPAS project and include and indicate on that chart all relevant Subvendors (i.e., any Subvendors with 20% or more participation in the project).

8.3.1.b

Indicate the level of staffing available in each relevant Vendor department that the Vendor will leverage to support this project.

8.3.1.c

Describe projected interactions between each Vendor entity and the EEA entities outlined in Appendix 3 EEA EIPAS Governance.


Page 58 of 103

8.3.1.d

8.3.2

If necessary, explain why and how the Vendor‟s organizational structure might change for each implementation phase of the project.

Vendor (and Significant Subvendor) Staff Continuity The Vendor‟s staffing approach must strive to maintain continuity in the composition of the project team, including Subvendors, over the course of the Contract. There must be continuity – including fully dedicated personnel -- within each area of the project and across the project as a whole. The Commonwealth assumes that all Key Personnel will be colocated with the Commonwealth Project Team AND are dedicated 100% to the project unless otherwise noted. At a minimum, Key Personnel should include:

        

Program Manager Technical Lead Architect Testing Lead(s) Functional Lead(s) Communications Lead Training Lead Application Lead Implementation Lead

In the event that a change is necessary, the Vendor‟s Program Manager will provide prompt written notice to EEA‟s Program Manager of the proposed change:

8.3.3



If the personnel change is a result of an emergency, the Vendor‟s Program Manager shall provide prompt written notice to EEA‟s Program Manager.



If the change is due to a nonemergency, Vendor Program Manager shall provide EEA EIPAS Project Manager two-week written notice.

Vendor (and Significant Subvendor) Key Staff Qualifications, Responsibilities, and Resumes The Vendor must assign key personnel who are qualified to perform the services required for the project. For each of the individuals the Vendor is proposing to assign to this project, the Vendor must include the following information in the RFR Response: 8.3.3.a

Name, title, and employer of individual


Page 59 of 103

8.4

8.3.3.b

Proposed role in project

8.3.3.c

Number of years experience in proposed role

8.3.3.d

Number of years relevant experience

8.3.3.e

Number of years with employer

8.3.3.f

Time commitment expressed as percentage of full time

8.3.3.g

1 - 2 page resume that includes the following information: 

Recent relevant prior project experience, including: start and end dates; client name; size and scope of the project; role/title and responsibilities; applied technical skills, subject matter expertise, methodology, and software tools



Education, including certifications and training



Two client references with first-hand knowledge of the team member‟s ability to perform the type of services required by this RFR. At least one of the references must be for work performed within the last 60 months. For each reference, Vendor must include in the client reference the name, title, employer, phone, and email address to facilitate reference contact by PMT.

Other Significant Subvendor(s)Requirements As required by Article 9 of the Commonwealth Terms and Conditions, all subcontracts must be in writing and approved in advance by EEA, and Subvendors are subject to all standard Contract requirements of the Commonwealth. 8.4.a

The Vendor‟s RFR response must include a list of all significant Subvendors that have responsibility for 20% or more of the EIPAS project.

8.4.b

The Vendor should include signed letters of agreement between the Vendor and its Subvendor(s) identifying the Subvendor(s)‟ responsibilities and their relationship to the Vendor.


Page 60 of 103

9.

EIPAS SOLUTION – PHASE II SPECIFICATIONS 9.1

Introduction This section of the RFR builds upon the EIPAS Project Definition as described in the RFR, Appendices and Attachments and identifies the technological specifications requirements that the Vendor must meet through submission of its RFR Response. It is the Vendor‟s responsibility to review all of the attachments and appendixes contained within this RFR, as those documents contain specific information critical to a Vendor‟s understanding of the intent and scope of the EIPAS project. As set forth in more detail in RFR Introduction EEA commenced with EIPAS Phase I in September 2011. EIPAS Phase I resulted in the EIPAS Phase I Documents that are attached in Attachment 1. The EIPAS Phase I Documents are the foundation on which this RFR has been developed, and any Vendor responding to this RFR should thoroughly review the Attachment 1 Documents, since the Vendor‟s RFR Response proposal for the EIPAS Project (including the EIPAS architecture, application architecture and applications) must reflect the functionality(ies), goals and objectives described in Attachment 1: EIPAS Phase I Documents. NOTE To Vendors: While the EIPAS Phase I Documents generally refer to “MassDEP” or “EEA,” The EEA Secretariat as a whole has adopted the EIPAS Phase I recommendations, goals and objectives as the basis for issuance of this RFR, and Vendors must submit RFR responses that incorporate the EIPAS I goals and objectives for utilization by the entire EEA Secretariat (including EEA‟s six agencies, described in Appendix 1). It is EEA‟s intent to utilize existing Commonwealth enterprise software when/if possible and Vendors will be asked to either incorporate specific enterprise solutions in their RFR response, or provide compelling reasons why an alternative solution should be considered. The successful Vendor will be required to develop business requirements and detailed technical specifications as their initial major task. These requirements will include, but are not limited to, finalizing the Master Service Agreement (MSA) (Attachment 7) that will be signed by the successful Vendor and EEA. It is anticipated that business requirements will be developed on an iterative process as the data schema, business components and lastly applications are implemented via a phased approach. The successful Vendor will conduct this design and specification work in close consultation with the EEA EIPAS program manager.


Page 61 of 103

9.1.1

Proposed Project Approach In the RFR technical response narrative, Vendors must provide a detailed narrative, explaining their proposed strategy for analysis, assessment, and design of this project. The approach must include the utilization of a Master Service Agreement (MSA)with, Project Plan and Task Orders. Vendors must provide an explanation in the RFR Technical Response narrative of their:

9.1.2

9.1.1.a

Project approach and preliminary plan including iterative deliverables.

9.1.1.b

Application development and data migration plan

9.1.1.c

Software development process

9.1.1.d

Key phases and deliverables

9.1.1.e

Software development methodology for each aspect of the proposed solution

9.1.1.f

Quality assurance methodology

9.1.1.g

Internal security practices as applicable to this project, including but not limited to, how these security practices will continue to apply and/or evolve during the development and implementation, warranty and maintenance stages of the project.

Proposed Solution The Vendor will be responsible for developing and implementing a solution that achieves EEA‟s business objectives and that meets the requirements specified in this RFR in its entirety, including all attachments and appendices. In particular, the Vendor must present a solution in the RFR response that meets all EEA objectives and goals set forth in this RFR, Appendices and Attachments, including but not limited to Attachment 1 EIPAS Phase I Documents. The detailed specifications for the EIPAS Project are found in this RFR, Appendices and Attachments. When responding to required RFR technical specifications, the Vendor must describe in detail the software and technology that will be used for each component of the project. Vendors must include the following information in their RFR Technical Response Narrative:


Page 62 of 103

9.2

9.1.2.a

Vendors must confirm, identify and describe the major application components that will make up their proposed system. For each component, the Vendor must describe the business function(s) supported by that component and confirm that it meets technical specifications set forth in this RFR and the goals and objectives identified in Attachment 1: EIPAS Phase I Documents, or describe where the functionality is not met. Where functionality is not met, the Vendor must indicate (and then describe) any proposed alternative that the Vendor will utilize to address this functionality.

9.1.2.b

Vendor must identify and describe the major technologies employed, including, but not limited to, the role of each technology in the EIPAS Project. In addition to this description, the Vendor must attach a software list to provide more specific and detailed information of the software and hardware that will be deployed. Vendors must provide a precise description of any commercial-offthe-shelf software (COTS) solutions they propose as a component of the EIPAS solution architecture.

9.1.2.c

If proposing COTS solution(s) to be integrated with a custom-built application, a Vendor must describe successful prior project experience integrating multiple COTS solutions in conjunction with custom software, and the Vendor must fully describe this approach within the EIPAS Project.

9.1.2.d

Each Vendor must identify in its response both the software owned by the Vendor (for software which is in the Vendor‟s possession) or indicate that the Vendor has access to the source code of COTS software. Each Vendor must agree to place in escrow all source code.

Technology Architecture and Data Schema EEA is requiring the Vendor, in its RFR response, to propose a new physical and technical environment for the EIPAS Project. The EIPAS Project will not utilize any of EEA‟s existing technical architecture. Therefore, while existing applications have been developed in SQL and Oracle, EEA‟s current technology architecture and application architecture will not be used during the design and development of the EIPAS solution by the Vendor.


Page 63 of 103

Details on EEA‟s existing computing environment can be found in Appendix 2, Existing Computing Environment, and is provided for background and reference for the Vendor. The Vendor may propose, as an alternative solution, hosting of the proposed solution, at the Commonwealth of Massachusetts ITD MITC Data Center. 9.2.1

Technology Architecture Proposal A detailed description of the proposed Technology Architecture can be found in Attachment 1: EIPAS Phase 1Documents. A key goal of the EIPAS proposed Technology Architecture is to provide a sustainable technology architecture foundation of comprehensive and core functional components on which EEA will implement technology solutions that improve the ability of the EEA Information Technology Office (EEA/IT) to respond in a timely and agile method to evolving EEA agency needs. EEA requires that the Vendor propose an approach that includes the development of an Enterprise SOA strategy and a timeline and process for implementing that strategy. The Vendor must build reusable software components and/or services that allow EEA/IT to aggregate and present solutions to be used by different stakeholders with common needs, while reducing the proliferation of applications and increasing IT capacity and responsiveness. The Vendor must propose an overall technology architecture that reflects the scope of the six individual architectures shown below. Exhibit 4: Proposed Technology Architecture: Six Individual Architectures

Application Architecture

Service Architecture

External facing...

Services & API(s)

Data Architecture Data Store(s)

Internal facing...

Interoperability Architecture Access and Delivery Architecture Security Architecture



Application Architecture: The Application Architecture defines the standards, architectures, and application


Page 64 of 103

development frameworks that govern the process of building IT systems and integrating internally created or commercially obtained software within EEA.

9.2.1.a

9.2.2



Service Architecture: The Service Architecture defines and depicts the software component foundations on which the integrated environmental systems are implemented.



Data Architecture: The Data Architecture documents the common data definitions for all shared EEA information and defines the rules and standards for access and use of data.



Interoperability Architecture: The Interoperability Architecture defines the services, standards, and protocols that support interaction amongst EEA systems.



Access and Delivery Architecture: The Access and Delivery Architecture defines the supported and planned access channels and modes of information delivery throughout EEA.



Security Architecture: The Security Architecture defines the approaches and methods used to protect the confidentiality and integrity of information and systems from unauthorized access, use, and disruption. In the RFR response, the Vendor must describe their approach to assessing the technology architecture requirements and designing the implementation of each architecture. The Vendor‟s recommendations and approach will be utilized as the basis for one of the first negotiated task orders in this project.

Data Schema A key element to the EIPAS solution is the development of a unified enterprise data model, that will serve as the foundation to the proposed EIPAS integrated solution. The Vendor must develop an enterprise and integrated model that will facilitate and permit core elements to be shared across the enterprise. Several cornerstone elements, which are identified and defined below, drive EEA‟s key business processes. In the RFR Response, the Vendor must describe how their process for developing a data model for EEA will: 9.2.2.a

Support the business needs defined in this RFR


Page 65 of 103

9.2.2.b

Support data integration

9.2.2.c

Promote interoperability

9.2.2.d

Ensure data integrity

9.2.2.e

Support data architecture for enterprise transactional and warehouse requirements identified in Attachment X EIPAS Phase 1 Documents.

9.2.2.f

The Vendor must also describe how the proposed process to develop the data model will ensure that the model meets all the required complexities of the interdependant relationships between the core elements necessary to meet the EIPAS requirements defined in this RFR, and the following aspects of EEA‟s business:



Chemical: Any regulated chemical substance.



Location: Geographic information required to fully describe incidences of chemicals, actors, regulated entities, and activities. Location may be geophysical or geopolitical and may be a single location or a polygon or a group of locations.



Actor: Any person, organization, or system that initiates or interacts with EEA.



Regulated Entity: the entity that is required by Commonwealth energy or environmental laws and regulations that apply to the Regulated Matter; the authority by EEA to mandate environmental or energy requirements.



Activity: The action by any Regulated Entity and Actor as required by environmental or energy laws and regulations. Component within any business and operational workflow that facilitates EEA goals and is performed by an Actor or a program-required business process.

9.3

Business Components: Overview EIPAS Phase I identifies a business component model and functionality which is defined and clarified in Attachment 1 EIPAS Phase I Document. In the RFR Response, the Vendor must propose an EIPAS solution that will support all of the specified functionalities set forth in the business


Page 66 of 103

components document. While the majority of the business components are mandatory requirements for the RFR technical response, other business components are highly desirable to EEA, as indicated in the Requirements Table in Attachment 3. Additionally, the Vendor must recognize that the business component model organizes the sixty-three (63) unique business components into primary portals based upon the category of users Further, the business component model identifies thirteen (13) common components that EEA anticipates would be shared across the five (5) portals. The Vendor must integrate these factors into the proposed EIPAS solution. Ideally, the Successful Vendor will develop all business component functionality identified in the business components document, and ensure that these functionalities are available for utilization by any application that is built on the EIPAS Architecture. In responding to the business components requirements, the Vendor‟s RFR response must recognize that the business components represent the types of business functions that EIPAS must support at the conclusion of this EIPAS Project, and specify, as part of the RFR response, how the proposed EIPAS solution will address these business functionality requirements. The following Exhibit, Business Component Model, summarizes the business functions that the Vendor must specifically address in the RFR response as part of the proposed EIPAS solution.


Page 67 of 103

Exhibit 5: Business Component Model

9.3.1

Business Components  Detailed Specifications This section includes a comprehensive list of all business components which the Vendor must address in the RFR response. All of the business components listed in the following section should be considered mandatory unless indicated, next to the component, that the component is “Optional.” All business components (including optional business components) are listed in Attachment 3 Requirements Table and a response must be provided for each component. As noted previously, the business components that the Vendor must address in the RFR response are listed below. Attachment 1, EIPAS Phase I Documents, lists these business components and a high level description of their expected functionality.


Page 68 of 103

Included as part of the Attachment 1 is an additional document which clarifies/corrects certain functionality descriptions in the business component document. The business component document and the clarifications document must be reviewed/analyzed by the Vendor together to understand the full scope of this RFR requirement. 9.3.2

Business Components Requirements In the RFR Response for the individual business components below, the Vendor must provide a brief narrative describing the software and functionality that will be included in the Vendor‟s proposed solution that meets the intent of Attachment 1, EIPAS Phase I Documents, specifically, the Business component Document and Business Component Clarifications Document. The technical narrative response to the RFR must include the methodology the Vendor will implement to address business requirements across the business units in the Secretariat, given that an iterative development process will be utilized and business component functionality will be built and expanded by the Vendor as a result of the applications that are migrated and transformed onto the EIPAS architecture. If the Vendor technical response narrative is duplicative for multiple business components, then the Vendor may reference the narrative for the original business component response and not repeat the same information. However, the Vendor‟s narrative must include all assumptions, qualifiers, and/or constraints with respect to any business component addressed (including optional business components). If an alternative approach is proposed, Vendor must respond to both the mandatory requirement, and then propose an alternative option, together with any assumptions, qualifiers and/or constraints associated with either the standard or the alternative approach In addition the Vendor must complete the Attachment 3 Requirements Table and respond to all questions for each listed business component.


Page 69 of 103

9.3.2.1

Online Filing Processing

9.3.2.2

Staff Assignments

9.3.2.3

Application and Notice Reviews

9.3.2.4

Public Comment

9.3.2.5

Financial Assurance (OPTIONAL)

9.3.2.6

Examinations (OPTIONAL)

9.3.2.7

Decisions and Issuances

9.3.2.8

Environmental Data

9.3.2.9

Laboratory Data

9.3.2.10

Inspections

9.3.2.11

Compliance Tracking

9.3.2.12

Complaint Management

9.3.2.13

Penalty Calculations

9.3.2.14

Compliance Reviews

9.3.2.15

Enforcement and Sanctions

9.3.2.16

Appeals and Legal Actions

9.3.2.17

Public Records Requests

9.3.2.18

Grant Management (OPTIONAL)

9.3.2.19

Revenue/Receivable Processing

9.3.2.20

Collections

9.3.2.21

Disconnected Data Management

9.3.2.22

Calendar/Activity Management

9.3.2.23

Mobile Inspections

9.3.2.24

Remote Searches, Views, and GIS

9.3.2.25

Field Data Collection


Page 70 of 103

9.3.2.26

Environmental Data Collection

9.3.2.27

Standard Reporting

9.3.2.28

Dashboard Views

9.3.2.29

Ad Hoc Reporting

9.3.2.30

Dataset Library

9.3.2.31

EPA Exchanges

9.3.2.32

MMARS Exchanges

9.3.2.33

Other Exchanges

9.3.2.34

Web Service Lookups

9.3.2.35

User Registration

9.3.2.36

Group Administration

9.3.2.37

Information Views

9.3.2.38

Communications

9.3.2.39

Online Form and Data Submittal

9.3.2.40

Online Payments

9.3.2.41

Remote Sensor Reporting

9.3.2.42

Surveys

9.3.2.43

Online Help and Assistance

9.3.2.44

Request Submission

9.3.2.45

Environmental Information Access

9.3.2.46

Online File Reviews

9.3.2.47

Complaint/Tip Submission

9.3.2.48

Environmental Dataset Downloads

9.3.2.49

Notification Subscriptions

9.3.2.50

Public Comment Submission


Page 71 of 103

9.4

9.3.2.51

Common Components

9.3.2.52

Remote Searches, Views, and GIS

9.3.2.53

Document Management

9.3.2.54

Notes and Correspondence

9.3.2.55

Workflow Manager and Inbox

9.3.2.56

Calendar and Activity Manager

9.3.2.57

Reminders and Notifications

9.3.2.58

Subscription Manager

9.3.2.59

Configuration Manager

9.3.2.60

Data Maintenance

9.3.2.61

User Access and Administration

9.3.2.62

EEA Knowledge Base

9.3.2.63

Desktop Integration

9.3.2.64

General Systems Features

Portal Development EIPAS business component functionality and all EIPAS data, as deemed appropriate by EEA, must be available, to external and internal users through the use of interactive and intuitive portals. As described in Attachment 1, EIPAS Phase I Documents, EEA will utilize portals for the following users and functionality: Internal Users Mobile Users External Users Public Access Reporting and Information Exchange Each of these portals will consist of combinations of the business components listed above in section 9.3 and must be device and browser agnostic as described in Section 9.11.


Page 72 of 103

9.4.a

9.5

In the RFR technical response narrative, the Vendor must provide a short narrative describing how its proposed EIPAS solution will meet the portal requirement. The Vendor must also complete the portals section listed in Appendix 3: Requirements Table.

GIS GIS is a mandatory Business Component in subsection 9.3.2.52 above. In order for the Vendor to comply with the mandatory GIS business component, the following additional information regarding GIS is provided here. The core business functions of Energy and Environmental Affairs are, by nature, geographic. Many EEA regulatory decisions, standards, or conditions are based in part, on the location of the regulated activity within the environment. Significant portions of EIPAS solution will have to be spatially aware, integrated with GIS, and have the capability to make spatial queries, and process spatial business rules. The key identification of “Location” should provide a common point of entry for both EEA staff and the public at large to gain access to EEA agency information about a place. EEA‟s GIS Environment is based on MassGIS, a Commonwealth wide GIS architecture. EIPAS functionality must utilize existing GIS resources to accurate reflect and retain location information. http://www.mass.gov/anf/research-and-tech/it-serv-andsupport/application-serv/office-of-geographic-information-massgis/. If the Vendor has an alternative approach to augment EEA‟s or the MassGIS environment or resources, that approach should be detailed per Alternatives To Technical Requirements Section 5.5. 9.5.1

GIS Integration In the RFR Response, the Vendor must describe how its proposed EIPAS solution will integrate and seamlessly interface with the existing Mass.Gov and EEA GIS information and architectures.

9.6

Data / Reporting Warehouse(s) In the RFR response, Vendors are required to include in the proposed EIPAS solution how they will utilize data warehouse(s) to facilitate data migration, data cleanup, data synchronization during development and for internal and external reporting purposes.


Page 73 of 103

9.6.1

Data / Reporting Warehouse(s) Specifications In the RFR response, Vendors must describe:

9.7

9.6.1.a

The number of data warehouses the Vendor is proposing,

9.6.1.b

Functionality by warehouse

9.6.1.c

Warehouse duration (i.e., whether temporary during system design and/or permanent as part of the EIPAS solution).

Permitting/Licensing/Authorizations Permitting and licensing is a key and mandatory component of the EIPAS Architecture and consists of many of the Business Components listed in Section 9.3. Note that permitting, in particular, consists of multiple Business Components, including, but not limited to, Application and Notice Reviews, workflow management, task management, calendar management, document management and online payments. Attachment 1, EIPAS Phase I Documents, Business Components Document and Clarifications should be referenced for additional details. The Vendor‟s permitting and licensing solution includes both internally and externally facing components. The Vendor‟s Permitting and Licensing solution must have the ability the meet the timeline calculations required by MassDEP in 310 CMR 4.00 and the ability to easily configure workflow throughout the regulatory process. The Vendor‟s proposed permitting and licensing solution must also link to a document management solution and an entity management solution. The Commonwealth of Massachusetts has procured Accela, an enterprisewide Licensing package that meets many Commonwealth agencies‟ needs for permitting and licensing and is hosted internally at the Commonwealth‟s data center (MITC). The Vendor must determine if Accela, as the Commonwealth‟s enterprise licensing solution, meets the requirements identified in this RFR, Appendices and Attachments, or if the Vendor will propose an alternative solution. More information on Accela is available at www.accela.com/. In the RFR Response, the Vendor must: 9.7.a

Indicate whether the proposed EIPAS solution will utilize Accela. In the event that Vendor does not include Accela in the proposed solution, the Vendor must itemize the reasoning for proposing a solution that is not the Commonwealth‟s Accela enterprise permitting and licensing solution.


Page 74 of 103

9.8

9.7.b

Describe in detail how the Vendor‟s proposed solution will meet the functionality described in the business component section for permitting and licensing.

9.7.c

Describe how the proposed solution, performs the complex timeline calculations as required by MassDEP and described in 310 CMR 4.00. Timeline calculations include MassDEP time and permittee time.

9.7.d

Describe the ease by which Agency subject matter experts (SMEs) can configure timelines, adjust data (such as corresponding fees) and manipulate workflows.

Entity Management / Identity Management In addition to the requirements shown in the above business components Section 9.3, the Vendor in the RFR response must respond to the following requirements. 9.8.1

Required Functionality The Vendor‟s RFR response must describe, in narrative form, how the proposed components of the EIPAS system meet the following entity/identity management business requirements: 9.8.1.a

Maintain a single unique entity identity. Note: entities consist of both individuals and organizations.

9.8.1.b

Provide an automated process for reconciling duplicate entity records.

9.8.1.c

Prevent multiple entries of the same entity that might be caused by typos or use of a nickname through a process such as automated cross checking upon data entry.

9.8.1.d

Entity history must be retained, including dates of changes. For example, if an individual represents an organization in the EIPAS database, there must be a record of previous associations if the individual changes jobs or companies.

9.8.1.e

Maintain relationships between parent organizations and their subsidiaries; the proposed system must allow inherited business rules to span across all organizational forms based on the designation of the parent organization.


Page 75 of 103

9.8.1.f

9.8.2

Satisfy the US Environmental Protection Agency's (EPA) Cross-Media Electronic Reporting Regulation (CROMERR) Identify Management Requirement (See Section 9.8.3 below)

Highly Desirable Capabilities It is also highly desirable that the Vendor‟s proposed solution will have the ability to transfer these functions to  or federate with  ITD‟s Tivoli Proposed Identity Management solution for external entities. 9.8.2.a

9.8.3

The Vendor must describe in the RFR Response if it will be technologically feasible, as proposed, to replace the Vendor‟s proposed identity management solution without major technical effort or disruption of other EIPAS functionality with ITD‟s Tivoli Identity Management solution, if that solution is implemented. More information on Tivoli is available at www01.ibm.com/software/tivoli/governance/security/identityaccess-mgmt.html. The work to replace the Vendor‟s proposed solution with the ITD IM solution would be outside the scope of this project. This RFR requirement speaks solely to the feasibility of such a replacement, and not to the implementation of the replacement.

CROMERR Compliance CROMERR is an EPA regulation that sets performance-based, technology-neutral standards for systems that states, tribes, and local governments use to receive electronic reports from facilities they regulate under EPA-authorized programs, and requires program modifications or revisions to incorporate electronic reporting. Many MassDEP electronically submitted permits and reports are subject to CROMERR. The Vendor‟s proposed EIPAS solution must meet CROMERR requirements and include administrative functionality needed to support CROMERR-required authentication processes for those reports and permits subject to CROMERR. Vendors can find information on CROMERR requirements at: www.epa.gov/CROMERR/tools.html. In the RFR Response, the Vendor must indicate that the proposed EIPAS solution either will meet CROMERR compliance requirements


Page 76 of 103

through custom design, existing components, or, will interface seamlessly utilizing an API with an EPA provided CROMERR web application. With respect to CROMERR compliance, the Vendor must specifically describe in their RFR response how the Vendor will meet the following requirements:

9.9

9.8.3.a

Reports and permits subject to CROMERR will meet all federal requirements, either through linking to EPA‟s CROMERR application via an API and building CROMERR functionality within the EIPAS Solution.

9.8.3.b

That the solution as proposed will have the capability to federate the CROMERR capabilities to ensure that web submittals not subject to CROMERR are subjected to those additional requirements. Because a significant portion of web submittals are not subject to the stringent CROMERR requirements, the Vendor must describe how they will federate the proposed EIPAS solution to ensure that those web submittals that have CROMERR requirements have that functionality while other web submittals utilize a less stringent identification and verification process.

9.8.3.c

As part of the proposed EIPAS solution, the Vendor must affirm that they will assist EEA in completing a CROMERR compliance application for the system to submit to EPA for approval.

9.8.3.d

Vendors must indicate in the RFR Technical Response Narrative whether they have previously implemented any systems that were deemed by EPA to meet CROMERR requirements, or linked an existing system via an API to EPA‟s web based CROMERR tool.

Application Development EEA has identified 100+ current applications or paper processes in Attachment 8 Application List with Screenshots. These applications, along with their corresponding data, must be migrated off their existing technology and application architectures and transformed onto the new EIPAS technology and application architecture. The Vendor must anticipate that the majority of these applications will have substantial new workflows and additional business requirements that exceed the functionality of their current system(s). The majority of the current applications have limited functionality and do not reflect current business practices and needs.


Page 77 of 103

Vendors should also be aware that many of these existing applications have redundant functionality and could either utilize a single business component or, in the alternative, multiple applications with similar purposes or processes could be consolidated into a single application with enhanced functionality. Potentially, several applications which currently reside as stand-alone applications may be merged into one application, e.g., individual permitting applications residing within a single agency may be merged into one single permitting application. EEA requires that the Vendor, through business requirements development and analysis, to identify where consolidation of applications and/or functionality would facilitate development and long term maintenance. EEA requires that each application will be transformed onto the new EIPAS architecture and will utilize the new business components. 9.9.1

Application Development Requirements The Vendor must, in the RFR Technical Response Narrative, respond to the following requirements: 9.9.1.a

The Vendor must propose an application and technology integration/transition plan in their response to this RFR. The majority of the applications listed in Attachment 8 are legacy systems, many of which are integrated with other data systems. In the integration and transitional plan, the Vendor must identify the process by which key data integration points will be identified to ensure continuous functionality during data and application migration and transformation.

9.9.1.b

The Vendor must describe the process and approximate time schedule by which the Vendor will address the breadth of applications needed to be migrated onto the new EIPAS architecture. The Vendor‟s RFR Technical Response Narrative must include its approach for both EEA business requirements and technical specifications development for each application.

9.9.1.c

The Vendor must identify the approach the Vendor will utilize during the project to ensure that the functionality of legacy systems continues until all dependencies (identified in this RFR) have been migrated onto the EIPAS solution during the scope of this engagement.


Page 78 of 103

9.10

9.9.1.d

The Vendor must describe its approach for data migration, cleansing and synchronization during the application migration process, including in the RFR response how the Vendor will evaluate existing relationships, such as data exchanges, and provide the business component development strategy.

9.9.1.e

The Vendor must also describe how the proposed EIPAS system design will maximize business owner configurability.

Data Migration, Mapping, Cleansing, and Synchronization In the Vendor‟s Technical Response Narrative, the Vendor must propose the most efficient and effective data migration, cleansing and synchronization plan that will serve the ongoing business requirements, goals and objectives of EEA. The Vendor must propose a methodology for migration of data during system development and application development. While specific timing and required data elements will be determined by EEA and the successful Vendor during the project, the Vendor, in the RFR Response, must describe the overall approach they propose to utilize for data cleansing, migration and ongoing integrity. In specific instances, data, either wholly or in part, will not be migrated to the new system. However, the Vendor should assume, for the purpose of responding to this RFR, that all data will be migrated and the following conditions must be met. As part of this RFR requirement, the Vendor must ensure that transactional data from existing systems continue to be available to those legacy systems until such time that the existing, legacy system is retired. In the Vendor‟s Technical Response Narrative, the Vendor must describe their process for data mapping between legacy applications, data warehouses and newly migrated transformed applications. Vendors should note that single instances of data can be utilized by multiple applications and mapping documents will need to be updated as subsequent applications are migrated and transformed. 9.10.a

The Vendor must describe their process for cleansing data, identifying any automated tools that will be utilized for this process. The Vendor must describe if these tools are temporary and only will be utilized for migration and cleansing during the EIPAS System development, or if these tools will be an integral part of the EIPAS system utilized to ensure ongoing data integrity.


Page 79 of 103

9.10.b

The Vendor must describe the process for migrating data from retiring legacy applications into the EIPAS environment.

9.10.c

The Vendor must propose solutions to ensure that transactional data is available to legacy systems with minimal or no legacy system modifications This transactional data requirement is be limited to Oracle and SQL Server Databases and not Microsoft Access databases.

9.10.d

The Vendor must describe the tools and processes that will be utilized to cleanse, convert, and otherwise transform the original datasets in a manner that incorporates the new EIPAS data standards and ensures consistent and high-quality data in the new EIPAS system. Automated tools should be proposed wherever possible to minimize agency SME manual review. Vendor tools can include, but are not limited to:

9.10.e

9.11



Filtering out data known to be unreliable or obsolete



Correcting data that violate database rules such as data type, validation rules, or referential integrity



Changing validation references from one source to another (for instance, an application may refer to a local chemical table, but may be converted to refer to a new broadly shared table)



Changing the data types and values associated with fields that do not conform to EEA data standards

Vendor must describe all tools that will be incorporated within the EIPAS architecture to maintain ongoing data integrity.

Device and Browser Compatibility and Support It is critical to the objectives of EEA that the proposed EIPAS system maintain compatibility with devices and browsers already in common usage. EEA should not have to adjust web forms each time a new browser version is released or new OS is released and ideally, all products should be device and browser agnostic. The Vendor must describe in the RFR Technical Narrative Response and in Attachment 3 Requirements Tables how the proposed EIPAS Solution will: 9.11.a

Utilize a responsive web design or similar technology to enable users to access the public access portal and externally facing applications from a variety of devices without significantly sacrificing functionality or usability.


Page 80 of 103

9.11.b

Be designed so that internal components of the system will, at a minimum, be completely functional for personal computers and tablets running Windows 7+,and Microsoft Office 2007 over the term of the contract, all contract extensions and the warranty period.

9.11.c

Be designed to be browser agnostic over the term of the contract, all contract extensions and the warranty period.

9.11.d

The public access components of the system must be completely functional for users accessing these features with smart phones, tablets and PCs. The public access features must be browser agnostic and operating system (OS) agnostic over the term of the contract, all contract extensions and the warranty period.

9.11.e

Vendors must also indicate and describe any known limitations in the device and browser compatibility of their proposed EIPAS solution, and identify/describe any alternative approaches to address non-compatible elements.

EEA is interested in proposed approaches that include a technology development environment that supports native, Apple and/or Android application development. 9.12

Compliance with Enterprise Accessibility Standards The EIPAS solution must meet the Enterprise Accessibility Standards as described in Attachment 6, Section 1.2 Accessibility. 9.12.a

Vendors shall submit with their bid the VPAT for each piece of COTS and/or SaaS Software product that the Vendor proposes to be used by end users. It is understood that some Vendors will not have VPATs for all COTS and/or SaaS Software products included in their bid. Vendors may, but are not required to, create a VPAT for such products and include it in their bid. 

VPATs Provided: Vendor shall provide VPATs for all Vendor and third-party software with which end users will interact in connection with the Services (the “End User Software”).



VPATs Not Provided: 

With respect to Software for which Vendor does not provided satisfactorily detailed VPATs, Vendor shall provide any alternative accessibility testing information or test results to which it has access.


Page 81 of 103



A Vendor that lacks VPATs or other credible accessibility testing results for the End User Software will not be disqualified from further consideration.



If the Vendor does not submit a VPAT for all End User Software, or the Vendor‟s VPATs or other accessibility testing results show that the proposed Vendor and Third -Party Software do not present significant accessibility issues then EEA will file a request for a mitigation letter to the ITD Assistive Technology Unit, which if approved by the Unit, may result in the issuance of a required mitigation plan.



If EEA files a mitigation letter request on behalf of the Vendor with the AT Unit, then EEA will not enter into an Agreement under this RFR until such time as it receives such approval from the AT Unit in the form of a mitigation letter. As noted above, the mitigation letter will not waive the Enterprise Accessibility Standards permanently by excusing EEA indefinitely from meeting them, but will permit EEA to enter a contract with the Vendor under which accessibility problems with the COTS and/or SaaS Software products are resolved or mitigated after contract execution. The mitigation letter may impose requirements regarding accessibility on Vendor in addition to and consistent with this section, which shall become part of the contract between EEA and the winning Vendor.

Vendor shall test every End User Software component for which it lacks satisfactorily detailed VPATs or alternative credible accessibility test results, and every configured version of, modification, customization, or upgrade thereto offered to EEA in connection with the Services. Vendor shall conduct such testing based on the Enterprise Accessibility Standards, and for interoperability with the AT/IT List. Prior to making each such End User Software component or configured version of, modification to, customization of or upgrade to available to EEA in connection with the Service, Vendor shall deliver to EEA the results of such testing. Accessibility testing will be incorporated as part of its overall quality assurance process. In this regard, Vendor shall test for accessibility during any or all of unit testing, integration testing, final acceptance testing and system testing. In addition to Vendor‟s independent testing obligations set forth herein, Vendor shall cooperate with ITD‟s third-party Vendors, including its Accessibility Testing Vendor, in its performance of testing. THIS RFI AND ALL RESPONSES HERETO WILL BECOME PUBLIC RECORD EIPAS II RFI EEA-IT-2014-823

Page 82 of 103

Vendor shall deliver to EEA the results of such testing prior to making such End User Software component or configured version of, modification to, customization of or upgrade to available to EEA in connection with the Services. 9.13

Quality Assurance, Acceptance and Testing Criteria

9.13.1

Quality Assurance In the RFR response, the Vendor must describe its policies, practices and procedures regarding its philosophy, vision of quality, and quality of work as expressed by top-level management.

9.13.2

Software Quality Assurance (SQA) Methodology In the RFR Technical Response Narrative, the Vendor must describe its software quality assurance (SQA) and testing methodology in terms of: 9.13.2.a

Roles and responsibilities

9.13.2.b

Tools and techniques the Vendor will use to manage:       

9.13.2.2

The SQA and testing process Source control and versioning Code walkthroughs and reviews Testing standards and guidelines, Verification and validation techniques Test-bed data creation Test case design

9.13.2.c

Testing time estimation in accordance with SQA industry best practices, such as those established by CMMI, W3C, or IEEE

9.13.2.d

Execution of test automation using custom or COTS test automation tool(s)

Vendor SQA Responsibilities In the RFR Technical Response Narrative, the Vendor describe their process for developing and delivering comprehensive test plans and checklists for the following types of tests:     

Accessibility Data conversion Functional Integration Load


Page 83 of 103

      

Negative Positive Regression Security Unit Usability User acceptance

During the term of the contract: 1. The Vendor must develop test cases and scenarios that prove all of the application‟s functionality. 2. The Vendor must test all deliverable software in a test environment to ensure that the software is robust and ready for more exhaustive testing by the EIPAS Project team. 3. As part of the status reporting effort, the Vendor must issue regular updates that describe ongoing testing efforts and strategies, as well as all test results, both during testing and when testing is completed. In addition, during status meetings between test build cycles, the Vendor‟s technical lead will provide a spreadsheet listing issues addressed/not addressed. 4. The Vendor must enable  and train EEA employees in  the use of test automation tools and scripts. 9.13.2.3

Use of Test Scripts In the RFR Response, the Vendor must describe its experience developing and maintaining test scripts for automated, repeatable testing processes. Due to the iterative development cycle of the EIPAS system, automated test scripts are highly desirable to test ongoing system integrity during all updates. All test scripts proposed by the Vendor in the RFR Response must run across browsers and operating systems for end-to-end system testing, and all test scripts must also accommodate all the types of testing listed in Subsection 9.13.2.2, Vendor SQA Responsibilities.

9.13.2.4

Performance Baseline In the RFR technical response narrative, the Vendor must describe the process by which the Vendor will establish an


Page 84 of 103

application performance baseline to determine if system performance meets application response specifications. During the term of the Contract, the Vendor must establish an application performance baseline approved by EIPAS Program manager that testers will use as a gauge in the performance of subsequent regression tests of each new release of the application that testers derive the baseline based on repeated load testing, measuring, and system tuning until that time when the system achieves the expected level of performance. The Vendor will perform the repeated load testing, and EEA EIPAS Project team will observe and approve the baseline and will determine if the results are satisfactory. 9.13.2.5

Issue Tracking In the RFR technical response narrative, the Vendor must agree to use the EIPAS Project Team‟s issue tracking software or, propose an alternative software as the primary means of reporting, tracking, and communicating the discovery and resolution of application issues. Vendor developers must use issue tracking software to communicate with the EIPAS Project team and Vendor testers and vice versa. The Vendor must follow EEA guidelines for establishing the priority of issues.

9.13.2.6

Source Code Control In the RFR technical response narrative, the Vendor must indicate that they will apply and be proficient in the use of Team Foundation Server 2010 (TFS 2010) for source code configuration management.

9.13.2.7

Acceptance Process and Criteria During the Contract term, the acceptance process must include, without limitation, the following elements for all major deliverables.


Page 85 of 103

9.13.2.7.a The Vendor submits to the EEA EIPAS Program Manager deliverables, including in the submission a target timeline for EEA response that is consistent with the schedule and in no case less than ten (10) business days after EEA‟s receipt of a major deliverable. If the EEA EIPAS Program Manager does not agree with the timeline, he or she must notify the Vendor‟s Program Manager to determine a mutually agreeable timeframe and resolve any impact that the revised schedule may have on the schedule. 9.13.2.7.b EEA reviews each deliverable and evaluates whether the deliverable has clearly met all criteria established in Master Service Agreement (MSA) design specification(s) and the Contract. 9.13.2.7.c After review and evaluation of the deliverable, EEA‟s EIPAS Program Manager must notify the Vendor‟s Program Manager in writing of the acceptance or rejection of the deliverable. 9.13.2.7.d If the deliverable is acceptable, EEA‟s EIPAS Program Manager must sign a form indicating acceptance and the Vendor‟s Program Manager must acknowledge receipt of the acceptance form in writing. 9.13.2.7.e A rejection of the deliverable by EEA‟s EIPAS Program Manager must include a written description of the defects, errors and/or nonconformities of the deliverable. 9.13.2.7.f Upon receipt of a rejection, the Vendor must correct the specified defects, errors and nonconformities within the period of time specified in the MSA, or any default period set forth in the Contract or time specified by mutual written agreement at time of delivery, and deliver an updated version of the deliverable to EEA‟s EIPAS Program Manager.


Page 86 of 103

9.13.2.7.g After review and evaluation of the updated deliverable, EEA‟s EIPAS Program Manager must notify the Vendor‟s Program Manager in writing of the acceptance or rejection of the updated deliverable, and any rejection must include a description of the way in which the updated deliverable fails to correct the previously reported deficiency or otherwise fails to meet the criteria established in the Contract, MSA, and the design specifications.

10.

PROPOSED TECHNOLOGY ENVIRONMENT It is EEA‟s intent that the EIPAS solution be hosted in either in a private or public cloud, or in the Commonwealth of Massachusetts MITC data center, or a combination thereof, i.e., a distributed hosting environment. In the RFR Response, the Vendor is only required to provide information on an externally hosted solution or distributed solution (external hosting in combination with Accela (hosted at MITC). EEA will review the RFR responses and determine if an externally or distributed hosted environment is appropriate, or, will choose to put the entire environment in the MITC data center. For all externally hosted components, the Vendor must propose in the RFR Response either (i) infrastructure-as-a-service (IaaS) – i.e., hosting for the database and application servers) – or (ii) a true software-as-a-service cloud (SaaS) arrangement or (iii)a Platform as a Service (PaaS). All hosted data must remain in the contiguous United States. Hosting may be provided on a multitenant or private cloud environment. Vendors are not required to provide hosting information or costs for the MITC Data Center.

10.1

Hosting Requirements In the RFR Technical Response Narrative, the Vendor must describe their preferred hosting environment, and the advantages of that environment and provide details responding to the following questions/issues: 10.1.a

What type of Cloud service is being proposed (IaaS (infrastructure), PaaS (platform) or SaaS (software))?

10.1.b

What type of Cloud infrastructure is being proposed (private cloud, public cloud, multitenant, hybrid, community, etc.)?

10.1.c

Is there a limitation on the number of users (internal and external that can be supported?


Page 87 of 103

10.1.d

Is the proposed environment a FedRAMP secure data center, received an Authority to Operation (ATO) on FedRAMP Moderate or have a certification pending? As an alternative, the Vendor must be willing to represent/warrant to EEA in the RFR Response that the cloud meets the FedRAMP moderate standards.

10.1.e

The Vendor must describe in detail the security and privacy advantages of the proposed hosting solution.

10.1.f

Will application hosting be single or multi-tenant with regards to hardware?

10.1.g

Will data storage be provided in the contiguous United States and/or the District of Columbia?

10.1.h

Are charges based upon traffic, usage, storage limits, by user, subscription, or number of transactions?

10.1.i

Will the Vendor provide logical separation, physical separation or both?

10.1.j

Has Vendor passed a “SAS ” Type II audit? If so, is the report available? If not, will it undergo one?

10.1.k

The Vendor must explain the flexibility and scalability of the preferred hosting environment.

10.1.l

The Vendor must explain the expected Response time of the proposed environment and describe the applicable service level agreements including up-time guaranties.

10.1.m

The Vendor must explain any additional benefits of the proposed hosting solution such as load balancing and ability to handle quickly handle spikes in network or internet traffic due to episodic high volume transactions.

10.1.n

If the Vendor is proposing a distributed hosting environment, the Vendor is required to ensure that the data and applications operate seamlessly between the two hosting environments with minimal or unnoticeable lag time. If the Vendor‟s proposal is a distributed hosting environment, then the Vendor must indicate, where known, which components will reside in which hosting environment.

10.1.o

The Vendor must Identify in the COST PROPOSAL ONLY the costs of the hosting environment.


Page 88 of 103

10.1.2

Assignability of Hosting Contract In the RFR Technical Response Narrative, the Vendor must affirm the following assignability of the Hosting Contract to EEA as follows: The winning Vendor that proposes a hosted solution in which hosting services will be provided by a third party shall enter a hosting agreement with a third party hosting provider, subject to EEA‟s review and approval (the “Third Party Hosting Agreement”). In the Third Party Hosting Agreement, the Winning Vendor will flow down any terms that EEA deems relevant from the Agreement entered under this RFR, including without limitation the terms of the Commonwealth‟s Terms and Conditions and Standard Contract Form and all terms pertaining to data security and privacy and prompt notice of security incidents. The term of such Third Party Hosting Agreement shall extend through the initial and all renewal terms of this Contract and for five (5) years thereafter. At the end of the initial term of the Contract entered under this RFR, EEA shall, at its sole discretion, direct the Vendor to assign the Third Party Hosting Agreement to EEA.

10.2

Version and Environment Management In the RFR Technical Response Narrative, the Vendor must describe their proposed approach to version and environment management. As with any software project, EEA expects the successful Vendor to implement comprehensive version control and environment migration procedures. EEA is expecting the apparent selected Vendor to establish the following separate application and database environments for the project: 

Development/unit/accessibility test



System/integration test



User acceptance test



Performance



Staging/preproduction



Production (with failover)



Training/conversion



Disaster recovery

The selected Vendor will be responsible for implementing procedures that protect versions of source code, allow the migration of code and THIS RFI AND ALL RESPONSES HERETO WILL BECOME PUBLIC RECORD EIPAS II RFI EEA-IT-2014-823

Page 89 of 103

configurations from environment to environment, and allow separate configurations by environment. The Vendor is encouraged to utilize tools to aid in the process. As a component of the technical response narrative, the Vendor may also present additional alternative environments, such as the implementation of a migration environment to aid the process of ongoing migration of information and code from one environment to another and/or an environment for data warehousing and reporting. 10.3

Data and System Security In the Vendor‟s Technical Response Narrative, the Vendor must describe with respect to any hosted data, whether on a multitenant or private cloud environment, how the cloud environment will meet FedRAMP moderate security requirements, or, in the alternative, the Vendor must indicate the Vendor‟s planned or pending application for certification with FedRAMP moderate Authority to Operate. Those Vendors who have an application for FedRAMP certification pending must submit a copy of that application as part of the RFR Response. In order to meet this security requirement, the Vendor also has the alternative option of providing detailed information in the Vendor‟s RFR response representing how the Vendor currently meets the FedRAMP moderate standards even if the Vendor has not applied for/obtained the FedRAMP certification referenced above. In the event that the Vendor elects to pursue this alternative option, the Vendor must complete and submit, as part of the RFR Response, the FedRAMP Microsoft Excel matrix found at the following link: www.gsa.gov/graphics/staffoffices/FedRAMP_Security_Controls_072912.zip EEA reserves the right to determine, in its sole discretion, whether the Vendor‟s RFR technical response narrative submitted pursuant to this alternative option complies with this security requirement.

10.4

Data Ownership In the RFR Technical Response Narrative the Vendor must agree that EEA will own all data uploaded to the system and all usage data generated by the system. EEA may license Vendor to use the usage data in evaluating the performance of the system. Vendor must agree that it will return all such data to EEA at the termination of the agreement(s) entered pursuant to this RFR or upon written request of EEA.


Page 90 of 103

10.5

Data Backup, Data Loss Prevention and Recovery In the RFR technical response narrative, the Vendor must indicate how it will provide backup services to minimize data loss in the event of an application or data crash or other system failure. Vendors must indicate in the RFR Response how their proposed EIPAS solution will provide for/address/implement/prevent loss of data with any combination of rollback, failover, mirroring, redundancy, fault tolerance, etc., and describe all notification procedures in the event that a loss should occur. In the RFR technical response narrative, the Vendor must describe the procedures and tools it will use to perform routine daily, weekly and monthly back-up procedures, and describe the procedures and tools the Vendor will use to recover lost data and EIPAS functionality.

10.6

Business Continuity/Disaster Recovery Prior to execution of the MSA, the Vendor must provide EEA with a copy of the following business continuity/disaster recovery plans to demonstrate the Vendor‟s ability to continue the program and to secure the Commonwealth‟s assets as required by the Contract in the event of a disaster. At all times during the term of the Contract, the Vendor must agree to implement the business continuity plan and/or the business continuity and disaster recovery plan when necessary. In the RFR response, the Vendor must affirm that it will provide these documents upon successful Contract negotiation and execution.

10.7

10.6.a

The business continuity/disaster recovery plan for the Vendor‟s business as a whole.

10.6.b

A plan specific to the proposed EIPAS system that extends through the term of the Contract, and all extensions and provides clear timeframes within which the system must be operational given specific scenarios.

10.6.c

Information as to whether the disaster recovery/business continuity plan includes a hot, cold or warm disaster recovery site.

Database Management

10.7.1

Audit Trails As part of the RFR response, Vendors must indicate how the proposed EIPAS solution will provide for/address/implement the following required functions:


Page 91 of 103

10.7.2

10.7.1.a

Maintain and make available audit trails as required

10.7.1.b

Track date, time, and individual who made manual changes

10.7.1.c

Provide the system developer with the means to add comments and reasons

Data Validation As part of the RFR technical response narrative, Vendors must describe how their proposed EIPAS solution will provide for/address/implement the following required functions: 10.7.2.a

The system must prevent or manage duplicate fields/data across applications.

10.7.2.b

The system must automatically evaluate data completeness and accuracy (content validation).

10.7.2.c

The system must automatically prepopulate forms from existing data.

10.7.2.d

The system must be capable of performing error checking at the field and module level, a process referred to here as “validation.” Validation must be both Internal and external. The system must indicate errors as close to the time of entry as possible (e. g., when the user tabs out of the field). Where errors cannot be ascertained until the data entry is complete, the system must offer the user the option to validate their form. Whenever the user validates, the system must save the data and trigger error checking. If there are validation criteria that are not met, then the system must provide error messages and guide the user to the location of the problem data and allow the user to make corrections.

10.7.2.e

All externally (or publicly) facing modules must pass validation before the system will allow signature and submittal of the form. The system must indicate each module‟s validation status to the user so that the user can see which parts are/are not complete in a multi-stage form.

10.7.2.f

Validation rules must be configurable by the internal SMEs to the greatest extent possible.


Page 92 of 103

10.8

System Availability and System Response Time All RFR technical response narrative to this Section should describe their approach, either assuming an externally hosted environment, or a distributed environment with only Accela (if Accela is determined by the Vendor to be the optimal solution for licensing and permitting) in the ITD MITC datacenter or the entire solution hosted at ITD MITC.

10.8.1

System Availability The Vendor must ensure that the EIPAS solution is available 24 hours a day, 7 days a week, 365 days a year with at least a 99.95% up time (excluding regularly scheduled application patches, updates, and enhancements provided that such regularly scheduled downtimes last no longer than 1 hour and are between the hours of 12:00 AM and 3:00 AM prevailing Eastern Time on one weekend day a month, or as otherwise to be negotiated by the Vendor and EEA).

10.8.2

System Response Time The Vendor must describe, in the RFR Technical Response Narrative, the industry standard or better service level that they are proposing for the EIPAS System. The Vendor should also describe the credits that will be provided to EEA if response time requirements are not met.

10.8.3

Externally Hosted/Cloud Availability In the RFR technical response narrative, the Vendor must also answer the following questions/issues pertaining to an externally hosted environment: 10.8.3.a

How is a service outage defined?

10.8.3.b

What tools are in place or will be provided to determine the severity of the outage?

10.8.3.c

How will EEA be credited or compensated for an outage?

10.8.3.d

What level of redundancy will be provided to minimize outages?

10.8.3.e

What alternative methods of access will be offered if there is an outage?

10.8.3.f

Will there be an incident reporting system?

10.8.3.g

What incident response plan will be provided?

10.8.3.h

Will access and/or usage reports be provided?


Page 93 of 103

10.8.3.i

Will there ever be scheduled downtime?

10.8.3.j

How much notice will be provided for scheduled downtime?

10.8.3.k

Describe the scalability of Vendor‟s provision of hosted environment resources.

11. TRAINING AND DOCUMENTATION 11.1

Training In the RFR Technical Response Narrative, the Vendor must include a highlevel draft plan for training that addresses the requirements identified in this Section. The Vendor must deliver training throughout all implementation phases of the EIPAS project. The Vendor must provide appropriate training separately for each phase. Training plans must reflect the phased implementation of capabilities and EEA expects that ongoing training will be provided throughout the project', without duplicating effort. EEA will collaborate with the Vendor on the final definition and timing of delivery of training after Contract award. The Vendor‟s proposed training plan must prepare end users, workflow developers, system administrators, and IT staff for EIPAS use, modification, refinement, and maintenance of all aspects of the system. All training must be appropriate for specific users and functionality.

11.2

11.1.a

In the RFR Response, the Vendor must describe their proposal for the following training requirements. All responses should include frequency and type(s) of training proposed.

11.1.b

End-user internal training: Use and configuration of the system

11.1.c

End-user external training materials

11.1.d

EEA/IT staff: EIPAS maintenance

11.1.e

Subject matter expert and EEA/IT Staff Administration and Configuration and use of the system

11.1.f

System user documentation at the time of the training

System Documentation The Vendor must provide, as part of the RFR Technical Response Narrative, the Vendor‟s proposal for providing specific technical, administrative and end user documentation for each component/application as it is released


Page 94 of 103

into production. The Vendor must update documentation if any component or application is modified, up to and including the final warranty period. Documentation shall, among other things, cover:

11.3

11.2.a

All applications developed

11.2.b

All components and applications developed

11.2.c

All end user and IT Training materials

11.2.d

In the RFR technical response narrative, the Vendor must describe their process for compiling documentation and how they will develop and distribute documentation throughout the EIPAS Project.

Knowledge Transfer The Vendor must provide ongoing knowledge transfer, as well as comprehensive knowledge transfer sessions at the conclusion of the EIPAS Project. Knowledge transfer includes sessions with EEA/IT staff as well as with Agency SMEs. Vendors must describe in the RFR technical response narrative how the Vendor will meet the following requirements: 11.3.a

Knowledge transfer that occurs at logical timeframes, such as implementation of a significant project component (such as, but not limited to, an application deliverable.)

11.3.b

The Collaboration process between the Vendor and EEA/IT on knowledge transfer throughout the project.

11.3.c

Vendors‟ RFR Response must build into the schedule detailed and comprehensive knowledge transfer sessions.

12. MAINTENANCE 12.1

Definition of Maintenance Requirements The maintenance requirements listed in this Section Maintenance, refers to the following: 

The entire period before acceptance and the maintenance period contract for after system acceptance



All Vendor- and third-party hosted hardware and software



All software, including COTS, open source, proprietary, and custom developed products


Page 95 of 103



All provided infrastructure and applications software



Both production and test systems



All APIs and integration tools



All migration tools



For all software elements of the system, the Vendor must provide:



Routine daily, weekly and monthly back-up procedures of the computing environment



All IT support activities for the system, including but not limited to database and application server maintenance, error troubleshooting, and enhancements

Procedures that protect versions of source code, allow the migration of code and configurations from environment to environment, and allow separate configurations by environment 12.2

Maintenance Tools In the RFR Technical Response Narrative, the Vendor must describe the tools it is proposing to utilize to ensure these maintenance requirements are met.

12.3

Maintenance and Support Agreements for COTS Software Components The Vendor must submit in its RFR Technical Response Narrative a maintenance and support agreement for each proposed COTS software component, regardless of whether the software is provided by the Vendor or by third-party vendors, which agreement shall include a requirement that the third-party vendor for such COTS software component cooperate with the Vendor with respect to the obligations set forth in Attachment 6, Section 1.2 Accessibility. Each agreement must extend for a period beginning on the expiration of the warranty period for such COTS software component, which warranty period shall be a minimum of 12 months following the acceptance of such COTS software component by EEA, and ending on a date 1 year beyond the end of the Warranty Period. The Cost Response (but not the Technical Response) must specify the cost to EEA for each year of the agreement for such period. For any COTS software, for time and materials maintenance contracts, maintenance rates and hourly personnel rates may not be increased for the first five (5) years and may thereafter be increased only once in any state fiscal year. Any such increases are limited to 3% over the rate from the previous year


Page 96 of 103

For any SaaS/IaaS/PaaS services, the rate for those services should be fully loaded and include, without limitation, all maintenance and support costs (including technical support availability for EEA) and hardware refreshes, if any. 12.4

Maintenance and Support Services At the conclusion of the Warranty Period for the completed EIPAS System, the Vendor must make services available to EEA for maintenance and support of the completed EIPAS System, inclusive of all products delivered or developed under the Contract, in addition to any maintenance and support agreements that may apply to COTS software components. EEA may, at its discretion, execute one or more task orders with the Vendor for such services. The Vendor must include a rate schedule for a fixed pool of hours of maintenance and support services for each task order in addition to the completed EIPAS System in Attachment 4 Pricing Matrix and Rate Table in the Cost Response. The duration of the maintenance and support plan must extend for a period beginning at the end of the Warranty Period and ending three (3) years thereafter. The Cost Response (but not the Technical Response) must specify the cost to EEA for each year of the maintenance and support plan for such period. Details regarding the Vendor‟s maintenance and support plan, including the cost of the plan, for the completed EIPAS System will be negotiated by EEA and the Apparent Successful Vendor at the appropriate time, and, if possible, prior to the execution of the Master Service Agreement.

12.5

Scope of Maintenance and Support In the RFR Technical Response Narrative, Vendors must provide detail on how they will meet the following requirements: 12.5.a

Vendors must resolve problems, answer questions, and implement system modifications during the Contract term. In the RFR response, Vendors must describe their system for reporting, documenting, and tracking support requests and problem logs, including specific software that the Vendor must provide for this project.

12.5.b

Problem reporting and tracking via software that allows entry of problem logs by EEA staff and review of status and progress on those logs by EEA‟s EIPAS Program Manager


Page 97 of 103

12.5.c

Telephone and email support during regular business hours (8:00 AM – 5:00 PM prevailing Eastern time, Monday through Friday, excluding legal or bank holidays for or in the Commonwealth of Massachusetts) for problem determination, verification, and resolution, or instruction as to workaround, as applicable

12.5.d

Diagnosing and remedying defects, errors, and nonconformities and providing resolutions, and, to the extent expressly permitted by EEA, workarounds, within the periods of time specified in writing.

12.5.e

In the RFR technical response narrative, in addition to adhering to the above requirements, Vendors must describe the level of support they will provide to EEA, in an emergency outside business hours

12.5.f

In the RFR Technical Response Narrative, Vendors must agree to provide maintenance and support for all defects reported by EEA or by any other of the Vendor‟s customers or identified by the Vendor itself for each of the severity levels listed in Exhibit 6. Ideally, the Vendor‟s maintenance and support plan for the completed system and all software must meet the following performance objectives.


Page 98 of 103

Exhibit 6: Severity Level Table Severity Level 1

Severity Level 2

Severity Level 3

Description

A defect, error or nonconformity that results in a failure of one or more critical functionalities of the deliverables, including, without limitation, the completed system, or that impairs the performance of substantially all major functions of the deliverables.

A defect, error or nonconformity that is cosmetic in nature and that does not interfere with any use or functionality of the deliverables, including, without limitation, the completed system. EEA may, in its sole discretion, escalate any Severity Level 3 defects, errors or nonconformities to Severity Level 2 if sufficient progress is not being made toward resolution.

Initial Call Back Response Minimum Temporary Requirement

1 hour

A defect, error or nonconformity that results in a loss of, or limits, required functionality of the deliverables, including, without limitation, the completed system, or a high risk that the deliverables may not perform critical functions. EEA may, in its sole discretion, escalate any Severity Level 2 defects, errors or nonconformities to Severity Level 1 if sufficient progress is not being made toward resolution. 1 hour

1 hour

NA

8 hours continuous efforts to develop a work around prior to resolution within thirty (30) days

48 hours

2 hours NA

Within the next scheduled release.

NA

Permanent Resolution

8 hours continuous efforts to develop a work around prior to resolution 10 days for a resolution which is adequately tested to meet the specifications.

Inquiries

Each maintenance and support agreement for a COTS software component must include error correction and maintenance releases, new versions, and new releases. The maintenance and support plan for the completed EIPAS System must include, in addition to the above, services for installation, configuration, and customization of new releases of COTS software components used in the completed EIPAS System. EEA may submit an enhancement request to the Vendor in writing, and the Vendor must evaluation any such submission for possible inclusion in future maintenance or in new releases. All provisions of the Contract relating to Accessibility apply to deliverables provided to EEA under both COTS software maintenance and support agreements and the completed EIPAS System maintenance and support plan. All maintenance and support must be provided in English. THIS RFI AND ALL RESPONSES HERETO WILL BECOME PUBLIC RECORD EIPAS II RFI EEA-IT-2014-823

Page 99 of 103

12.6

Maintenance, Support and Hosting Costs In the Cost response – but not in the Technical Response – the Vendor must include pricing for:

12.7

12.6.a

The rate at which the Vendor will provide support for additional changes or services

12.6.b

Maintenance and support services for all COTS comprising the EIPAS System, including updates and upgrades

12.6.c

Hosting Costs

12.6.d

SaaS, PaaS or IaaS service fees

12.6.e

Per-year maintenance and support costs for the period beginning at acceptance of the completed system and ending at the term of the Contract, including any extensions

12.6.f

A rate schedule for a fixed pool of maintenance and support services hours per year for the completed system

12.6.g

Annual rate for maintenance and support for the COTS software components on a 1-year, 2 and 3-year basis

12.6.h

Vendor must provide copies of all available maintenance and support plans (e.g., silver, gold, platinum).

Maintenance for Versions and New Releases EEA requires the Vendor to implement the completed system using current releases of all deliverables. Therefore, prior to commencement of testing and refinement of each deliverable, the Vendor must: 12.7.a

Evaluate the release for inclusion in the completed system

12.7.b

Make a recommendation to EEA as to whether it is feasible to implement the current release or any major release of each deliverable, if different from the version currently included in the pre-testing version of the completed system


Page 100 of 103

12.7.c

If the current release or any major release (a) is available in an actual production version (rather than as a beta or pilot version); (b) has proven to be stable and generally error-free in production; (c) provides new functionality within the scope; and (d) must not impair the overall robustness of the system or otherwise interfere with the requirements, then the Vendor must recommend to EEA that such current release or any major release be implemented prior to the commencement of testing, subject to any mutually agreed upon terms regarding the timing and cost of such implementation if the originally agreed upon timing and cost are affected in any way. EEA‟s Program Manager must make the final determination regarding whether or not to implement any such current release or any major release recommended by the Vendor and the Vendor must abide by such determination.

12.7.d

Vendors are reminded that the maintenance and support plan must include error correction and maintenance releases, new versions, and new releases. The Vendor must deliver new releases to EEA upon EEA‟s request.

12.7.e

The vendor must regression test components prior to release.

13. REPRESENTATIONS AND WARRANTIES 13.1

Requirements The Vendor must make the following representations and warranties in its RFR Response: 13.1.a

Each deliverable in the completed EIPAS System will conform to the criteria established in the applicable task order(s) and the Master Services Agreement, the relevant task order specifications, and the requirements set forth in Attachment 3: Requirements Tables, including any requirements and designs incorporated by inclusion of prior deliverables

13.1.b

No software provided to EEA (whether or not via a subcontractor, sublicense, etc.) will contain disabling devices. A disabling device includes any virus, worm, built-in, or use-driven mechanism, injurious or damaging algorithm, time bomb, or other software or hardware that can disable or adversely affect the use of the software (delivered by the Vendor) or harm any of EEA‟s data, network, or other software


Page 101 of 103

13.1.c

All of the technology-related components of the completed EIPAS System will be interoperable with one another, as intended, including, backward and forward compatibility among versions and interoperability with components/systems.

13.1.d

The completed EIPAS System will comply with all applicable security procedures during the duration of the Contract as specified in this RFR and in all subsequent documents forming this Contract. From time to time during the duration of the Contract, EEA will notify the Vendor of such applicable security procedures and the Vendor must modify the completed EIPAS System or any deliverables previously accepted, as applicable, to meet such security procedures at no additional cost to EEA.

13.1.e

The Vendor will obtain all necessary government authority or other third-party permissions, clearances, licenses, and consents to perform the services and deliver the deliverables, copies of which shall be provided to EEA upon execution of the Master Services Agreement and otherwise upon EEA‟s request.

13.1.f

Throughout the duration of the Contract, the services will be performed, and all deliverables will be developed and provided under the Contract, in compliance with all applicable federal, state, and local laws, rules, and regulations that may be applicable to the Vendor‟s duties under the Contract.

13.1.g

The Vendor has sufficient rights in the deliverables to grant to EEA the rights and licenses granted under the Contract and is not aware of any asserted or unasserted third-party claims challenging or affecting any right granted under the Contract.

13.1.h

The services and/or the deliverables, including, without limitation, the completed EIPAS System, provided under the Contract will not infringe or misappropriate any intellectual property, contractual, or other proprietary right of any third-party.

13.1.i

If any COTS software component included in the deliverables (including software developed by the Vendor and software that has been supplied by third-party suppliers) is subject to a separate shrink-wrap or click-wrap license, EEA‟s operation of the COTS software component or licensed deliverables (including, without limitation, opening the shrink-wrapped package or clicking “accept” or “OK” or the like) shall not limit any of EEA‟s rights or the Vendor‟s obligations under the Contract, except as specifically set forth in the Contract or in a writing signed by EEA and the Vendor.


Page 102 of 103

13.1.j

The (i) Vendor has the right, power and authority to enter into and perform its obligations under the Contract; (ii) the individual executing the Contract is authorized to do so; (iii) nothing contained in the Contract or the performance of the Contract will cause the Vendor to materially breach any other contract or obligation; and (iv) the Vendor and its subvendors are sufficiently staffed and equipped to fulfill the Vendor‟s obligations under the Contract.

13.1.k

The services will be performed (i) by appropriately qualified and trained personnel; (ii) with due care and diligence and to a high standard of quality as is customary in the industry; (iii) in compliance with the applicable schedules; and (iv) in accordance with all applicable professional standards for the field of expertise.

13.1.l

The Vendor may, upon receipt of prior written approval by Vendor(i) incorporate any open source software into, or combine open source software with, the deliverables or use open source software to provide the deliverables; or (ii) distribute open source software in conjunction with or for use with the deliverables.

13.1.m

Documentation provided by the Vendor under the Contract shall be in sufficient detail so as to allow suitably skilled, trained, and educated EEA personnel to understand the operation of the deliverables. The Vendor shall promptly, at no additional cost to EEA make corrections to any documentation that does not conform to this warranty.

14. NONCOMPLIANCE WITH REQUIREMENTS Vendors must clearly identify any requirements of this RFR in that they cannot meet in whole or in part. In these instances, for each requirement, Vendors must clearly state that they cannot meet the requirement and propose alternative solutions that would address any such requirements, together with any qualifiers/assumptions and/or constraints. In addition, Vendors must document their inability to meet any requirements in Attachment 3 the Requirements Table.


Page 103 of 103