Attachment T- Answers to Questions from Offerors.xlsx
XLSX spreadsheet 110 KB Posted
- Attached to
- ECONOMIC SVCS SYSTEM APP MODERNIZATION State and local contract opportunity
- Solicitation number
- 5400024945
- Issued by
- Richland County, South Carolina
About this file
This document is a comprehensive Q&A response file from the South Carolina Department of Social Services (DSS) addressing vendor questions regarding the Economic Services System Application Modernization (ESSAM) RFP. The ESSAM project seeks a prime contractor to design, develop, and implement a modern replacement system for the legacy Client History Information Profile (CHIP) mainframe system supporting SNAP and TANF benefits administration. The DDI phase is variable, anticipated between 2-4 years depending on the vendor's proposed solution approach (COTS, SaaS, transfer, or hybrid), followed by an 8-year maintenance and operations (M&O) phase consisting of 2 years of initial warranty and M&O coverage plus three optional 2-year renewal terms. The project involves approximately 1,125 core Economic Services staff users plus approximately 500 secondary and view-only users across South Carolina. Mandatory qualifications require vendors to have performed as prime contractors on comparable SNAP/TANF system implementations within the last 5 years with full operational status, and vendors must provide three prior state government references. The RFP encompasses requirements for system functionality including eligibility determination, program integrity, appeals and hearings processing, data conversion from legacy systems (CHIP, SCOSA, WINS, SCCES), disaster recovery capabilities, comprehensive testing protocols, training and knowledge transfer, and integration with multiple state and federal interfaces including AWS Connect, OnBase, and various federal systems.
The State identified preferred technology standards including Microsoft Azure, PowerApps, Power Automate, Office 365/SharePoint, Hyland OnBase, Azure SQL Services, Power BI, and SSIS, though vendors may propose alternatives with documented business and technical justification. Data conversion includes approximately 8.3 million image files (approximately 20TB) from SCOSA dating back 4 years, plus all data from current CHIP, WINS, and SCCES systems. The pilot implementation will be conducted at DSS locations in Columbia followed by a phased rollout across four geographic regions (Upstate, Pee Dee, Midlands, and Low Country), with a minimum 3-month production pilot period. Vendors are responsible for securing regional training facilities, conducting end user system training for all 1,125 core users, and establishing Tier 1 Help Desk operations with anticipated annual ticket volumes of approximately 20,000 based on current system metrics. The State will procure separate Quality Assurance and Independent Validation and Verification contractors and will provide a Project Management Office with dedicated State resources. Performance metrics include strict deliverable acceptance criteria with 10-business-day first-round review periods and 5-business-day subsequent review periods for all deliverables, with 10% payment witholds for non-compliance against defined performance targets during both DDI and M&O phases.
View the file
Other files for this state and local contract opportunity
Show all 22
On GovTribe
Work with this file on GovTribe
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Vendor Questions & DSS Response
| Question # | Page # | Subsection | RFP Language | Question | State's Response | RFP or Attachment(s) Updated | Document Changes Made |
| 1 | Page #: Attachment A – ESSAM Requirements Definition | Sub Section: Tab T5. Technology Preferences | RFP Language: Items T5.1 – T5.9 | Question: Does DSS currently use any of the technologies deemed preferred on Tab T5. Technology Preferences? If yes, which ones specifically? | Response: Those in T5 deemed Mandatory are currently in use at SC-DSS; And those deemed Preferred are: MS Azure PowerApps, Power Automate, Microsoft Office 365 / SharePoint and Hyland OnBase, Microsoft Azure SQL Services, Microsoft Power BI, Microsoft SSIS and Azure Data Factory (ADF). | No | |
| 2 | Page #: Attachment A – ESSAM Requirements Definition | Sub Section: Tab T5. Technology Preferences | RFP Language: “Preference: DSS deems this a ‘Preferred’ technology. The state prefers that the Contractor included this technology in their ESSAM Solution Architecture.” | Question: For the technologies specifically named as a DSS “Preference”, are there any scoring impacts if these technologies are not proposed? | Response: Per the RFP, Evaluation Factor(s) - Proposal Shows Thorough Understanding and Compliance with Business & Technical Requirements = 30%. Scoring will be based on the entire solution proposed by the vendor including hosting and platform options. Utilizing DSS Technical Solution Standards and preferences wherever possible for the Vendor’s proposed solution is desirable by DSS, and aligns more closely with the envisioned “To-Be” solution and technical requirements. When proposing alternatives, please include a detailed business and technical justification that demonstrates how the vendor’s proposed solution approach can meet the same requirements and benefits at the same or better cost. | No | |
| 3 | Page #: 21 | Sub Section: 3.2.3.1 | RFP Language: Deliver the functionality detailed in the DSS-approved ESSAM Requirements Definition Document (RDD) (Error! Reference source not found.) | Question: Does the State have a preference for vendors to expand on their responses in the body of our RFP responses or in the comment column in Attachment A? | Response: Vendors should use their Proposal to provide expanded responses to requirements - ensuring that Proposal responses do not conflict with the comments column of the Requirements Definition Document (RDD). | No | |
| 4 | Page #: 68 | Sub Section: 3.13.3.1.17 | RFP Language: Utilize the most current version of FNS’ SIRT to evaluate whether the System delivered meets all SNAP functional requirements, if applicable. Work with DSS staff to use the tool to validate System functionality before UAT. | Question: Are there any special waivers from FNS regarding the SNAP program that should be considered? If yes, can you provide more details? | Response: The only current waiver in place with SC is the Conduct Unscheduled Interviews. This allows SC to have a Interview Center that accepts inbound calls for completing federal interview requirement for applications and renewals/annual recertifications. SC does have three Federal approved Demonstration projects that have been in place for years and should be expected to continue. These two Demonstration projects are 1) The South Carolina Combined Application Program' (SCCAP) and The Elderly Simplified Application Program (ESAP) and 3) The Standard Medical Deduction (SMD). | No | |
| 5 | Page #: 24 | Sub Section: 3.4.2.1 | RFP Language: DSS must approve the contents of the Deliverable Expectation Document for each deliverable. Any work not done in compliance with the DED must be revised at no additional cost to DSS and no impact to the defined schedule | Question: Will the DED approval process follow the documentation approval process with 10 business days for State first round review and 5 business days for State second round review? | Response: Please see 3.4.7.11.3 for the DSS Submission and review process. | Yes | Section 3.4.2.1. - Each Contractor deliverable will be defined by a Deliverable Expectation Document that must contain the format of the deliverable, deliverable components, deliverable schedule, and associated detailed acceptance criteria. The contents of each deliverable must be determined no less than 30 calendar days prior to the time that work begins on that deliverable. DSS must approve the contents of the Deliverable Expectation Document for each deliverable. Any work not done in compliance with the DED must be revised at no additional cost to DSS and no impact to the defined schedule. |
3.4.7.11.3 - 3.4.7.11.3. - Following Deliverable Expectation Document (DED) or Deliverable submission, DSS and Contractor must adhere to the following process and timelines:
| 3.4.7.11.3. | Following Deliverable Expectation Document (DED) or Deliverable submission, DSS and Contractor must adhere to the following process and timelines: | |||||||
| 3.4.7.11.3.1. | Step 1 - State Review(s): DSS will review and either approve or reject each DED or Deliverable. A rejection will be accompanied by a list of deficiencies. | |||||||
| 3.4.7.11.3.2. | Step 2 - Contractor Update(s): Contractor must make all changes identified by DSS and resubmit a DED or Deliverable to DSS for review and approval. | |||||||
| 3.4.7.11.3.3. | Step 3 – Acceptance: Following submission or resubmission, acceptance of all Contractor Deliverables will be communicated via the controlled correspondence process (see Section 3.4.7.7.4 above). DSS will not consider any Deliverable to be final or eligible for payment until the Deliverable has been accepted. | |||||||
| 3.4.7.11.3.4. | The Contractor must include at least 10 Business Days per DED and deliverable in the project schedule so that DSS staff may conduct a complete review and provide comments to the Contractor. Based on the review comments for each DED or deliverable, DSS may grant approval of the DED or deliverable, reject the complete DED or deliverable, or require the Contractor to revise portion(s) of the DED or deliverable. DSS will require additional 5 Business Day periods to review revised DED or deliverables whenever DSS rejects complete DED or deliverables or portions of DED or deliverables or whenever DSS makes comments that require DED or deliverable to be revised. Upon Contractor’s written request, DSS may agree to extend the time periods set forth at its sole discretion on a case-by-case basis. However, DSS will not unreasonably withhold its consent. DSS will provide Contractor with the reasons DSS rejected a DED or deliverable. | |||||||
| 3.4.7.11.4. | In addition to DSS, DEDs or Deliverables may be subject to review by various state organizations, the IV&V contractor, and USDA FNS. | |||||||
| 6 | Page #: 26 | Sub Section: 3.4.7.1.1 | RFP Language: In conjunction with the DSS project team, the Contractor must plan and conduct the project kickoff meeting within 10 business days following the Contract Effective Date or on other date mutually agreed upon by the Parties. Key stakeholders will be in attendance, including program area staff representing Economic Assistance, Appeals and Hearings, and Program Integrity. | Question: Will the Kick-off meeting be virtual, in person at DSS office, or hybrid? | Response: ESSAM Kickoff Meeting will be onsite at one of the DSS Locations in Columbia, SC. | No | ||
| 7 | Page #: 27 | Sub Section: 3.4.7.4.4.4 | RFP Language: The Contractor must manage and update the Project Schedule weekly and provide the latest version to the State PMO along with a weekly Project Status Report | Question: Is it acceptable to resource load the initial draft project schedule with generic State resources until actual State resource availability is known? | Response: Yes, it is acceptable to resource load the initial draft project schedule with generic State resources for the proposal submission. Although if selected, the Software Development Contractor will within the first 90 days of project initiation, work with the State to elaborate the State Resources for 90 days into the future as described in section 3.4.7.4.4.2. The detailed tasks 3 months into the future may have generic State Resources if not known at the time of project plan creation. | No | ||
| 8 | Page #: 28 | Sub Section: 3.4.7.4.5.1 | RFP Language: The Project Management Component must encompass the planning, management, direction, and control of all contracted work performed by the Contractor or its Subcontractors. The contractor must initiate, effect, conduct, and coordinate all ESSAM Project activities with their Subcontractors, DSS, the ESSAM Project Team, and others with a stake in the ESSAM Project, including without limitation the IV&V Contractor, the Quality Assurance contractor, and the ESSAM Executive Committee. | Question: Is the Contractor responsible for the contractor-level Project Management Plan or the project-level Project Management Plan? | Response: There will be only one ESSAM Project Management Plan (PMP) for which the Software Development Contractor (SDC) and State will work together to establish and approve. The Software Development Contractor (SDC) is responsible for the creation, maintenance and updates to this project management plan. SDC will utilize provided sample State Project Management Plan (PMP) and subsequently apply SDC methodology wherever appropriate. Both the selected SDC and State will adhere and operate the project according to this approved PMP. State does not recognize Contractor-level versus Project-level Plan(s). | No | ||
| 9 | Page #: 29 | Sub Section: 3.4.7.5.3.2 | RFP Language: Schedule Management Plan: This plan must describe how the project schedule itself will be managed, how actual activities will be monitored and managed to the Plan, and how status will be reported. | Question: Is the Contractor responsible for contractor-level Schedule Management or project-level Schedule Management? | Response: See answer to question #8. There is only one Schedule Management Plan and the Software Development Contractor (SDC) is responsible for the Schedule Management Plan and ESSAM Project Schedule. The State will initially approve the plan and provide input on a weekly basis, but the maintenance of the plan on a weekly basis with input from OCM, IVV, State Resources, interface partners etc. will be the responsibility of the selected Software Development Contractor (SDC). | No | ||
| 10 | Page #: 98 | Sub Section: Table 10 – Critical Incident (Service Request Severity Level 1) Resolution Completion Time | RFP Language: Description: Critical incidents (service requests with severity level of 1 with initial response in 4 hours or less and resolution in 1 to 3 business days over the measurement period, per timeline requirements in Error! Reference source not found. | Question: It appears the measurement does not match the description. The description requires resolution for Level 1 Incidents within 3 business days. The measurement calls for 2 hours resolution time. Can the State clarify? | Response: The State is correcting Table 10 to refer to verbiage and response times for Table 8 | Yes | Measurement: Number of Critical severity incidents/service requests resolved within the agreed to timeline according to severity level 12 hours divided by the total number of Critical severity incidents/service requests. Reported monthly. | |
| 11 | Page #: 99 | Sub Section: Table 10 – Response to Patches and Fixes | RFP Language: Description: Release patches/fixes to the production environment (aligned with DSS' release process) in less than or equal to 30 calendar days from when the software vendor released the patch/fixes for software used in the System. | Question: Can the State clarify this performance measure applies to Third Party Software patches/fixes only? | Response: These metrics are related to third-party / vendor controlled products (i.e., Microsoft or Oracle releasing patches to their OS or RDBMS solutions). Critical fixes to the application or infrastructure under Software Development Contractor control fall under defect management, incident response categories. | No | ||
| 12 | Page #: 100 | Sub Section: Table 10 – Response to Patches and Fixes - Critical Security Patches | RFP Language: Description: Release critical patches/fixes to the production environment (aligned with DSS' release process) in less than or equal to 5 calendar days from when software vendors released the critical patch/fixes for software used in the System. | Question: Can the State clarify this performance measure applies to Third Party Software patches/fixes only? | Response: Performance measure applies to Third Party Software patches/fixes. | No | ||
| 13 | Page #: 100 | Sub Section: Table 10 – Documentation Updates | RFP Language: Description: Update documentation and receive approval from DSS for updated documentation in less than or equal to fourteen (14) calendar days from the day a change is introduced to the System (e.g., new software is deployed) or processes (e.g., personnel changes involved in disaster recovery). | Question: Can the State provide the timeframes for first and second State review periods on documentation updates? | Response: The State and Vendor usually make the design and updates to the functional and technical designs & documentation (Training, User Manuals etc...) prior to the implementation of changes into the production environment. Under normal circumstances the review process will follow the standard documentation approval as outlined in RFP section 3.4.7.11.3.4. See Solicitation document. |
| The questioned RFP language appears to be a unique scenario where a quick production fix is needed for a Severity Level 1 or 2. The documentation of changes may lag, but the State will expedite the review of the changes to accommodate the 14 day post implementation timeline OR provide an exception to the vendor whenever this is not feasible or possible. | No | |||||||
| 14 | Page #: 288 | Sub Section: Attachment L – FNS Handbook 9019 | RFP Language: 5.5.2.2 System Adaptability Service Oriented Architectures (SOA) has emerged as the primary enabling approach for system adaptability. SOA provides the means to support legacy applications, to interface with disparate programming technologies, and to support multiple platforms. | Question: The FNS handbook provides SOA design principles for system adaptability. Similar to SOA, is there specific guidance on the use of microservices from an enterprise architectural perspective? | Response: The ESSAM project considers Microservices to be a SOA design pattern. A microservice is a tightly scoped, highly cohesive, strongly encapsulated, loosely coupled, and independently deployable and scalable software component. Microservices architecture (MSA) applies the principles of service-oriented architecture (SOA), DevOps and domain-driven design to the delivery of distributed applications. Use of MSA has four core objectives: increasing agility, enabling autonomous teams, improving deployment flexibility and supporting precise scalability. SC DSS will consider the appropriate use of Microservices within the proposed solution architecture as favorable and relevant towards the broader goals of adaptability. There are no additional guidance and/or requirements related to use of Microservices from an Enterprise Architecture point of view. | No | ||
| 15 | Page #: N/A | Sub Section: Attachment C – Current Technologies and Standards | RFP Language: List of technologies | Question: Besides Software AG, which other technologies/tools is DSS planning to sunset? | Response: All of the Mainframe technologies associated with the CHIP System Software AG (NATURAL, ADABAS, PREDICT, CONNX), COBOL, ASSEMBLER, IDMS, CA7. | No | ||
| 16 | Page #: N/A | Sub Section: Attachment C – Current Technologies and Standards (Lines 22 to 27) | RFP Language: List of technologies | Question: Lines number 22 to 27 display multiple enterprise service bus technologies. What is the license expiration date on each ESB tool? We would like to understand if any long-term contracts that may prevent sunsetting a specific ESB tool. | Response: Line 22-27 are mainframe technologies for the Enterprise Service Bus / Integration Broker for DSS' existing CHIP Mainframe. Once the ESSAM solution is implemented Statewide and the ESSAM application has stabilized, DSS will determine appropriate time to sunset the mainframe and other technologies. There is no expiration date or deadline for support of these technologies at this time. Software Development Contractors should assume the mainframe will be available until at least after the warranty period post Statewide implementation. State will work with existing platform service providers to decommission mainframe, which will not involve selected ESSAM Software Development Contractor. | No | ||
| 17 | Page #: 56 | Sub Section: Table 6 | RFP Language: “This system has capacity issues and needs improved functionality to allow for precise document tracking and accounting.” | Question: With regard to the SCOSA system, pg. 56 says “This system has capacity issues and needs improved functionality to allow for precise document tracking and accounting.” But page 70 lists it as a legacy system from which data needs to be converted/migrated, and requirements from Attachment A seem to suggest that SCOSA will be replaced. Does the State intend to replace the SCOSA system as part of this project or enhance it? | Response: SCOSA is DSS' current SNAP/TANF imaging and workflow system. The images\imaging portion residing in SCOSA will be converted by the vendor into a State hosted OnBase Image Repository based on the case related conversion rules. The expectation is that the SNAP\TANF workflow will be part of the vendors’ proposed solution. In the future, the vendor solution should have an interface with the State's OnBase system. Please expand and clarify if this request contradicts an imbedded imaging solution for the SDC's proposed solution. | No | ||
| 18 | Page #: 69 | Sub Section: 3.14 Data Conversion and Migration | RFP Language: Data conversion process, including steps to ensure accuracy and completeness of the converted data. | Question: Is there a complete list of legacy systems from which data needs to be converted/migrated? | Response: The legacy systems from which data needs to be converted/migrated are CHIP, SCOSA(Images & Workflow), WINS and SCCES (Benefits Portal) | No | ||
| 19 | Page #: 73 | Sub Section: 3.16 Pilot Implementation | RFP Language: The Contractor must roll-out a pilot implementation | Question: Would the State consider a more phased rollout approach rather than a single pilot implementation followed by statewide rollout? | Response: It is the State's intention to have a pilot plus a certain number of rollouts post successful pilot. The State will work with the Software Development Contractor (SDC) to determine best rollout strategy. It is desired that ESSAM would have Pilot + 4 Regions(Geographically). | No | ||
| 20 | Page #: Attachment A | Sub Section: FR5 Program Integrity Tab | RFP Language: Referral use cases | Question: Program Integrity - Can you elaborate on creating program integrity referrals that are for members not known to the system? Shouldn’t all benefit recipients be known to the system? Our solution in other states requires newly created referrals to be created on an existing case. | Response: For DSNAP, specifically, the Agency may issue benefits to current recipients and non-recipients. At present, regular SNAP and DSNAP are handled through two different systems. We have to be able to identify benefit issuance based on type for reporting/program integrity purposes. | No | ||
| 21 | Page #: Attachment A | Sub Section: FR Tabs | RFP Language: FR5.10, FR5.12, FR5.21 | Question: What is the expected form of transfers of referrals to other state agencies. Are these electronic transfers? | Response: The Agency needs a way to electronically send referrals for services to other agencies, and we also need a way to track referrals. | No | ||
| 22 | Page #: Attachment A | Sub Section: FR Tab | RFP Language: FR5.23 | Question: What is the Investigation Case Management System? I don’t see it in the list of current technologies or in the list of interfaces (Attachments C and D). | Response: This is Program Integrity Pondera System, which is no longer in use. The Requirement (FR5.23- "FR 5.23 - The System will establish a connection and interchange information with the Investigation Case Management System") has been removed. If the Software Development Contractor has a standard interface for this functionality, please let the State know as part of the Proposal response. | Yes | Appendix A - requirement strikethrough\removal - "FR5.23 - The System will establish a connection and interchange information with the Investigation Case Management System" |
BGD 9/26/2023 - Removed this requirement - we will not need it anymore.
| 23 | Page #: Attachment A | Sub Section: FR Tab | RFP Language: FR5 | Question: For which benefit types will the system maintain the claims for? Only SNAP and TANF? | Response: Yes, the system will only handle SNAP and TANF benefit types. | No |
| 24 | Page #: Attachment A | Sub Section: T5 | RFP Language: Application Platform PowerApps/ LogicApps/ Dynamics 365 as target platform for mission-critical Apps | Question: Is an application platform preferred over a transfer system? | Response: The State is seeking the best proven solution with the lowest risk. The State has no preference and is not restrictive or prescriptive on what the solution might be. | No |
| 25 | Page #: N/A | Sub Section: N/A | RFP Language: N/A | Question: I know you replied negatively in the pre-proposal conference. I would ask again for a list of the attendees. My reasoning is based on the fact that some of us might want to provide sub-contract services the primes may need. I’d like the chance to interact with those potential prime vendors. My particular company is not a program provider. But we may have some complementary services for their solution. I’d appreciate your reconsideration. | Response: No, the State will not provide a list of participants at the pre-proposal meeting. | No |
| 26 | Page #: 21 | Sub Section: Project Overview | RFP Language: N/A | Question: What outcomes or benefits do you expect to achieve through this modernization effort? | Response: Refer to Section III, 3.3 ESSAM Vision on page 23 of the solicitation. Also, please review Attach R-ESSAM_Business_Process_Analysis_Report section 3 - Program Vision, Drivers and Imperatives to fully understand "What DSS is looking to achieve through this modernization effort". | No |
| 27 | Page #: 24 | Sub Section: General Project Requirements | RFP Language: NA | Question: Who are the primary users of the current legacy IBM application, and what roles or functions do they perform within SC DSS | Response: Staff determining eligibility and other associated functions for both SNAP and TANF benefits are the primary users of the CHIP system. Other users include but not limited to staff in the following areas: clerical, Quality Control, Management Evaluation, Program Quality Assurance, state-level management, SNAP/TANF policy/procedures, Performance Coaches, Senior Consultants and DSS Connect. | No |
| 28 | Page #: 24 | Sub Section: General Project Requirements | RFP Language: NA | Question: Can you provide an estimate of the number of users who will interact with the new COTS/SaaS application? | Response: We have an estimated total of 1643 total users, which include 1125 primary core users from Economic Services (Eligibility Workers, Supervisors, Team Leads and Performance Coaches). | No |
| 29 | Page #: 26 | Sub Section: Project Management | RFP Language: NA | Question: What are the primary needs and expectations of the user community with regard to the modernization of the application? | Response: Refer to Attachment R-ESSAM_Business_Process_Analysis_Report, specifically 3.3 ESSAM Program Drivers and Section 3.4 - Imperatives - Client and Worker. | No |
| 30 | Page #: 26 | Sub Section: Project Management | RFP Language: NA | Question: Have you conducted any user surveys or gathered feedback to understand their pain points and preferences? | Response: While no user surveys were conducted, as part of the planning phase of ESSAM, the team did interview users and can provide problematic areas. DSS is also working on engaging an OCM vendor which is planned to start prior to the onboarding of resources for this contract. | No |
| 31 | Page #: 110 | Sub Section: Price Proposal | RFP Language: NA | Question: Could you provide details regarding the established budget parameters or allocated funding for the purpose of this modernization endeavor | Response: The State will not provide the ESSAM Budget information. Software Development Contractors are encouraged to offer their best price based on their proposed solution. | No |
| 32 | Page #: 115 | Sub Section: Section 5 | RFP Language: UNLESS YOU POSSESS THE FOLLOWING MANDATORY MINIMUM QUALIFICATIONS, DO NOT SUBMIT AN OFFER: |
Offeror must have successfully completed at least 1 large scale design, development, and implementation project for a system similar to the ESSAM System described in this RFP.
The project must meet all the following criteria:
1) Comparable in size and complexity to that specified herein, or larger;
2) System’s SNAP/TANF functionality has been fully operational in the 12 months prior to the RFP Proposal due date;
3) Have implemented with a “go live” date within the 60 months prior to the RFP Proposal due date.
4) Included SNAP and/or TANF eligibility determination.
5) For a state or local government health/human services agency.
6) Performed as the prime contractor. Question: Can DSS please confirm that the requirement for “large scale design, development, and implementation project” means a full SNAP/TANF eligibility replacement project (including eligibility, program integrity, and appeals and hearings) where the offer operated as the system’s implementor including fully performing design, development, and implementation services of the entire solution? Response: See the updated language for qualifications in Section 5 of the solicitation on page 116.
To answer the question, Software Development Contractor at a minimum should have implemented SNAP/TANF eligibility determination functionality. Yes Section 5 Qualifications - simplified the wording on the qualifications to three points.
QUALIFICATIONS - SPECIAL STANDARDS OF RESPONSIBILITY (MAR 2015)
The project must meet all the following criteria:
| 1) | Comparable in size and complexity to that specified herein, or larger; | |||
| 2) | System’s SNAP/TANF functionality has been fully operational in the 12 months prior to the RFP Proposal due date; SNAP/TANF system implementation, including eligibility determination, within the last 5 years and currently fully operational | |||
| 3) | Have implemented with a “go live” date within the 60 months prior to the RFP Proposal due date. | |||
| 4) | Included SNAP and/or TANF eligibility determination. | |||
| 5) | For a state or local government health/human services agency. | |||
| 6)3) | Performed as the prime contractor. | |||
| 33 | Page #: 115 | Sub Section: Section 5 | RFP Language: UNLESS YOU POSSESS THE FOLLOWING MANDATORY MINIMUM QUALIFICATIONS, DO NOT SUBMIT AN OFFER: |
Offeror must have successfully completed at least 1 large scale design, development, and implementation project for a system similar to the ESSAM System described in this RFP.
1) Comparable in size and complexity to that specified herein, or larger;
2) System’s SNAP/TANF functionality has been fully operational in the 12 months prior to the RFP Proposal due date;
3) Have implemented with a “go live” date within the 60 months prior to the RFP Proposal due date.
4) Included SNAP and/or TANF eligibility determination.
5) For a state or local government health/human services agency.
| 6) Performed as the prime contractor. | Question: Can DSS please confirm that the requirement for “large scale design, development, and implementation project” does not include an incremental legacy modernization project, but rather requires a full DDI replacement of the legacy system? | Response: Yes, a full System Development Lifecycle (Requirements, Design, Development & Implementation) of a SNAP/TANF Replacement as the Prime. See the updated language for qualifications in Section 5 of the solicitation on page 116. | No | ||||
| 34 | Page #: 110 | Sub Section: Section 3.3.1 | RFP Language: Offerors must provide a minimum of three (3) prior and existing state government references | Question: Can DSS please confirm that the references need to be for other full-scale DDI implementations of a SNAP/TANF eligibility system where the offeror performed as the prime contractor? | Response: The Software Development Contractor must have previously performed as the prime contractor on a similar SNAP/TANF project as the Design, Development and Implementation (DDI). See the updated language for qualifications in Section 5 of the solicitation on page 116. - "3) Performed as the prime contractor." | No | |
| 35 | Page #: 7 | Sub Section: Table 1 - ESSAM Project Phase; Attachment P, Cost Proposal Workbook | RFP Language: The DDI time frame is variable and is anticipated to be between 2-4 years depending on solution option selected during the Procurement Process. | Question: DSS has stated that the DDI timeframe may be between 2 and 4 years. However, Attachment P, Cost Proposal Workbook is structured in such a way that requires offerors to provide cost details for a full 12 year term (DDI + M&O). If an offeror is to propose a DDI of less than 4 years, can DSS provide additional instructions on how to complete Attachment P (specifically Tab 4. Appl M&O and Tab 5. Help Desk)? | Response: Phase 1, which is Design, Development, and Implementation(DDI), has variable length based on the Software Development Contractor's proposed DDI phase. Initially after the statewide rollout of system (which is the completion of DDI (day 1 of complete statewide solution being implemented), the warranty and Maintenance and Operations will occur for 2 years. After the first 2 years of Maintenance and Operations there will be 3 optional terms of 2 years each for a potential of 6 years. Cost proposals should include the costs for the DDI phase with appropriate proposed length followed by 8 years of M&O (2 years initial + 3 optional terms of 2 years). The only variability in duration is the time required to perform DDI. |
| Instructions on completion are contained in Attachment P, Cost Proposal Workbook. | No | ||||||
| 36 | Page #: 75 | Sub Section: Section 3.16.3.3 | RFP Language: Present the Pilot Implementation Plan to DSS and incorporate DSS feedback before finalization. | Question: FNS requires a 3 month pilot implementation, but the RFP does not mandate a 3 month production pilot. Can DSS please confirm that a minimum 3 month production pilot is required? | Response: SC DSS plans to execute live pilot operations for a minimum of three months. The exact length for pilot has not been determined, and the ESSAM Project will gather input from State, FNS and Software Development Contractor and other important stakeholders to determine exact Pilot length necessary. | No | |
| 37 | Page #: 72 | Sub Section: Section 3.14.6 | RFP Language: The Contractor must ensure the Conversion team (DSS & Contractor) clearly articulates and documents steps and processes used to convert data from the various legacy systems to the ESSAM System and identifies checks and balances to confirm data was appropriately converted. | Question: Can DSS provide an estimate of the current volume of the documents to be converted from SCOSA? | Response: The images to be converted should be associated to the cases that are from current\implementation date to 4 years old. This does not apply to data related to cases associated to a claim, all data and images associated to those cases will need to be migrated. |
| DSS has Active Images of 2,914,754 TIF files and archived images of 5,395,974 TIF files. Currently we have 8,310,728 image files, with a large majority of those images needing to be converted. The total size of DSS' images stored using the Hitachi Data Ingestor for SCOSA is close to 20TB (7TB for current active share, and 13TB for the archive share). Only a subset of these images based on the business rules above will be converted. See question #183 for anticipated case load conversion volume. | No | |||||
| 38 | Page #: N/A | Sub Section: Attachment A, T5.1.15 | RFP Language: The Portal Component will provide chat and instant messaging (IM) support. | Question: Does DSS have existing chatbot/live chat technology with which offerors should propose to integrate? Or, is DSS seeking for the offeror to price and include chatbot/live chat technology? If so, does DSS have any product preferences? | Response: DSS does not have existing ChatBot capabilities. DSS does not expect vendors to respond to the ESSAM RFP with a chat bot or instant messaging product included in the proposal. |
| In the future, DSS may implement Chat Bot Technology, and would like integration options with the new ESSAM Solution. If the proposed solution has existing or "built-in" functionality to integrate with a Chat Bot or Instant Messaging Product, please include the details in your response. | No | ||||||
| 39 | Page #: N/A | Sub Section: Attachment A, T1.34 | RFP Language: The System will include the telephony integration required to satisfy the ability to dial a phone number directly from data within the System based on user request, and provide the capability to automatically bring up the caller’s record upon the receipt of an incoming call. | Question: Does DSS have existing IVR technology with which offerors should propose to integrate?? Or, is DSS seeking for the offeror to price and include IVR technology? If so, does DSS have any product preferences? | Response: DSS official Call Center and IVR technology is AWS Connect, the Software Development Contractor will integrate with this platform. | No | |
| 40 | Page #: N/A | Sub Section: Attachment A, FR2.83-FR2.87 | RFP Language: FR2.83 - The System will present the account profile to an Eligibility Worker when they log in, which will include the list of required customizable training modules to complete based on role and tenure | Question: Does DSS have existing Learning Management System (LMS) technology with which the offeror should propose to integrate? Or, is DSS seeking for the offeror to price and include the LMS technology? If so, does DSS have any product preferences? | Response: SC-DSS does have an LMS solution provided by the SC Department of Administration and managed by the DSS Staff Development and Training Division in which LMS training modules for the new ESSAM system can be incorporated. | No | |
| 41 | Page #: N/A | Sub Section: Attachment A, T5.9.1 | RFP Language: The IAM component design will comply with U.S. Department of Health & Human Services and U.S. Department of Education privacy and data security requirements, including, but not limited to, the Health Insurance Portability and Accountability Act (HIPAA), the Family Educational Rights and Privacy Act (FERPA) and the Health Information Technology for Economic and Clinical Health (HITECH) Act provisions of the American Recovery and Reinvestment Act (Authorized Representative RA) of 2009. | Question: Is there an existing IAM solution that DSS is currently utilizing, implemented in Microsoft Azure Active Directory B2C & Enterprise? Or, is DSS expecting the offeror to implement a new IAM solution which should be integrated with the proposed SNAP/TANF solution for user provisioning, authentication, and authorization purposes? | Response: SC-DSS does not currently have a solution that leverages Azure Active Directory, but DSS plans to fully sync up the on premise identities with Azure Active directory using Azure AD Connect for Offerors' solutions to integrate with. | No | |
| 42 | Page #: N/A | Sub Section: Attachment A, T6.7-T6.11 | RFP Language: T6.7 – For Platform requirements, the State has a “Mandatory” requirement for the Vendor to propose one or more of the following technologies as part of their Solution Architecture – Windows Server | Question: These End User requirements list the following solution architecture components as Mandatory – Windows Server, VMWare, Active Directory and WinTel Servers. Please confirm if they are mandatory or preferred? Also, please confirm if this applies to end user machines (laptops, computers, etc.) or cloud hosted servers? | Response: These are DSS "Strongly Preferred". | No | |
| 43 | Page #: N/A | Sub Section: Attachment A, G4 – Interface List; Attachment D | RFP Language: N/A | Question: The RFP references interfaces in Attachment A and Attachment D. However, the two lists are not in sync. Please confirm if it is DSS’ intent for the superset of Attachment A and D to be required for ESSAM. Furthermore, the descriptions listed for some of the interfaces in Attachment A do not provide enough details to understand the intent of the interface (example – “in-house” and “Clemson”). Can DSS provide interface descriptions and additional details? |
Interfaces listed in Attachment D that are not present in Attachment A, G4 tab:
| • | SC Revenue and Fiscal Affairs Office (RFA) |
| • | SC Department of Education |
| • | SC DSS - Benefits Portal |
| • | SC DSS - SCOSA - SNAP/TANF Imaging |
| • | USDA / Electronic Disqualified Recipient System (eDRS) |
| • | SC-DSS - SC Comprehensive Employment and Training System (SCCETS) |
| • | SC State Election Commission |
| • | SC Public Employee Benefit Authority (PEBA) |
| • | US Census Bureau |
| • | Pondera (Fraud Analytics Vendor) |
List of interfaces that are in Attachment A, G4 and not in Attachment D:
| • | in-house | ||||
| • | WINS | ||||
| • | Child Care | ||||
| • | EPLN | ||||
| • | SEC | ||||
| • | RSA Research & Stats | ||||
| • | Clemson | ||||
| • | Dashboard | ||||
| • | IDEC | ||||
| • | CAPPS | Response: Attachment A - Requirements Definition Document (RDD) Tab G4 - Interface List updated to align with Attachment D - DSS List of Interfaces. Addition of 5 proposed interfaces to both documents. | Yes | Attachment A - Requirements Definition Document (RDD) Tab G4 - Interface List updated to align with Attachment D - DSS List of Interfaces. Addition of 5 proposed interfaces to both documents. | |
| 44 | Page #: N/A | Sub Section: Attachment A, G4 – Interface List; Attachment D | RFP Language: N/A | Question: From our experience implementing SNAP/TANF eligibility systems, we typically see some additional interfaces beyond those included in Attachment A and D. For consistency of vendor proposals, can DSS confirm or instruct if the following additional interfaces are required to be included? | |
| • | Public Assistance Reporting Information System (PARIS) | ||||
| • | National Accuracy Clearinghouse | ||||
| • | Systematic Alien Verification for Entitlements (SAVE) | ||||
| • | Social Security Administration (SSA) State On-Line Query Internet (SOLQ-I) | ||||
| • | The Work Number (TWN) | ||||
| • | Death Match | Response: Proposed interfaces added to Attachment A - Requirements Definition Document (RDD) Tab G4 - Interface List and Attachment D - DSS List of Interfaces. | Yes | Response: Proposed interfaces added to Attachment A - Requirements Definition Document (RDD) Tab G4 Req # G4.21 - Interface List and Attachment D - DSS List of Interfaces. |
Added verbiage in both Attachments clarifying that the SSA Interface performs the Death match - "and performs Death Match) 45 Page #: 79 Sub Section: Section 3.20.5.1.8 RFP Language: N/A Question: Is the offeror expected to provide the training facility including any hardware, software, other AV equipment to support training? Response: The Software Development Contractor (SDC) is responsible for the End User System Training which may be a combination of classroom and virtual. For proposal and estimation purposes, SDC should assume the training will be conducted onsite regionally (Pilot + 4 regions), with the SDC being responsible for securing the training locations and performing end user system training. Pilot training will be conducted onsite at DSS location in Columbia and does not need to be included in vendor training location costs. Training Equipment including laptops, projectors, screens and relevant training software and hardware(as necessary) will be provided and costs incurred by DSS.
DSS is in process of engaging an OCM Vendor that will aid the State in conducting the Business Process Training prior to the System Training. The OCM vendor will utilize the same training room and logistics as the Software Development Contractor. In planning for the training facilities costs, offeror should include an additional 1 month per rollout grouping (in addition to time needed for System Training) for initial setup and breakdown of training site, plus OCM training of the 1125 core business (total statewide).
| Regarding State Training Resources, the State has budgeted to have 1 Training Manager, and up to 6 training resources to perform the OCM training and review/approval of the System Training Approach, Plan and Documentation. | Yes | 3.20.5.1.8 - " Training locations (the Contractor must finalize the training locations in consultation with the DSS Training Team). Software Development Contractor (SDC) should assume the training will be conducted onsite regionally (Pilot + 4 regions), with the SDC being responsible for securing and the costs for the four training locations. Training locations will be regionally (Upstate, Pee Dee, Midlands and Low Country) in the metropolitan centers of South Carolina. Pilot training will be conducted onsite at DSS location in Columbia and does not need to be included in the vendor training location costs. In planning for the training facilities costs, SDC should include an additional 1 month per rollout grouping (in addition to time needed for SDC end user System Training) for initial setup and breakdown of training site, plus Organization Change Management (OCM) business process training of the 1125 core business (total statewide) prior to the SDC system training. Training Equipment including laptops, projectors, screens and relevant training software and hardware (as necessary) will be provided by DSS and DSS will incur training equipment costs." | ||||||
| 46 | Page #: N/A | Sub Section: Attachment A, G4 – Interface List | RFP Language: N/A | Question: The G4 tab does not include the fit/gap columns including ‘Vendor Response (L, T, D)’ column. How does DSS want the fit/gap analysis to be captured for each interface? | Response: Please refer to the updated Attachment A worksheet to include vendor response columns. | Yes | Attachment A Tab G4 - Interface List updated to include vendor response columns. | |
| 47 | Page #: N/A | Sub Section: Attachment A, All tabs | RFP Language: N/A | Question: The tabs in Attachment A include a column ‘Vendor Proposed Release Date’ with pre-populated dropdown values as 1 and 2. However, based on the instructions provided, a release date needs to be included. Please confirm and clarify how should the proposed release date be provided? | Response: Please refer to the updated Attachment A worksheet. | Yes | Attachment A Worksheet updated to remove Data Validation on the affected columns | |
| 48 | Page #: N/A | Sub Section: Attachment A, Respondent Instructions tab | RFP Language: | Question: If a vendor is proposing a single functional release to production, does DSS have a preferred approach that would help respond to this column? Additionally, if a date is required, should the vendor leverage 6/17/2024 as the project start date as provided in the RFP? | Response: The State wants to know when a requirement will be met within the SDLC. All Requirements must be accomplished prior to completion of the System Integration Test (SIT) phase of the project. If the Bidder has a reason why preferred requirements should be deferred post SIT, please add explanation in comments. If functionality must be developed, Offerors should include the anticipated date the functionality development will be completed and tested, based on a contract start date of 6/17/24. | No | ||
| 49 | Page #: 105 | Sub Section: Section 2, 2.1 | RFP Language: Offerors should acknowledge and confirm their understanding of information listed in Section Error! Reference source not found., Item Error! Reference source not found. Current Business Environment and Item Error! Reference source not found. Current Technical Environment. | Question: Section 3.5.5.10 is regarding current SC application volumes and not ‘Current Technical Environment’. Please confirm the section reference is supposed to be 3.5.6 (Current Technical Environment) and related sections that follow. | Response: Cross-reference at section 4.2.1 updated to point to 3.5.6 Current Technical Environment. | Yes | Cross-reference at 4.2.1 (3.5.5.10) needs to be updated to point to 3.5.6 Current Technical Environment. (Page 104 of 141) | |
| 50 | Page #: 63; 72 | Sub Section: Section 3.9.2; 3.14.17 | RFP Language: 3.9.2. The Contractor must develop and maintain detailed specifications for all necessary hardware, software, and tools requested/required to support the functionality on the DSS ESSAM Solution (aligned with DSS' standard policies and procedures) for the seven (7) environments listed below for the duration of the Project. The seven (7) environments include: |
• Production
• Pre-Production/Staging
• User Acceptance Testing
• Training
• System Integration Testing
• Development
• Disaster Recovery
3.14.17. The Contractor must, as part of the Data Conversion Plan, outline a process for reconciling converted data including written procedures, methods, and checklists for balancing and reconciling conversion of data between the legacy systems and the new ESSAM environment. Question: Requirements under Section 3.14. DATA CONVERSION AND MIGRATION refer to a Conversion environment, however Section 3.9 TECHNICAL ENVIRONMENT SETUP AND MANAGEMENT does not include a conversion environment. Please confirm if the offerors should include Conversion as an additional environment in addition to the environments listed in Section 3.9.2? Response: Please refer to the updated section 3.9.2 to have a Conversion Environment. Yes Update made to the environments to add Conversion
| 3.9.2. | The Contractor must develop and maintain detailed specifications for all necessary hardware, software, and tools requested/required to support the functionality on the DSS ESSAM Solution (aligned with DSS' standard policies and procedures) for the seven (7) environments listed below for the duration of the Project. These seven (7) environments include: | |||||||
| • | Production | |||||||
| • | Pre-Production/Staging | |||||||
| • | User Acceptance Testing | |||||||
| • | Training | |||||||
| • | System Integration Testing | |||||||
| • | Development | |||||||
| • | Disaster Recovery | |||||||
| • | Conversion | |||||||
| • | Sandbox (As Needed for FNS) | |||||||
| 51 | Page #: 105 | Sub Section: Section 4. | RFP Language: You should submit a summary of all insurance policies you have or plan to acquire to comply with the insurance requirements stated herein, if any, including policy types; coverage types; limits, sub-limits, and deductibles for each policy and coverage type; the carrier's A.M. Best rating; and whether the policy is written on an occurrence or claims-made basis. [04-4010-2] | Question: The response outline as prescribed in Section 4 (page 105) does not explicitly call out where to include the summary of all insurance policies. Does DSS have a specific section where they would like to see this information included in the offeror’s response? | Response: No, DSS does not have a specific section for the summary of insurance policies. It can be submitted as an attachment to your technical proposal or with your responses to Section 5 QUALIFICATIONS. | No | ||
| 52 | Page #: 113 | Sub Section: Section 4. | RFP Language: In addition to information requested elsewhere in this solicitation, the Price Proposal must be clearly identified and must include a copy of Page 1 of this solicitation. | Question: ATTACHMENT P – Cost Proposal Workbook is an Excel file; however, a signed page 1 of the solicitation will be a PDF submission. Will DSS clarify if the Price Proposal should be submitted as two files to consist of an Excel file and a PDF, or if vendors should submit a single PDF including Attachment P and Page 1 of the solicitation? | Response: Offerors must submit a completed copy of Attachment P as an Excel or PDF but regardless of format, the Cost Proposal must be submitted as a separate file from the technical proposal response. That is, there must be no cost information in the technical proposal. A signed copy of page 1 may be submitted as a separate file or as part of the technical proposal. | No | ||
| 53 | Page #: 114 | Sub Section: Section 4. | RFP Language: OFFSHORE CONTRACTING (JAN 2006) | Question: Section 4. INFORMATION FOR OFFERORS TO SUBMIT includes the expected response section outline that DSS desires from all Offerors. There is an Offshore Contracting form included on page # 114 without reference to the section where this form should be included. Can DSS clarify where in the response they would like to include the completed Offshore Contracting (Jan 2006) form? | Response: Offshore Contracting will be included in the Technical Proposal. Refer to Attachment O section 1 - #6 - Offshore Contracting clause for details. | Yes | Updated Attachment O Section 1 - #6 - "Offshore Contracting clause | |
| 54 | Page #: N/A | Sub Section: N/A | RFP Language: N/A | Question: Will a call recording be made available? | Response: No, a recording of the pre-proposal meeting is not available. | No | ||
| 55 | Page #: 11 | Sub Section: 2 | RFP Language: (c) If Offeror is unable to certify the representations stated in paragraphs (a)(1), Offer must submit a written explanation regarding its inability to make the certification. The certification will be considered in connection with a review of the Offeror's responsibility. Failure of the Offeror to furnish additional information as requested by the Procurement Officer may render the Offeror nonresponsible. | Question: would the offeror be nonresponsible or non-responsive? In this case, is failure to furnish additional information as requested cause for offeror disqualification? | Response: As stated in the clause, failure to furnish additional information may render the Offeror non-responsible. The State may only enter into contracts with offerors who are deemed responsible. | No |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .