RFP Document.pdf

STATE OF SOUTH DAKOTA

DEPARTMENT OF EDUCATION

800 GOVERNORS DRIVE

PIERRE, SOUTH DAKOTA 57501-2235

Perkins Data and Application System

PROPOSALS DEADLINE: by August 9, 2024 5:00 PM CT

RFP #: 24RFP10864 Buyer: Rochelle Kenzy Phone: (605) 773-8063

REQUEST FOR PROPOSAL FORM

FIRM NAME: AUTHORIZED SIGNATURE:

ADDRESS: TYPE OR PRINT NAME:

CITY/STATE: TELEPHONE NO:

ZIP (9 DIGIT): FAX NO:

FEDERAL TAX ID#: E-MAIL:

PRIMARY CONTACT INFORMATION

CONTACT NAME: TELEPHONE NO:

FAX NO: E-MAIL:

1. General Information

1.1 Purpose of this Request for Proposal (“RFP”)

The South Dakota Department of Education’s Division of (“State”) seeks a qualified vendor to provide professional services on behalf of the State of South Dakota (“Consultant”) for the purpose of as further specified in Section 2 below.

The Consultant will review all requirements of the RFP and provide a proposal by the deadline listed below. The Consultant will also provide supporting documentation on qualifications and experience to the State.

1.2 Schedule of Activities

RFP Publication July 8, 2024

Deadline for Submission of Written Inquiries July 17, 2024 by 5:00 PM CT

Responses to Consultant Questions ,July 26, 2024

Proposal Submission Deadline August 9 , 2024 5:00 PM CT

Anticipated Award /Contract Negotiation / Technology Review August 2024

Contract Start Date September 1, 2024

1.3 Proposal Submission

All proposals must be completed and received by the date and time indicated in the Schedule of Activities.

Proposals received after the deadline will be late and ineligible for consideration.

An original of the proposal shall be submitted. In addition, the Consultant shall provide one (1) copy of their entire proposal, including all attachments, in Microsoft Word or PDF electronic format.

Consultants shall enclose the electronic copy with their mailed response and may not send the electronically copy of their proposal via email.

All proposals must be signed, in ink, by an officer of the responder, legally authorized to bind the responder to the proposal, and sealed in the form intended by the respondent. Proposals that are not properly signed may be rejected. The sealed envelope must be marked with the appropriate RFP Number and Title. The words “Sealed Proposal Enclosed” must be prominently denoted on the outside of the shipping container. Proposals must be addressed and labeled as follows:

REQUEST FOR PROPOSAL #24RFP10864

BUYER ROCHELLE KENZY

DEPARTMENT OF EDUCATION

800 GOVERNORS DRIVE

PIERRE SD 57501-2235

Proposals may be modified or withdrawn by the Consultant prior to the established due date and time. No oral, telephonic, telegraphic or facsimile responses or modifications to proposals will be considered.

1.4 Certification and Qualification

By signing and submitting this proposal, the Consultant certifies that neither it nor its principals are presently debarred, suspended, proposed for debarment, declared ineligible, or voluntarily excluded from participation, by any Federal department or agency, from transactions involving the use of Federal funds. Where the Consultant is unable to certify to any of the statements in this certification, the Consultant shall attach an explanation to their proposal.

No proposal shall be accepted from, or no contract or purchase order shall be awarded to, any person, firm or corporation that is in arrears upon any obligations to the State of South Dakota, or that otherwise may be deemed irresponsible or unreliable by the State.

1.5 Non-Discrimination Statement

The State of South Dakota requires that all contractors, vendors, and suppliers doing business with any State, department, or institution, provide a statement of non-discrimination. By signing and submitting their proposal, the Consultant certifies they do not discriminate in their employment practices with regard to race, color, creed, religion, age, sex, ancestry, national origin or disability.

1.6 Consultant Inquiries

Consultants may make email inquiries concerning this RFP to obtain clarification of requirements.

No inquiries will be accepted after the date and time indicated in the Schedule of Activities. Inquiries must be sent to Rochelle Kenzy at Rochelle.Kenzy@state.sd.us with the subject line “RFP

#24RFP10864 ”.

The State will respond to Consultant’s inquiries (if required) via e-mail. All Consultants will be informed of any inquiries and the State’s response. Consultants may not rely on any other statements, either of a written or oral nature, that alter any specification or other term or condition of this RFP. Consultants will be notified in the same manner as indicated above regarding any modifications to this RFP.

Consultant’s Contacts: Consultant and their agents must direct all questions and comments regarding this RFP to the buyer of record as indicated above. Consultants and their agents may not contact any State of South Dakota employee other than the buyer of record regarding any of these matters during the solicitation and evaluation process. Inappropriate contacts are grounds for suspension or exclusion from specific procurements. Consultants and their agents who have questions regarding this matter should contact the buyer of record.

1.7 Proprietary Information

