RFP Document.pdf

UPDATED APRIL 10, 2025 V5.1 1

STATE OF SOUTH DAKOTA

INFORMATION TECHNOLOGY (IT) RFP

DEPARTMENT OF EDUCATION

800 GOVERNORS DRIVE

PIERRE, SOUTH DAKOTA 57501-2235

CACFP Financial Management System

PROPOSALS ARE DUE NO LATER THAN December 29, 2025, 5:00PM CST

RFP #: 25RFP13437 STATE POC: Rochelle Kenzy EMAIL: Rochelle.Kenzy@state.sd.us

READ CAREFULLY

FIRM NAME: AUTHORIZED SIGNATURE:

ADDRESS: TYPE OR PRINT NAME:

CITY/STATE: TELEPHONE NO:

ZIP (9 DIGITS): FAX NO:

E-MAIL:

PRIMARY CONTACT INFORMATION

CONTACT NAME:

TELEPHONE NO:

FAX NO: E-MAIL:

mailto:Rochelle.Kenzy@state.sd.us

UPDATED APRIL 10, 2025 V5.1 2

1 General Information

1.1 Purpose of Request for Proposal (RFP)

The South Dakota Department of Education’s Division of Child and Adult Nutrition Services (“State”) seeks a qualified vendor to provide professional services on behalf of the State of South Dakota for the purpose of meeting United States Department of Agriculture (USDA) Child and Adult Care Food Program financial management requirements as further specified in Section 3 below.

1.2.1 Background:

Child and Adult Nutrition Services (CANS) is seeking a system to assist with Child and

Adult Care Food Program (CACFP) bank statement reviews. This system will be used to meet federal requirements and will allow program operators to submit a month's worth of bank statements and corresponding information. Once the information has been uploaded, State staff will review annually to ensure program compliance.

1.2.2 Goals and Objectives:

Accurately collect and review financial information. Ensure regulatory compliance and promote transparency and accountability.

1.2 Issuing Office and RFP Reference Number

The South Dakota Department of Education (“Agency”) is the issuing office for this document and all subsequent addenda relating to it, on behalf of the State of South Dakota. The reference number for this transaction is RFP#25RFP13437. This reference number must be referred to on all proposals, correspondence, and documentation relating to this RFP. For purposes of this RFP, the State’s centralized IT agency, the Bureau of Information and Telecommunications (“BIT”), must approve all IT related purchases.

1.3 Schedule of Activities (Subject to Change)

All deadlines in the Schedule of Activities are due by 5:00 p.m. CST. The Schedule of Activities for this RFP is as follows:

RFP Publication November 4, 2025 Deadline for Letter of Intent to Respond November 14, 2025, 5:00 PM CT Deadline for Submission of Written Inquiries December 1, 2025, 5:00 PM CT Deadline for Responses to offeror Questions December 15, 2025, 5:00 PM CT Deadline for Proposal Submission December 29, 2025, 5:00 PM CT Discussions / Technical Review January 2026 Demonstrations and presentations (if required) January 2026 Anticipated Award Decision/Contract Negotiation February 2026

1.4 Letter of Intent

All interested offerors may submit a Letter of Intent to respond to this RFP.

The Letter of Intent must be submitted to the Agency via email at

UPDATED APRIL 10, 2025 V5.1 3

Rochelle.Kenzy@state.sd.us by the date and time indicated in Section 1.3 Schedule of Activities. Please place the following in the subject line of your email: “Letter of Intent for RFP#25RFP13437”.

1.5 Submitting a Proposal

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

Proposals received after the Deadline for Proposal Submission will be late and ineligible for consideration.

All proposals must be signed, in ink or electronically, by a representative of the offeror who is legally authorized to bind the offeror to the proposal. Proposals that are not properly signed may be rejected. The offeror’s proposal must be prepared pursuant to the requirements of Section 6 Proposal Submission Requirements of this RFP.

The State will only accept electronic proposals via email.

Each offeror must provide an electronic version of the proposal. The electronic version should be provided in MS Word or in PDF format to Rochelle.Kenzy@state.sd.us. The email, including attachments, must be limited to 20MB in size.