The proposal of the successful Consultant(s) becomes public information as required by SDCL § 1-27 and § 5-18D-20. Proprietary information can be protected under limited circumstances such as client lists and non-public financial statements. Pricing and service elements are not considered proprietary. An entire proposal may not be marked as proprietary. Consultants must clearly identify in the Executive Summary and mark in the body of the proposal any specific proprietary information they are requesting to be protected. The Executive Summary must contain specific justification explaining why the information is to be protected. Proposals may be reviewed and evaluated by any person at the discretion of the State. All materials submitted become the property of the State and may be returned only at the State's option.

1.8 Length of Contract

September 1, 2024 - June 30, 2026

The State reserves the right to extend any contract awarded as a result of this Request for Proposal (RFP) for additional six (6) years if it is deemed to be in the best interest of the State of South Dakota.

The contract may be renewed at the initiative of the State, and if mutually agreed upon by the parties, for additional one (1) year terms.

1.9 Contract Terms

Any contract or agreement resulting from this RFP will include the State’s standard terms and conditions as set forth in Exhibit A – Standard Contract Terms and Conditions. Any contract or agreement resulting from this RFP will include the State’s standard terms and conditions as set forth in Exhibit A – Standard Contract Terms and Conditions, Exhibit E_BIT IT Contract Terms, Exhibit F – Information Technology Security Policy, and Exhibit G Security Acknowledgment Form, along with any additional contract terms as negotiated by the parties.

1.10 Governing Law

Venue for any and all legal action regarding or arising out of the transaction covered herein shall be solely in the Sixth Judicial Circuit, Hughes County, South Dakota. The laws of South Dakota shall govern this transaction.

1.11 Web Content Accessibility Guideline

If applicable the Consultant’s application is required to conform to the Web Content Accessibility Guidelines 2.0

1.12 Restriction of Boycott of Israel

For contractors, vendors, suppliers, or subcontractors with five (5) or more employees who enter into a contract with the State of South Dakota that involves the expenditure of one hundred thousand dollars ($100,000) or more, by submitting a response to this solicitation or agreeing to contract with the State, the bidder or offeror certifies and agrees that the following information is correct:

The bidder or offeror, in preparing its response or offer or in considering proposals submitted from qualified, potential vendors, suppliers, and subcontractors, or in the solicitation, selection, or commercial treatment of any vendor, supplier, or subcontractor, has not refused to transact business activities, has not terminated business activities, and has not taken other similar actions intended to limit its commercial relations, related to the subject matter of the bid or offer, with a person or entity on the basis of Israeli national origin, or residence or incorporation in Israel or its territories, with the specific intent to accomplish a boycott or divestment of Israel in a discriminatory manner. It is understood and agreed that, if this certification is false, such false certification will constitute grounds for the State to reject the bid or response submitted by the bidder or offeror on this project and terminate any contract awarded based on the bid or response. The successful bidder or offeror further agrees to provide immediate written notice to the contracting executive branch agency if during the term of the contract it no longer complies with this certification and agrees such noncompliance may be grounds for contract termination.

1.13 Restriction of Prohibited Entity

In accordance with the South Dakota Codified Law 5-18A, any bidder or offeror submitting a bid or offer in response to this document certifies and agrees that the following information is correct:

The bidder or offeror is not an organization, association, corporation, partnership, joint venture, limited partnership, limited liability partnership, limited liability company, or other entity or business association, including all wholly-owned subsidiaries, majority-owned subsidiaries, parent companies, or affiliates, of those entities or business associations, regardless of their principal place of business, which is ultimately owned or controlled, directly or indirectly, by a foreign parent entity from, or the government of, the People’s Republic of China, the Republic of Cuba, the Islamic Republic of Iran, the Democratic People’s Republic of Korea, the Russian Federation, or the Bolivarian Republic of Venezuela It is understood and agreed that, if this certification is false, such false certification will constitute grounds for the purchasing agency to reject the bid or response submitted by the bidder or offeror on this project and terminate any contract awarded based on the bid or response, and further would be cause to suspend and debar a business under SDCL § 5-18D-12.

The successful bidder or offeror further agrees to provide immediate written notice to the purchasing agency if during the term of the contract it no longer complies with this certification and agrees such noncompliance may be grounds for contract termination and would be cause to suspend and debar a business under SDCL § 5-18D-12.

1.14 Prohibition on Discrimination against Firearm-related Entity

In accordance with the State of South Dakota, Office of the Governor, Executive Order 2023-04, the following applies to any type of agreement by or on behalf of the State with a financial institution to provide financial services that involves the expenditure of one hundred thousand dollars ($100,000) or more:

For contractors who enter into a contract with the State of South Dakota that involves the expenditure of one hundred thousand dollars ($100,000) or more, by submitting a response to this solicitation or agreeing to contract with the State, the bidder or offeror certifies and agrees that the following information is correct:

The bidder or offeror, in preparing its response or offer or in considering proposals submitted from qualified, potential vendors, suppliers, and subcontractors, or in the solicitation, selection, or commercial treatment of any vendor, supplier, or subcontractor, has not discriminated against a firearm-related entity as defined by South Dakota Executive Order 2023-04. It is understood and agreed that, if this certification is false, such false certification will constitute grounds for the State to reject the bid or response submitted by the bidder or offeror on this project and terminate any contract awarded based on the bid or response. The bidder or offeror further agrees that falsely submitting this certification shall serve as cause for debarment from consideration of any state contract for a period not to exceed three years.

The successful bidder or offeror further agrees to provide immediate written notice to the contracting executive branch agency if during the term of the contract it no longer complies with this certification and agrees such noncompliance will result in the contract’s termination if the noncompliance is not cured as provided for in Section 3 of Executive Order 2023-04. The successful bidder or offeror further agrees that its failure to cure any subsequently arising noncompliance shall serve as cause for suspension or debarment from consideration of any state contract pursuant to

SDCL § 5-18D-12.

1.15 Certification of No State Legislator Interest

Offeror (i) understands neither a state legislator nor a business in which a state legislator has an ownership interest may be directly or indirectly interested in any contract with the State that was authorized by any law passed during the term for which that legislator was elected, or within one year thereafter, and (ii) has read South Dakota Constitution Article 3, Section 12 and has had the opportunity to seek independent legal advice on the applicability of that provision to any Agreement entered into as a result of this RFP. By signing an Agreement pursuant to this RFP, Offeror hereby certifies that the Agreement is not made in violation of the South Dakota Constitution Article 3, Section 12.

2. Scope of Work

The Consultant shall:

2.1 System Administration

2.1.1 The Consultant will provide an online data collection and program application system

(the “Perkins Hub”) to meet the State’s requirements for implementation of the requirements under the Strengthening Career and Technical Education for the 21st Century Act, or Perkins V.

2.1.2 Infrastructure/Technical Quality

2.1.1.1 Provide program and data irrespective of operating system (Windows, iOS, etc.), browser software (Internet Explorer, Safari, Firefox, Chrome, etc.), or device (PC, Mac, iPad, Phone, etc.).

2.1.3 Functionality

2.1.3.1 Overall System Requirements: The system must be Americans with Disabilities Act (ADA) and Section 508 compliant.

2.1.3.2 The system must work within the state’s longitudinal data system (SLDS, or SD- STARS), the state’s student information system (Infinite Campus), the teacher certification system, and the accountability report card. Additionally, the system must work together with the state’s SLDS expansion into a P-20.

2.1.3.3 Must also be able to ingest data from provided for the postsecondary CIP (Classification of Instructional Programs) Code Nontraditional file and map to CIP Codes provided by institutions.

2.1.3.4 The system must be configurable by state program staff to adjust courses within a career cluster, career clusters themselves, and other program requirements that may arise.

2.1.4 Account Levels

2.1.4.1 The system must include different user roles of access for the State, administrators, educators, and postsecondary data staff. Each user must have access to appropriate functions and features based on the user’s role.

2.1.1.2 The system must allow reporting at each level of access.

2.1.5 Training

2.1.5.1 The Consultant’s solution must include a complete user training guide for every level of user and documentation of all steps that built the system.

2.1.5.2 This system must provide resources to meet the requirements under South Dakota’s state Perkins V plan, including the following specifications:

2.2 Secondary Data System. The system must be able to collect from the state’s Student Information Management System (SIMS), Infinite Campus, student transcript information to pull students having taken an approved Career and Technical Education (CTE) course. The data collection system must include a mechanism for determining which courses at which districts meet the threshold for approval, as defined by the State, and in coordination with the state’s current K-12 data systems. The following components must be included:

2.2.1 Secondary Data Collection

2.2.1.1 Ability to accommodate both ingesting data from the SIMS and work within the state’s longitudinal data system (SD-STARS),

2.2.1.2 A mechanism for ingesting district reported data for required data not contained within the SIMS or SD-STARS. The current element requiring this option includes secondary post-program placement and data from districts which do not utilize Infinite Campus District Edition.

2.2.1.3 Ability to accommodate ingesting data from the PRF system as well as a mechanism to accept approved CTE programs and their related instructors for data collection.

2.2.1.3 Ability for districts to validate their data, once ingested and complete.

2.2.1.4 Ability to connect the Secondary Data Collection system with the Secondary

Program application system so that data tables may be shared amongst the system.

2.2.1.5 Ability for State staff to assign roles and credentials as applicable to state and district staff.

2.2.1.6 Ability to easily edit data tables related to Career Clusters, Course Information, Industry Recognized Credentials and related information which may change from year to year, while preserving historical data.

2.2.1.7 Ability to create recurring data years based on the state’s Educational Structures, including the ability to roll forward data tables while preserving historical information.

2.2.1.8 Ability to accommodate data for districts utilizing Approved Course Providers

2.2.1.9 Ability to freeze each year’s data collection irrespective of future years’ changes.

2.2.1.10 Built in a manner for the state to be able to adjust parameters within the system as federal requirements and the state’s implementation of those requirements changes. Those could include which courses fall into which clusters, what courses add up to a concentrator, what the names of the clusters and courses are, etc.