No proposal will be accepted from, or no contract or purchase order will 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 of South Dakota.

1.6 Certification Regarding Debarment, Suspension, Ineligibility, and Voluntary

Exclusion – Lower Tier Covered Transactions

By signing and submitting this proposal, the offeror certifies that neither it nor its principals is 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 offeror is unable to certify to any of the statements in this certification, the offeror shall attach an explanation to its offer.

1.7 Non-Discrimination Statement

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

1.8 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

UPDATED APRIL 10, 2025 V5.1 4

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.9 Certification Relating to Prohibited Entity

For contractors, vendors, suppliers, or subcontractors who enter into a contract with the State of South Dakota 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, is not a prohibited entity, regardless of its principal place of business, that is ultimately owned or controlled, directly or indirectly, by a foreign national, a foreign parent entity, or foreign government from China, Iran, North Korea, Russia, Cuba, or Venezuela, as defined by South Dakota Codified Law § 5-18A. 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 and would be cause to suspend and debar a business under SDCL § 5-18D-12.

1.10 Certification of No State Legislature Interest

The bidder or 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, the bidder or offeror certifies that the Agreement is not made in violation of the South Dakota Constitution Article 3, Section 12.

UPDATED APRIL 10, 2025 V5.1 5

1.11 Modification or Withdrawal of Proposals

Proposals may be modified or withdrawn by the offeror prior to the established due date and time.

No oral, telephonic, telegraphic or facsimile responses or modifications to informal, formal bids, or Request for Proposals will be considered.

1.12 Questions Regarding RFP

All written questions should be sent to: Rochelle.Kenzy@state.sd.us, only emailed questions will be accepted.

Each offeror may submit questions via email concerning this RFP to obtain clarification of requirements. No questions will be accepted after the date and time indicated in the above schedule of activities. Email questions to the email address listed above with the subject line “RFP#25RFP13437”. The questions and their answers will be sent to all offerors that submitted Letters of Intent, submitted questions, or requested the questions and answers via email before the proposal submittal date and will be sent by the date and time indicated in the above calendar of events. Offeror 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 that have not originated from the SD RFP Project Contact. Offerors will be notified in the same manner as indicated above regarding any modifications to this RFP. Offerors and their agents may not contact any state employee other than the buyer of record regarding any of these matters during the solicitation and evaluation process.

Inappropriate contacts are grounds for suspension and exclusion from specific procurements.

1.13 Proprietary Information