2.2.2 Secondary Data Calculations. The system must be able to accurately and replicate repeatedly calculate the below indicators as they pertain to CTE student concentrators, at the levels of district, consortium, college, and state, within the definitions (numerator and denominator) as provided by the state:

2.2.2.1 Distinguish between students having taken a CTE course during the relevant academic year and students who have taken a set series of courses over the course of their academic career, within the parameters defined by the state.

2.2.2.2 1S1: Four-year graduation rate: as calculated by the state’s ESSA accountability system

2.2.2.3 2S1: Academic Proficiency in Reading/Language Arts: as calculated by the state’s ESSA accountability system

2.2.2.4 2S2: Academic Proficiency in Mathematics: as calculated by the state’s ESSA accountability system

2.2.2.5 2S3: Academic Proficiency in Science: as calculated by the state’s ESSA accountability system

2.2.2.6 3S1: Post-Program Placement: through a combination of district-reported data and possibly National Student Clearinghouse data

2.2.2.7 4S1: Non-traditional Program Concentration: calculated based on the state-provided list of clusters and pathways in which one gender is a minority in the workforce

2.2.2.8 5S3: Program Quality – Participated in Work-Based Learning: pulled from student transcript data in the SIMS

2.2.2.9 Secondary CTE participants: determined based on coursework data pulled from approved programs criteria and student transcripts

2.2.2.10 Secondary CTE concentrators: determined based on coursework data pulled from approved programs criteria and student transcripts over a student’s high school career

2.2.2.11 Any other CTE measure as required by federal law and the state’s CTE plan.

2.2.2.12 Integration within the Accountability Report Card. At the secondary level, the calculation of indicators must feed into the existing private and public Accountability Report Card.

2.2.3 Secondary Reporting Mechanisms.

2.2.3.1 District Data Collection Status Report

2.2.3.2 Placement Status Report

2.2.3.3 Student Summary Report

2.2.3.3 Courses Student Summary Report

2.2.3.4 Earned Industry Recognized Credential Student Summary Report

2.2.3.5 The data collected and calculations must be displayed within user-friendly reports accessible to state staff for both display and validation, and as required, by school personnel. Reports must be downloadable in excel and compatible with printing where applicable.

2.3 Postsecondary Data System. The system must be able to either ingest or receive an upload from the state’s postsecondary technical colleges that participate in approved CTE. If the system is built to ingest data, the data collection system must include a mechanism for determining which programs meet the threshold for approval, as defined by the State, and in coordination with the postsecondary data systems.

2.3.1 Postsecondary Data Collection

2.3.1.1 Ability to crosswalk ingested data with internally provided data. Current example: Non-Traditional Crosswalk CIP code file

2.3.1.2 The postsecondary secondary data collection system must be able to distinguish between students having taken a CTE course during the relevant academic year and students who have taken a set series of courses over the course of their academic career, within the parameters defined by the state.

2.3.1.3 The system must be built in a manner for the state to be able to adjust parameters within the system as federal requirements and the state’s implementation of those requirements changes.

2.3.2 Calculation and Aggregation of Postsecondary Indicators. The system must be able to accurately and replicate repeatedly calculate and aggregate the below indicators as they pertain to CTE student concentrators, at the levels of district, consortium, college, and state, within the definitions (numerator and denominator) as provided by the state:

2.3.2.1 1P1: Postsecondary Placement: currently provided by postsecondary colleges, but possibly with the ability to pull from labor and National Student Clearinghouse data sources

2.3.2.2 2P1: Earned Recognized Postsecondary Credential: as reported by postsecondary colleges

2.3.2.3 3P1: Non-traditional Program Concentration: calculated based on the state-provided list of clusters and pathways in which one gender is a minority in the workforce

2.3.2.4 Postsecondary CTE participants: currently reported by colleges, but with the potential for a direct pull from postsecondary systems

2.3.2.5 Postsecondary CTE concentrators: currently reported by colleges, but with the potential for a direct pull from postsecondary systems

2.3.2.6 Any other CTE measure as required by federal law and the state’s CTE plan.

2.3.3 Postsecondary Reporting Mechanisms

2.3.3.1 PS Student Summary Report

2.3.3.2 PS Participant Aggregated Report

2.3.3.3 PS Concentrator Aggregated Report

2.3.3.4 PS Placement Aggregated Report

2.3.3.5 PS Earned Recognized Post-Secondary Credential Report

2.3.3.6 PS Non-Traditional Program Concentration Aggregated Report

2.3.3.7 The data collected and calculations must be displayed within user-friendly reports accessible to state staff for both display and validation, and as required, by school personnel. Reports must be downloadable in excel and compatible with printing where applicable.

2.4 Secondary Program Approval Application or Portal. Within the system and connected to the data collection system.

2.4.1 Development of a Program Application workflow which integrates information from the Secondary Data Collection System, the PRF system, district provided information and data tables. Data tables must be able to be copied or rolled forward from year to year while also able to be edited due to CTE program changes per school year.