The proposal of the successful offeror(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. An entire proposal may not be marked as proprietary. Offerors 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 of South Dakota and may be returned only at the State's option.

1.14 Length of Contract

The proposed contract term will be from January 2026 to September 2028, based on the Consultant’s proposal. The State may choose to renew the contract for an additional one- , two-, or three-year period; however, such extensions will not be automatic.

1.15 Governing Law

This RFP will be governed by and construed in accordance with the laws of the State of

UPDATED APRIL 10, 2025 V5.1 6

South Dakota. Any lawsuit pertaining to or affecting this RFP will be venued in Circuit Court, Sixth Judicial Circuit, Hughes County, South Dakota.

1.16 Presentations/Demonstrations

At the State’s discretion, the State may require a presentation or demonstration by an offeror to clarify a proposal. However, the State may award a contract based on the initial proposals received without a presentation or demonstration by the offeror. If presentations or demonstrations are required, they will be scheduled after the submission of proposals. Presentations and demonstrations will be made at the offeror’s expense.

1.17 Technical Review

At the State’s discretion, the State may require a technical review of the offeror based on the offeror’s proposal and response to the Security and Vendor Questionnaire.

1.18 Negotiations

This process is a Request for Proposal/Competitive Negotiation process. Each proposal will be evaluated, and each respondent will be available for negotiation meetings at the State’s request. The State reserves the right to negotiate on any component of every proposal submitted. From the time the proposals are submitted until the formal award of a contract, each proposal is considered a working document and as such, will be kept confidential. The negotiation discussions will also be held as confidential until such time as the award is completed.

2 Standard Contract Terms and Conditions

Any contract or agreement resulting from this RFP will include the State’s standard terms and conditions as attached in Exhibit A, the State’s standard Information Technology (“IT”) contract terms listed in Exhibit D, and any additional terms and conditions as negotiated by the parties.

The offeror must indicate in its response any issues it has with specific contract terms. If the offeror does not indicate that there is an issue with a specific contract term, then the offeror will be deemed to have accepted the contract terms as written.

3 Scope of Work

The Offeror shall:

3.1 Propose a web-based customizable system that allows the program operators to enter their financial information for program funds. The system must be able to allow the sponsor to upload and the State to review documentation uploaded into the system.

• The State is requesting the proposal have options for hosting on the Offeror’s server and\or on the State’s server. The Consultant must submit separate proposals for scope of work and cost proposal for each option.

• While this is not a disqualification, the State would prefer the system not to use

Silverlight, QuickTime, PHP, Adobe ColdFusion, Adobe Flash or Adobe

UPDATED APRIL 10, 2025 V5.1 7

Animate CC. If the Offeror does use one of the listed applications above, the Offeror should indicate how the program is used and how they plan to limit the security risk associated with the program and\or remove the application in the future. The Offeror shall meet the required technology requirements as identified in Section 4.

3.2 The system shall meet the Child and Adult Care Food Program (CACFP) 7 CFR 226.7(a) and CACFP 09-2024, establish a financial management system to adhere to financial management standards.

• Annually reviewing at least 1 month's bank account activity of all sponsoring organizations against documents adequate to support that the financial transactions meet program requirements and allow expansion, as need if discrepancies are found

• Annually reviewing actual expenditures reported as program funds and the amount of meal reimbursement funds retained from centers, if any, for administrative costs for all sponsoring organizations of unaffiliated centers.

• Must reconcile reported expenditures with program payments to ensure that funds are fully accounted for and use the reported actual expenditures as the basis for selecting a sample of expenditures for validation.

• Monitoring and reviewing the institutions' documentation of their nonprofit status to ensure that all program reimbursement funds are used solely for the conduct of the food service operation or to improve food service operations, principally for the benefit of children or adult participants.

3.3 Provide an implementation schedule

• The State’s preferred timeline would tentatively be as follows:

• January 2026 – June 2026: Customization of the system to meet

State requirements

• June 2026 – September 2026: System testing and continued customization of the system, Testing shall include at a minimum, integration, functional, performance, and load testing

• October 2026: System Launch

• August – September 2026: Provide training to the State and local agency

• October 2026 – September 2028: Continued Support and

Maintenance

• The implementation schedule should indicate how the Consultant will complete the required deliverables and services and address the following:

• Proposed project management techniques

• Tasks to be performed (within phase as applicable)

• Deliverables created by each task

• Dates by which each task will be completed (dates should be

UPDATED APRIL 10, 2025 V5.1 8

indicated in terms of elapsed time from project inception)

• Resources assigned to each task

• Required State support

• Show task dependencies

• Training

• The deliverables shall:

• Include a test platform for the State to enter both mock data and periodically get refreshed with actual live system data. Test platform will also allow the State to test system updates and changes before they are moved to the live system.

• Include a complete and accurate system manual for the State users and local agency users for the CACFP.

• Include functioning reports that summarize common issues or errors.

• Provide in-person or virtual training for State staff after full system implementation is complete.

• Provide webinar trainings to local agencies to be recorded and given to the State for posting on the State website.

• The Offeror shall provide a system stored procedure document to show how the numbers in the reports are calculated within the system (Tables and fields are needed for calculation, plus criteria used) and an Entity-Relationship Diagram (ERD). The ERD should be a graphically illustration that shows a system’s entities and their relationships to include how all the tables in a system are related, field types, primary keys, etc.

• The system security shall:

• Be secured in a manner that will allow the State to assign users and security rights to different types of users, for example school/agency view only rights, school/agency modify rights, State agency reviewer rights, etc.

• Allow only school/agency users to modify menus or upload documents and areas that require their response and not allow State users to modify or upload in any school/agency areas.

• Allow users to make comments

• Have all identified security risks and security scan results resolved before launch of the system.

• The Bureau of Information and Telecommunications (BIT) shall run a security scan on the test environment running the same code as production to identify any possible security risks. Any identified security results from this scan will need to be resolved.

4 Project Deliverables/Approach/Methodology

The offeror must describe in detail how its proposed deliverables will meet the needs of the State as described in Section 3. At its sole discretion, the State may consider a solution that includes any of these deliverables or consider deliverables not originally listed.

UPDATED APRIL 10, 2025 V5.1 9

An offeror must highlight any requirement in Section 3 or Section 4 that the offeror’s proposed deliverables cannot comply with, and the offeror must provide any suggested “work-around” to the requirement in question or a future date that the offeror will be able to comply with the requirement.

4.1 The offeror’s proposal must include a:

• Project Management Plan

• Project Schedule

• Risk Management Plan

• Data Conversion Plan, if applicable

• Requirements Traceability Matrix

• Communication Plan

• Testing Plan

• Training Plan

• Go-Live/Cutover Plan

• Post-Implementation Support (or Maintenance and Operations Plan)

In addition, the offeror’s proposal must include how its proposed deliverables will meet the following IT requirements (General, State Hosted, and Vendor Hosted). If the offeror’s proposal includes an option for a state hosted solution and an option for a vendor hosted solution, the offeror must provide a separate response for each proposed solution and how each solution will meet the requirements in Sections 3 and 4.

4.2 GENERAL IT REQUIREMENTS

4.2.1 Hosting and Data Access Requirements

The State will own all data tables created as a result of the Agreement. The State must have the ability 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’s proposal must describe how the State can access data housed within the proposed solution for ingestion into a state data repository, encompassing available methodologies (e.g., application programming interface (API), flat file), data formatting, frequency of updates, and any inherent constraints. Additionally, the offeror’s proposal must provide a high-level architecture diagram, as part of the solution diagram as required by Section 6.7, explaining the proposed solution's data provision mechanism.

4.2.2 Single Sign-On Requirements

If the offeror’s proposal includes a deliverable with a login component, the proposal must describe how the deliverable will integrate with the State’s standard identity management service single sign-on (SSO).

The State’s SSO supports the industry standard OAuth 2.0 protocol. This identity management will handle password recovery and multi-factor

UPDATED APRIL 10, 2025 V5.1 10

authentication (MFA). MFA is required for all application Administrators and may be required for other users. The State’s SSO requirement and links to Microsoft’s official documentation can be found at:

https://www.sd.gov/bit?id=bit_standards_single_sign_on.

If the offeror is not able to fulfill this identity management standard, the offeror’s proposal may be rejected from consideration.

4.2.3 SSO Logout Initiation Requirements

• The offeror’s deliverable must provide users with a clear and easily accessible logout mechanism (e.g., a “Logout” button/link).

• The logout functionality of the offeror’s deliverable must trigger a session-based logout process utilizing the sign-out endpoint found in the metadata document provided during implementation.

4.2.4 Session Timeout Requirements

• The offeror’s deliverables must allow for a customizable, State-defined inactive user session timeout period.

• The offeror’s deliverables must notify users of impending session expiration five minutes before the timeout occurs, providing users with the option to extend the session.

4.2.5 Session Termination on Browser Close Requirement

The offeror’s deliverables must clearly notify users that closing the browser window or tab is not a valid logout because the SSO session may remain active.

The notice must further notify users that they are responsible for explicitly logging out to ensure complete session termination.

4.2.6 Onboarding/Provisioning of Users Requirement

The offeror’s proposal must describe how new users are onboarded or provisioned into the deliverable. The offeror must provide an automated process for onboarding and offboarding users or must provide a process that requires minimal manual steps.

4.2.7 Interfaces and Integration Requirements

The offeror’s proposal must describe how the deliverables can adapt to business necessary interfaces using widely adopted open APIs and standards.

Additionally, the offeror must make available or expose software services that would enable third-party developers to interface other business applications.

The offeror must publish documentation for the software services in question.

The offeror’s proposal must include a detailed description of system capability.

4.2.8 Web Application Vulnerability Scan Requirements

Any web-based deliverable must undergo a web application vulnerability scan https://www.sd.gov/bit?id=bit_standards_single_sign_on

UPDATED APRIL 10, 2025 V5.1 11

(“Vulnerability Scan”). The Vulnerability Scan must identify misconfigurations or vulnerabilities such as those found in the OWASP Top Ten and must detail the certainty level of each finding.

Unless expressly indicated in writing, the State assumes all price estimates and bids are for the delivery and support of deliverables that will pass Vulnerability Scans. If the State determines that any aspect of the deliverable has 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 deliverable does not pass the initial Vulnerability Scan or the offeror cannot provide a satisfactory Vulnerability Scan report, additional scans may be required to confirm the deliverable is secure.

State Hosted: For state hosted web-based deliverables, the Vulnerability Scan will be performed by the State and the offeror’s proposal should take that into consideration when responding to this RFP. As a condition of the resulting contract, the state hosted web-based deliverable will have to successfully pass the Vulnerability Scan prior to the deliverable being allowed to go in a production environment. Any offeror who responds to this RFP must accept such a contract term and must factor this security requirement into the offeror’s proposal.

Vendor Hosted: For vendor hosted web-based deliverables, any offeror who makes it to the “Tech Review” stage of the RFP process must provide the State a copy of the full report of the deliverable’s most recent Vulnerability Scan, a summary will not be accepted. The offeror should mark the vulnerability report as “Confidential” if it treats such a report as confidential information. If the offeror requires a Non-Disclosure Agreement (NDA) to be in place before the State may review the Vulnerability Scan report, the offeror must notify the State of such a requirement and resolve the signing of an NDA with enough time to respond to this RFP within the timeframe.

The offeror’s Vulnerability Scan report must consist of, at a minimum:

• The system that was evaluated,

• The categories that were evaluated (examples: SQLi, XSS, or RCE),

• What were the general findings,

• Technical detail of each issue found,

• Remediation status of enumerated issues (if any).

The cost of any Vulnerability Scans done by the offeror or the offeror’s costs associated with the State performing Vulnerability Scans must be part of the offeror’s cost proposal. Failure of a deliverable to satisfactorily pass a Vulnerability Scan may result in the offeror’s proposal being rejected.

4.2.9 Test System Requirement

The offeror must include a test system for its application deliverables to be used

UPDATED APRIL 10, 2025 V5.1 12

at the discretion of the State. All resource costs, including licensing costs, associated with keeping the test system available must be detailed in the offeror’s cost proposal. If the offeror does not include the test system costs in the offeror’s proposal, then the offeror will bear the costs. The offeror will maintain the test system as a mirror image of the production system code base.

4.2.10 Internal Processes and Procedures Requirement

The offeror must use industry standard processes and procedures, such as a software development lifecycle, when planning the development, configuration, implementation, and support of a proposed deliverable. The offeror must outline their internal processes and procedures in their proposal, including, but not limited to, alerting 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 or offeror resources or systems.

4.2.11 Email Domain Name Requirement

If the offeror’s proposal includes a website or a web application that generates email and is hosted by the offeror or in the State’s cloud, the proposed website or web application cannot use state email domains as the originating domain name.

4.2.12 Banned Entity Requirement

The offeror’s proposed deliverables 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 of America 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.

4.2.13 Access Management Requirement

If the offeror’s proposed deliverables require 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 proposal. All costs associated with providing an account to the offeror will be borne by the agency.

4.2.14 Testing Requirements

UPDATED APRIL 10, 2025 V5.1 13

The following testing may be required:

4.2.14.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.

4.2.14.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).

4.2.14.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.

4.2.14.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 interoperability may also be evaluated. Performance testing is often done in conjunction with load testing.

4.2.14.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.

4.2.14.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 http://searchnetworking.techtarget.com/definition/response-time http://searchdatacenter.techtarget.com/definition/MIPS http://whatis.techtarget.com/definition/reliability http://searchdatacenter.techtarget.com/definition/scalability http://searchsoa.techtarget.com/definition/interoperability http://searchsoftwarequality.techtarget.com/definition/stress-testing http://searchnetworking.techtarget.com/definition/availability http://searchsoftwarequality.techtarget.com/definition/performance-testing

UPDATED APRIL 10, 2025 V5.1 14

known as beta testing, application testing or end user testing. In some cases, UAT may include piloting of the software.

4.3 STATE HOSTED SOLUTIONS (ON-PREM OR STATE CLOUD) REQUIREMENTS

4.3.1 Virtualized Environment Requirement

The offeror should state whether its proposed solution will operate in a virtualized environment. The offeror must 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 system diagram.

4.3.2 Network Vulnerability Scan Requirement

All deliverables hosted by the State will be subject to a network vulnerability scan by the State.

4.3.3 Load Balancing Requirement

The offeror must state if its proposed deliverables can be load balanced across multiple servers, which is a requirement for an application to operate within the State’s computing environment.