2.4.1.1 Ability to connect with the teacher certification and/or PRF system to validate teacher certification for CTE program eligibility.

2.4.1.2 Ability for districts to enter teacher information manually in cases where teacher is under contract but not yet in the PRF system.

2.4.1.3 Ability to create automated email correspondence between the system and district Perkins contacts. Ex: Requesting completion of the program application, confirmation of submission, program approval notification, reminder emails, etc.

2.4.1.4 Ability to assign roles and credentials to applicable individuals to complete the program application at the district and for CTE staff to review assigned program applications.

2.4.1.5 Ability to populate eligible course offerings, industry credentials and Career and Technical Student Organizations per Career Cluster

2.4.1.6 Ability to identify programs utilizing Approved Course Providers (i.e.- multi-districts, partner districts and virtual providers)

2.4.1.7 Ability for the system to calculate program eligibility for CTE staff approval with varying approval options.

2.4.1.8 Ability for the system to allow CTE staff to approve program status;

generate automated emails and automated workflow communications.

2.4.1.9 Ability for program applications to be edited during set times of the year.

2.4.1.10 Ability for program applications to be approved, conditionally approved or denied for program approval.

2.4.1.11 Ability to edit the program application questions/elements by CTE staff.

2.4.1.12 Ability to attach and archive Perkins required documentation per federal requirements. Ex: Program Improvement Plans, Comprehensive Local Needs Assessment (CLNA) Documents, Local Plan and Action Plan Documents

2.4.1.13 Ability to assign tasks to districts or consortia such as completion of CLNA, Program Improvement Plans, etc.

2.4.1.14 Ability to assign the role of Perkins Coordinator or similarly titled position to the applicable individual per district

2.4.2 Secondary Program Approval Reporting Mechanisms:

2.4.2.1 Career Cluster Programs Approval Status (Cluster, District, Entity and

State Views) including status of Perkins eligibility

2.4.2.2 Year to Year Program Change Report (identifying programs dropped, added or simply not applied for compared to prior year(s))

2.4.2.3 Use of Approved Course Providers Report (listing district, cluster and courses being utilized by districts to build their programs.

2.4.2.4 Teacher Status Report (ability to identify teachers which are: new, on a Plan of Intent, and by Career Cluster including their name and email)

2.4.2.5 Program Application Completion Report (identifying the status of each district’s program application, including if the application has been started, is in completed, completed, sent back for revisions, etc.)

2.5 System Development Reports. The following requirements are expected of all reports listed within this document.

2.5.1 Levels of Reporting.

2.5.1.1 Provide capability to drill-down to the levels of performance indicator, attendance center, district, consortium, college, state, career cluster, demographic group, and/or special population as applicable, for all reports.

2.5.1.2 Aggregated and non-aggregated performance across all postsecondary Perkins performance indicators including demographic and sub-group categories with the ability to drill-down to all levels.

2.5.1.3 Cluster-specific counts of postsecondary concentrators and participants including demographic and sub-group categories.

2.5.1.4 Report identifying districts and/or entities which did not satisfactorily meet Perkins performance expectations.

2.5.1.5 Non aggregated reports of student across all secondary Perkins performance indicators including demographic and sub-group categories with the ability to drill-down to all levels from student, Cluster, district, consortium and state levels.

2.5.1.6 All other reports as previously listed under this scope of work.

2.5.2 Provide for the export of reports to external files (e.g. open exported data in Microsoft™ Excel)

2.5.3 Allow the State to identify consortia, multi-districts, one or more school districts and pull reports based on one, some or all.

2.5.4 Ability for users to access, view and download reports as applicable to their role including district Perkins directors, consortium directors, postsecondary Perkins contacts, state CTE staff and DOE CTE leadership.

2.6 Hosting and Data Access Requirements

The contract doubles as an agreement for the State to own the data tables and is able to manipulate data, run reports as needed, pull code tables, access raw data, and develop dashboards as needed through Microsoft Power BI, ESRI, Tableau and associated platforms.

The Offeror shall describe the process by which the State can access data housed within the proposed solution for ingestion into a state data repository, encompassing available methodologies (e.g., flat file, API), data formatting, frequency of updates, and any inherent constraints. Additionally, provide a high-level architecture diagram, as part of the Solution Diagram, elucidating the proposed solution’s data provision mechanism.

2.7 Single Sign-On Requirements

As part of the State’s Identity and Access Management (IAM) strategy, the proposed solution will need to integrate with the State of South Dakota’s standard identity management service single sign-on (SSO) which enables custom control of how citizens and state employees sign up, sign in, and manage their profiles.

The SSO supports the industry standard OAuth 2.0 protocol. This identity management will handle password recovery and multi-factor authentication (MFA). MFA is required for all application Administrators and may be required for other users. Microsoft’s official documentation on the identity provider the State has implemented can be found at: 1) https://learn.microsoft.com/en-us/azure/active-directory-b2c/ and https://learn.microsoft.com/en-us/azure/active-directory-b2c/integrate-with-app-code-samples for public/citizens (Azure B2C), 2) https://learn.microsoft.com/en-us/azure/active-directory/architecture/auth-oauth2 and https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-protocols-oidc for state employees, businesses, partners, and providers.