4.3.4 Use of Abstraction Technologies Requirement

The offeror must describe how its proposed deliverables use abstraction technologies, which is defined as the removal of the network control and forwarding functions that allows the network control to become directly programmable and the underlying infrastructure to be separated for applications and network services.

In addition, the offeror must affirmatively state that its proposed deliverables do not use hard-coded references.

4.3.5 Non-Standard Hardware and Software Requirement

State standard hardware and software should be utilized unless there is a reason not to. If the offeror’s proposal recommends using non-standard hardware or software, the proposal must 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 costs of such non-standard hardware or software should be reflected in the offeror’s cost proposal. See https://bit.sd.gov/bit?id=bit_standards_overview, for lists of the State’s standard hardware and software. The offeror’s proposal must include a link to the offeror’s hardware and software specifications if one is available or explain why a link is not available. BIT must approve the use of any non-standard hardware or software before a contract can be awarded.

4.3.6 Vendor to State Hosted Transition

https://bit.sd.gov/bit?id=bit_standards_overview

UPDATED APRIL 10, 2025 V5.1 15

If, as part of the proposed project plan, the offeror intends to set up or configure a deliverable outside of State’s IT infrastructure, even in part, and then move said deliverable to the State’s infrastructure, then the offeror must provide a complete and detailed project plan on how that transition will occur. The offeror’s proposal should include any additional time and money considerations for the transition.