(EntraID, formally Azure Active Directory).

If the offeror is not able to fulfill this identity management standard, they will be excluded from the list.

2.8 Onboarding/Provisioning Users

The offeror must describe how new users are onboarded/provisioned in the system using an external identity provider and provide an Identity/SSO/Login Design Document.

2.9 Interfaces and Integration

The offeror must describe how the system can adapt to business necessary interfaces using widely adopted open APIs and standards. Additionally, the State expects that the offeror will make available/expose software services and publish documentation for those software services that would enable third party developers to interface other business applications. A detailed description of system capability must be included in the proposal.

2.10 Solution Diagram

The offeror must provide a solution diagram providing specific details of how the entire solution will meet the requirements of the RFP. This will include integration with the State’s infrastructure, existing systems that will integrate with the proposed solution, how data would flow between systems, the technology stack of the solution including any dependencies, and include, but not be limited to, user onboarding/provision and SSO.

2.11 Project Deliverables/Approach/Methodology

If the State will be hosting the solution the offeror will provide a system diagram. The diagram must be detailed enough that the State can understand the components, the system flow, and system requirements. It is preferred that the diagram be provided as a separate document or attachment. The file must be named “(Your Name) System Diagram and Requirements”. If the offeror elects to make the diagram part of the proposal, then the location of the diagram must be clearly indicated in the Table of Contents.

If the offeror is hosting the solution, provide a diagram giving an overview of the proposed system. It is preferred that this diagram be provided as a separate document or attachment.

The file must be named “(Your Name) Hosted System Diagram”. If the offeror elects to make the diagram part of the proposal, then the location of the diagram must be clearly indicated in the Table of Contents.

The offeror should state whether its proposed solution will operate in a virtualized environment. The offeror also should identify and describe all differences, restrictions or limitations of its proposed solution with respect to operation, licensing, support, certification, warranties, and any other details that may impact its proposed solution when hosted in a virtualized environment. This information must be included with the solution diagram for the offeror hosted solution.

This section identifies tasks and deliverables of the project as described in Section 3 above. The selected offeror is responsible for providing the required deliverables. These deliverables will be the basis against which the offeror’s performance will be evaluated.

The offeror is required to include a test system for its application. This test system will be used at the discretion of BIT. All resource costs associated with keeping the test system available must be borne by the project owner or the offeror. Any licensing costs for the test system must be included with the costs.

At BIT’s discretion, any code changes made by the offeror, either during this project or thereafter, will be placed in the above test system first. It is at BIT’s discretion if the code changes are applied by BIT or the offeror. If the code testing delays a project’s timeline, a change management process should be followed, and the State will not be charged for this project change. If the test and production systems are to be hosted by the State, the schedule for the testing of the code changes is to be decided by BIT. Testing of emergency code changes will be scheduled by BIT based on the severity and resource availability.

The test system will be maintained by the offeror as a mirror image of the production system code base. At BIT’s discretion, updates to the production system will be made by copying code from the test system after the test system passes BIT certification requirements.

If BIT determines that the application must be shut down on the production system, for any reason, the offeror will, unless approved otherwise by BIT, diagnosis the problem on and make all fixes on the test system. The offeror is expected to provide proof, to BIT, of the actions taken to remediate the problem that led to the application being denied access to the production system before the application can go back into production. This proof can be required by BIT even if the fix passes all BIT certification criteria. BIT is willing to sign a non-disclosure agreement with the offeror if the offeror feels that revealing the fix will put the offeror’s intellectual property at risk.

All solutions acquired by the State that are hosted by the offeror, including Software as a Service, or hosted by a third-party for the offeror will be subjected to security scans by BIT or preapproved detailed security scan report provided by the offeror. The scan report sent in with the proposal can be redacted by the offeror. The State’s goal at this point is to see if the contents of the report will be acceptable, not to review the contents themselves. If the offeror will be providing a security scan report, one must be sent with the proposal for approval. Approval is not guaranteed. If the scan report is not acceptable, the State must scan the offeror’s solution.

The actual scanning by the State or the submission of a security scan report will be done if the proposal is considered for further review. A detailed security report must consist of at least:

2.11.1 The system that was evaluated (URL if possible, but mask it if needed).

2.11.2 The categories that were evaluated (example: SQL injection, cross site scripting, etc.)

2.11.3 What were the general findings, (meaning how many SQL injection issues were found, what was the count per category)

2.11.4 Technical detail of each issue found. (where was it found – web address, what was found, the http response if possible)

2.11.5 The cost of any scans done by the offeror or the offeror’s costs associated with the State’s scans must be part of the offeror’s bid. If the offeror is sending a security scan report, it should price the product both as if the State was to do the security scan or if the offeror was to do the security scan.