4.4 VENDOR HOSTED SOLUTION REQUIREMENTS

4.4.1 General Vendor Hosted Requirements

In the offeror’s proposal, the offeror must describe its:

• Data loss prevention methodology;

• Data sanitization methodology and procedures;

• Identity and access management;

• Security intelligence;

• Annual security training and awareness;

• Manual procedures and controls for security;

• Perimeter controls;

• Security certifications and audits.

4.4.2 Import and Export of Data Requirement

The offeror’s proposed deliverables must allow the State the ability to import or export the State’s data piecemeal or in its entirety at the State’s discretion without interference from the offeror. The data must be able to be exported in a non-proprietary format and must include information such as metadata (data structure descriptions, data dictionary, and data). The offeror’s proposal must describe how this functionality works within its deliverables.

5 Proposal Submission Requirements

The offeror’s proposal should be prepared simply and economically and provide a direct, concise explanation of the offeror’s proposal and qualifications. Elaborate brochures, sales literature, and other presentations unnecessary to a complete an effective proposal should not be submitted.

The offeror is cautioned that it is the offeror's sole responsibility to submit information related to the evaluation categories. The State of South Dakota is under no obligation to solicit any information that is not included with the proposal. The offeror's failure to submit all requested information in this RFP may cause an adverse impact on the evaluation of the offeror’s proposal. The offeror should respond to each point in Sections 3 and 4 in the order they were presented.

5.1 Use of State Seal Restriction

The offeror’s proposal should refrain from using the State of South Dakota State Seal in its proposal. Offerors are cautioned that use of the State Seal in any of its documents is illegal as per South Dakota Codified Law § 1-6-3.1. Use of seal or facsimile without

UPDATED APRIL 10, 2025 V5.1 16

authorization prohibited--Violation as misdemeanor. No person may reproduce, duplicate, or otherwise use the official seal of the State of South Dakota, or its facsimile, adopted and described in §§ 1-6-1 and 1-6-2 for any for-profit, commercial purpose without specific authorization from the secretary of state. A violation of this section is a Class 1 misdemeanor.

5.2 Format of Proposal

5.2.1 The offeror’s proposal must be submitted pursuant to the requirements of Section

1.5 of this RFP.

5.2.2 The offeror’s proposal should be page numbered and should have an index or a table of contents referencing the appropriate page number. Each of the sections listed in Section 6.2.3 should be tabbed.

5.2.3 The offeror’s proposal should be prepared using the following headings and, in the order that they are presented below. Please reference the section for details on what should be included in your proposal.

• Statement of Understanding of the Project\Executive Summary

• Deliverables

• Project Plan

• IT Requirements

• Required Diagrams (If not a separate document)

• Security and Vendor Questionnaire (If not a separate document)

• Response to the State’s Contract Terms

• Corporate Qualifications

• Project Experience and References

• Team Organization and Staff Resumes

• Background Investigations

• Cost (If not a separate document)

• Audited Financial Statement

• South Dakota Substitute W9.

• Certification Relating to Prohibited Entity.

5.3 Statement of Understanding of the Project\Executive Summary

The offeror’s proposal must summarize the offeror’s understanding of the State’s needs as enumerated in Section 3 and the work required to meet those needs (“Executive Summary”). The Executive Summary should include, but not be limited to, the offeror’s understanding of the purpose and scope of the project, critical success factors and potential problems related to the project, and the offeror’s understanding of the deliverables. The offeror must include their specialized expertise, capabilities, and technical competence as demonstrated by the proposed approach and methodology to meet the project requirements. The Executive Summary should be limited to no more than two pages.

5.4 Deliverables

The offeror’s proposal must include a Deliverables section which constitutes the major portion of the work to be performed. The offeror’s Deliverables section must include a

UPDATED APRIL 10, 2025 V5.1 17

complete narrative detailing the assessment of the work to be performed, approach and methods to provide the requirements of this RFP, the offeror’s ability to fulfill the requirements of this RFP, the offeror’s approach, the resources necessary to fulfill the requirements, project management techniques, specialized services, availability to the project locale, familiarity with the project locale, and a description of any options or alternatives proposed. The offeror’s Deliverables section should address each evaluation requirement enumerated in Section 8. If the offeror has an alternative methodology or deliverable it would like to propose to meet the needs of the State, please include a detailed description of the alternative methodology or deliverables and how the alternative options will meet or exceed the requirements of this RFP.

5.5 Project Plan

The offeror’s proposal must provide a project plan that indicates how the offeror will complete the required deliverables and services and addresses the following:

• Proposed project management techniques

• Number of offeror’s staff needed

• Tasks to be performed (within phase as applicable)

• Number of hours each task will require

• Deliverables created by each task

• Dates by which each task will be completed (dates should be indicated in terms of elapsed time from project inception)

• Resources assigned to each task

• Required state agency support

• Show task dependencies

• Training (if applicable)

Microsoft Project is the standard scheduling tool for the State of South Dakota. The schedule should be a separate document, provided in Microsoft Excel, and submitted as an attachment to your proposal.

5.6 IT Requirements

The offeror’s proposal must highlight any requirement in Section 4 that the offeror’s proposed deliverables cannot comply with, and the offeror must provide any suggested “work-around” to the requirement in question or a future date that the offeror will be able to comply with the requirement.

5.7 Required Diagrams

5.7.1 System Diagram. The offeror’s proposal must include a system diagram which must provide specific details so that the State can understand the components, the system flow, and system requirements. If the offeror’s proposal includes more than one hosting option, the offeror must provide a system diagram for each option. 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.

UPDATED APRIL 10, 2025 V5.1 18

5.7.2 Solution Diagram. The offeror’s proposal must include a solution diagram which must provide specific details on how the offeror’s proposed deliverables will meet the requirements of this RFP. The solution diagram must include: integration with the State’s infrastructure; existing systems that will integrate with the proposed deliverables; how data would flow between systems; all components, tools, and products the proposed deliverables will utilize, the technology stack of the proposed deliverables including any dependencies; and include, but not be limited to, user onboarding/provisioning and SSO.

5.8 Security and Vendor Questionnaire