2.11.6 All hardware, website(s), or software purchased by the State and hosted by the State will be subjected to security scans by BIT.

2.11.7 Security scanning will be performed during the software development phase and during pre-production review. These scans and tests can be time consuming and should be allowed for in project planning documents and schedules. Products that do not meet BIT’s security and performance requirements will not be allowed to go into production and may be barred from UAT until all issues are addressed to the State’s satisfaction. The State urges the use of industry scanning/testing tools and secure development methods be employed to avoid unexpected costs and project delays. Costs to produce and deliver secure and reliable applications are the responsibility of the software entity producing or delivering an application to the

State. Unless expressly indicated in writing, the State assumes all price estimates and bids are for the delivery and support of applications and systems that will pass security and performance testing. If the State determines the hardware, website(s), software, and or cloud services have security vulnerabilities that must be corrected, the State will inform the offeror of the nature of the issue and the offeror will be required to respond in writing regarding mitigation plans for the security vulnerabilities. If the product(s) does not pass the initial security scan, additional security scans may be required to reach an acceptable level of security. The offeror must pass a final follow-up security scan for the website(s), software or cloud services for the product(s) to be acceptable products to the State. The State may suspend or cancel payments for hardware, website(s), software, or cloud services that do not pass a final security scan.

2.11.8 Any website or web application hosted by the offeror that generates email cannot use “@state.sd.us” as the originating domain name per state security policy.

2.11.9 As part of this project, the offeror will provide a monitoring tool the State can utilize to monitor the operation of the proposed solution as well as all systems and all subcomponents and connections. It is required that this tool be easy to use and provide a dashboard of the health of the proposed solution. The effectiveness of this monitoring tool will be a component of the acceptance testing for this project.

2.11.10 As part of the project plan, the offeror will include development of an implementation plan that includes a back out component. Approval of the implementation plan by BIT should be a project milestone. Should the implementation encounter problems that cannot be resolved and the implementation cannot proceed to a successful conclusion, the back out plan will be implemented. The Implementation and back out documentation will be included in the project documentation.

2.11.11 The successful offeror will use the approved BIT processes and procedures when planning its project, including BIT’s change management process. Work with the respective agency’s BIT Point of Contact on this form. The Change Management form is viewable only to BIT employees. The purpose of this form is to alert key stake holders (such as: Operations, Systems Support staff, Desktop Support staff, administrators, Help Desk personnel, client representatives, and others) of changes that will be occurring within state resources and systems to schedule the:

2.11.12 Movement of individual source code from test to production for production systems

2.11.13 Implementation of a new system

2.11.14 A major enhancement to a current system or infrastructure changes that impact clients

2.11.15 Upgrades to existing development platforms

2.11.16 If as part of the project the state will be acquiring software the proposal should clearly state if the software license is perpetual or a lease. If both are options, the proposal should clearly say so and state the costs of both items separately.

2.11.16.1 Include in your submission details on your:

2.11.16.2 Data loss prevention methodology;

2.11.16.3 Identity and access management;

2.11.16.4 Security intelligence;

2.11.16.5 Annual security training and awareness;

2.11.16.6 Manual procedures and controls for security;

2.11.16.7 Perimeter controls;

2.11.16.8 Security certifications and audits.

2.12 If the offeror will have State data on its system(s) or on a third-party’s system and the data cannot be sanitized at the end of the project, the offeror’s proposal must indicate this and give the reason why the data cannot be sanitized as per the methods in NIST 800-88.

2.13 The offeror’s solution cannot include any hardware or hardware components manufactured by Huawei Technologies Company, Nuctech, or ZTE Corporation or any subsidiary or affiliate of such entities. This includes hardware going on the State’s network as well as the offeror’s network if the offeror’s network is accessing the State’s network or accessing State data. This includes Infrastructure as a Service, Platform as a Service or Software as a Service situations.

Any company that is considered to be a security risk by the government of the United States under the International Emergency Economic Powers Act, in a United States appropriation bill, an Executive Order, or listed on the US Department of Commerce’s Entity List will be included in this ban.

2.14 If the offeror’s solution requires accounts allowing access to State systems, then the offeror must indicate the number of the offeror’s staff or subcontractors that will require access, the level of access needed, and if these accounts will be used for remote access. These individuals will be required to use Multi-Factor Authentication (MFA). The State’s costs in providing these accounts will be a consideration when assessing the cost of the offeror’s solution. If the offeror later requires accounts that exceed the number of accounts that was originally indicated, the costs of those accounts will be borne by the offeror and not passed onto the State. All State security policies can be found in the Information Technology Security Policy (ITSP) attached to this RFP. The offeror should review the State’s security policies regarding authorization, authentication, and, if relevant, remote access (See ITSP 230.67, 230.76, and 610.1). Use of Remote Access Devices (RAD) by contractors to access the State’s system must be requested when an account is requested. The offeror should be aware that access accounts given to non-state employees, Non-State (NS) accounts, will be disabled if not used within 90 days. A NS account may be deleted after 30 days if it is not used.