The offeror must submit a completed Security and Vendor Questionnaire, which is attached to this RFP as Exhibit G, for each proposed deliverable. If the offeror’s proposal includes more than one hosting option, the offeror must complete a Security and Vendor Questionnaire for each hosting option and indicate which questionnaire belongs to which hosting option. The Security and Vendor Questionnaire will be used in the proposal evaluation. The offeror must complete the Security and Vendor Questionnaire in the Microsoft Word format as it is provided to the offeror.

5.9 Response to the State’s Contract Terms

The offeror’s proposal must indicate any issues the offeror has with specific contract terms found in Section 2 and Exhibit D. If the offeror does not indicate that there is an issue with a specific contract term, then the offeror will be deemed to have accepted the contract terms as written.

5.10 Corporate Qualifications

5.10.1 Offeror Company Information

The offeror’s proposal must include responses to the each of the following questions:

• What year was your firm established?

• What is your firm’s website?

• Has your firm ever done business under a different name and if so, what was the name?

• How many employees does your firm have?

• How many employees in your firm are involved in this type of project?

• How many of those employees are involved in on-site project work?

• Has your firm ever done business with other governmental agencies? If so, please provide references.

• Has your firm ever done business with the State of South Dakota? If so, please provide references.

• Has your firm ever done projects that are exactly like or similar to this project?

• How many clients are currently using your proposed solution? How many of those clients are public sector: local, state, and federal?

5.10.2 Offeror Parent Company

UPDATED APRIL 10, 2025 V5.1 19

If the offeror has a parent company, the offeror’s proposal must include responses to the following questions:

• What is the name of your parent company?

• What year was your parent company established?

• What is your parent company’s website?

• What is the business of your parent company?

• What is the total number of employees in the parent company?

• What are the total revenues of your parent company?

• How many employees of your parent company have the skill set to support this effort?

• How many of those employees are accessible to your organization for active support?

• What percent of your parent company’s revenue (if applicable), is produced by your firm?

5.11 Project Experience and References

The offeror’s proposal must provide details about the three most recent projects that the offeror was awarded and managed through to completion. If the offeror cannot provide four examples, the offeror must explain why it cannot provide three examples and must provide as many examples as possible. These most recent projects will serve as references. Project examples must include the following information (if available):

• Client Name

• Client Address, including City, State and Zip Code

• Client Contact(s), including Name, Title, Telephone Number, and E-mail Address.

• Project Start Date and Completion Date

• Estimated Project Timeframe and Actual Project Timeframe (if actual timeframe is greater than estimated, please provide an explanation)

• Project Description and Goals

• Offeror’s Role in Project

• Offeror’s Responsibilities

• Offeror’s Accomplishments

• Description of How Project Was Managed

• Estimated Project Cost and Actual Project Cost (if actual costs exceed estimated costs, please provide an explanation)

• Description of special project constraints, if applicable

• Description of offeror’s ability and proven history in handling special project constraints

• Description of all changes to the original plan or contract that were requested

(describe which changes were completed)

• Description of how change requests were addressed or completed by offeror

• Was there any litigation or adverse contract action regarding contract performance?

(If “Yes” provide explanation)

• Feedback on offeror’s Work by Client

• Offeror’s Statement of Permission for the State to contact the Client and for the

Client’s contact(s) to release information to the State

UPDATED APRIL 10, 2025 V5.1 20

5.12 Team Organization and Staff Resumes

In this subsection, the offeror’s proposal must provide the requested information and identify the individuals who will fulfill the roles for the offeror.

5.13 Background Investigations

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 or federal statute as confidential or have access to secure facilities will have fingerprint-based background investigations. These background investigations 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 subcontractors, agents, assigns, and affiliated entities.

5.14 Cost

In this subsection, the offeror’s proposal must provide the requested information in Section 6 Cost Proposal.

The project plan and the costs stated in Section 6 Cost Proposal must include service desk and support, since BIT can only guarantee best effort support for on-prem vendor proposed solutions. If any software development may be required in the future, hourly development rates must be stated in the offeror’s proposal and Section 6 Cost Proposal.

The project plan must include the development and implementation of a disaster recovery plan since vendor hosted solutions will not be covered by the…