2.15 The following testing may be required:

2.15.1 Regression Testing- Regression testing is the process of testing changes to computer programs to make sure that the older programming still works with the new changes.

2.15.2 Integration Testing- Integration testing is a software development process which program units are combined and tested as groups in multiple ways. In this context, a unit is defined as the smallest testable part of an application. Integration testing can expose problems with the interfaces among program components before trouble occurs in real-world program execution. Integration testing is also known as integration and testing (I&T).

2.15.3 Functional Testing- Functional testing is primarily used to verify that a piece of software is meeting the output requirements of the end-user or business. Typically, functional testing involves evaluating and comparing each software function with the business requirements. Software is tested by providing it with some related input so that the output can be evaluated to see how it conforms, relates or varies compared to its base requirements. Moreover, functional testing also checks the software for usability, such as ensuring that the navigational functions are working as required. Some functional testing techniques include smoke testing, white box testing, black box testing, and unit testing.

2.15.4 Performance Testing- Performance testing is the process of determining the speed or throughput of an application. This process can involve quantitative tests such as measuring the response time or the number of MIPS (millions of instructions per second) at which a system functions. Qualitative attributes such as reliability, scalability, and into operability may also be evaluated. Performance testing is often done in conjunction with load testing.

2.15.5 Load Testing- Load testing is the process of determining the ability of an application to maintain a certain level of effectiveness under unfavorable conditions. The process can involve tests such as ramping up the number of users and transactions until the breaking point is reached or measuring the frequency of errors at your required load. The term also refers to qualitative evaluation of factors such as availability or resistance to denial-of-service (DoS) attacks. Load testing is often done in conjunction with the more general process of performance testing. Load testing is also known as stress testing.

2.15.6 User Acceptance Testing- User acceptance testing (UAT) is the last phase of the software testing process. During UAT, actual software users test the software to make sure it can handle required tasks in real-world scenarios, according to specifications. UAT is one of the final and critical software project procedures that must occur before newly developed or customized software is rolled out. UAT is also known as beta testing, application testing or end user testing. In some cases, UAT may include piloting of the software.

The State, at its sole discretion, may consider a solution that does include all or any of these deliverables or consider deliverables not originally listed. An offeror must highlight any deliverable it does not meet and give any suggested “work-around” or future date that it will be able to provide the deliverable.

2.16 NON-STANDARD HARDWARE AND SOFTWARE

State standard hardware and software should be utilized unless there is a reason not to. If your proposal will use non-standard hardware or software, you must first obtain State approval. If your proposal recommends using non-standard hardware or software, the proposal should very clearly indicate what non-standard hardware or software is being proposed and why it is necessary to use non-standard hardware or software to complete the project requirements. The use of non-standard hardware or software requires use of the State’s New Product Process. This process can be found through the Standards’ page and must be performed by State employees.

The costs of such non-standard hardware or software should be reflected in your cost proposal.

The work plan should also account for the time needed to complete the New Product Process.

See https://bit.sd.gov/bit?id=bit_standards_overview, for lists of the State’s standards. The proposal should also include a link to your hardware and software specifications.

If non-standard hardware or software is used, the project plan and the costs stated in Section 7 must include service desk and field support, since BIT can only guarantee best effort support for standard hardware and software. If any software development may be required in the future, hourly development rates must be stated. The project plan must include the development and implementation of a disaster recovery plan since non-standard hardware and software will not be covered by the State’s disaster recovery plan. This must also be reflected in the costs.

The offeror must complete the list of technical questions, Security and Vendor Questions which is attached as Appendix B. These questions and the offeror’s responses may be used in the proposal evaluation.

2.17 BACKGROUND CHECKS

The offeror must include the following statement in its proposal:

(Company name here) acknowledges and affirms that it understands that the (company name here) employees who have access to production Personally Identifiable Information (PII), data protected under the Family Educational Rights and Privacy Act (FERPA), Protected Health Information (PHI), Federal Tax Information (FTI), any information defined under state statute as confidential or have access to secure facilities will have fingerprint-based background checks. These background checks will be used to check the criminal history records of the State as well as the Federal Bureau of Investigation’s records. (Company name here) acknowledges and affirms that this requirement will extend to include any Subcontractor’s, Agents, Assigns and or Affiliated Entities employees.

3. Proposal Response

The Consultant is cautioned that it is the Consultant’s sole responsibility to submit information related to the evaluation categories and that the State is under no obligation to solicit such information if it is not included with the proposal. The Consultant's failure to submit such information may cause an adverse impact on the evaluation of the proposal.

3.1 An original hardcopy shall be submitted.

3.1.1 In addition, the Consultant shall provide one (1) copy of their entire proposal, including all attachments, in Microsoft Word or PDF electronic format. Consultants shall enclose the electronic copy with their mailed response and may not send the electronically copy of their proposal via email.

3.2 The proposal must be page numbered and should have an index and/or a table of contents referencing the appropriate page numbers.

3.3 All proposals must be…