RFP Document.pdf

STATE OF SOUTH DAKOTA

Department of Agriculture and Natural Resources

Office of Water, Water Rights Program 523 E Capitol Ave, Pierre SD 57501

RFP to Convert Water Rights and Water Use Databases from FoxPro to GIS-Centric Database

PROPOSALS ARE DUE NO LATER THAN 5:00 PM (Central Time) May 9, 2025

RFP #: 25RFP14102 State POC: Ron Duvall EMAIL: ron.duvall@state.sd.us

READ CAREFULLY

OFFEROR INFORMATION

FIRM NAME:

AUTHORIZED

SIGNATURE:

ADDRESS: TYPE OR PRINT NAME:

CITY/STATE: TELEPHONE NO:

ZIP (9

DIGIT): FAX NO:

E-MAIL:

PRIMARY CONTACT INFORMATION

CONTACT

NAME:

TELEPHONE

NO:

FAX NO: E-MAIL:

1.0 GENERAL INFORMATION

1.1 PURPOSE OF REQUEST FOR PROPOSAL (RFP)

The purpose is to convert water rights and water use data currently in Microsoft FoxPro (all free tables, not wrapped in a database container) to an ESRI, GIS-centric database solution with an annual water use reporting requirement, including retention of historical water reporting use. The successful vendor will propose solutions where the converted data and ongoing data collection will be hosted locally by the State of South Dakota, by the contractor in the cloud, or by a combination of both. The ability for the State to generate mailings, access PDF documents associated with the data, and create reports is a necessity, whether by custom-built tools or “off the shelf” tools. The data, wherever hosted, will remain the property of the State of South Dakota.

A two-year contract will be issued to complete the data conversion with potentially an ongoing commitment to receiving professional services from the contractor depending on the proposal and where the solution is hosted.

1.2 ISSUING OFFICE AND RFP REFERENCE NUMBER

The Office of Water, Water Rights Program is the issuing office for this document and all subsequent addenda relating to it, on behalf of the State of South Dakota, Department of Agriculture and Natural Resources. The reference number for the transaction is RFP # 25RFP14102. This number must be referred to on all proposals, correspondence, and documentation relating to the RFP.

1.3 DEFINITIONS USED IN THIS RFP

The following definitions are used in this RFP:

Offeror – A company who has submitted a proposal in response to this RFP.

Contractor – An Offeror that has been awarded a contract as a result of this RFP.

State – South Dakota Department of Agriculture and Natural Resources, Office of Water, Water Rights Program.

1.4 LETTER OF INTENT

All interested Offerors are requested to submit a non-binding Letter of Intent to respond to this RFP. While preferred, a Letter of Intent is not mandatory to submit a proposal. The letter of intent must be received in the Water Rights Program no later than 5:00 PM Central Time April 14, 2025. Be sure to reference the RFP number in your letter.

The Letter of Intent should be submitted to Ron Duvall via email at ron.duvall@state.sd.us.

Please place the following in the subject line of your email: “Letter of Intent for RFP # 25RFP14102”. Be sure to reference the RFP number in any attached letter or document.

1.5 OFFEROR INQUIRIES

Offerors may 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 emailed Ron Duvall to ron.duvall@state.sd.us with the subject line “RFP #

25RFP14102.”

The State will respond to Offeror’s inquiries (if required) via e-mail. All inquiries and the State’s response will be posted on the state’s e-procurement system. Offerors 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. Offerors will be notified in the same manner as indicated above regarding any modifications to this RFP. Offerors 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. Offerors will be notified in the same manner as indicated above regarding any modifications to this RFP.

Offerors are expected to raise any questions, exceptions, or additions they have concerning the RFP document by the deadline for submission for written inquiries as indicated in the Schedule of Activities. If an Offeror discovers any significant ambiguity, error, conflict, discrepancy, omission or other deficiency in this RFP, the Offeror should immediately notify Ron Duvall, of such error and request modification or clarification of the RFP.

1.6 OFFEROR’S CONTACTS

Offerors and their agents (including subcontractors, employees, consultants, or anyone else acting on their behalf) must direct all of their questions or comments regarding the RFP, the evaluation, etc. to Ron Duvall as indicated above. Offerors and their agents may not contact any other state employee regarding any of these matters during the solicitation and evaluation process without routing any such requests through Ron Duvall. Inappropriate contacts are grounds for suspension and/or exclusion from specific procurements. Offerors and their agents who have questions regarding this matter should contact Ron Duvall as indicated above.

1.7 SCHEDULE OF ACTIVITIES (SUBJECT TO CHANGE)

RFP Publication March 28, 2025 Letter of Intent/Offeror Questions Due April 14, 2025 Responses to Questions Posted on or before April 21, 2025 Proposals Due May 9, 2025 Notification of shortlisted Offerors May 21, 2025 Conduct shortlisted Offerors demos June 23 – June 27, 2025 Conduct Tech Reviews with shortlisted Offerors June 30 – July 11, 2025 Finalize selection and notice of award July 25, 2025

1.8 PREPARING AND SUBMITTING YOUR PROPOSAL

Elaborate proposals (e.g., expensive artwork) beyond that sufficient to present a complete and effective presentation are not necessary or desired.

1.8.1 Incurring costs

The State is not liable for any cost incurred by Offerors in replying to this RFP.

1.8.2 Submitting the proposal

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

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

Offerors must submit one electronic copy (in Word, Excel, or a searchable Text-Based PDF file format) of the proposal. Submission of a hard copy is optional. Proposals must be received no later than May 9, 2025 (5:00 P.M. Central Time).

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 otherwise may be deemed irresponsible or unreliable by the State of South Dakota.

All proposals must be signed, either digitally or in ink if a hard copy is submitted, 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. If a hard copy is submitted, the sealed envelope should be marked with the appropriate RFP Number and Title.

Proposals must be addressed and labeled as follows:

REQUEST FOR PROPOSAL # 25RFP14102

PROPOSAL DUE DATE: May 9, 2025 (5:00 P.M. Central Time)

SD DANR, WATER RIGHTS PROGRAM

ATTEN: Ron Duvall

523 E CAPITOL AVE

PIERRE SD 57501

1.9 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 bidder shall attach an explanation to their offer.

1.10 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.11 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 an 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 SDCL 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.

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

1.14 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.15 PROPRIETARY INFORMATION

The proposal of the successful Offeror(s) becomes public information. 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.16 LENGTH OF CONTRACT

The contract will be for two (2) years and the State, in its sole discretion may renew the Agreement under the same terms and conditions for another one-year period.

1.17 GOVERNING LAW AND VENUE

This RFP shall be governed by and construed in accordance with the laws of the State of South Dakota, without regard to any conflicts of law principles, decisional law, or statutory provision which would require or permit the application of another jurisdiction’s substantive law. Venue for any lawsuit pertaining to or affecting this RFP shall be in the Circuit Court, Sixth Judicial Circuit, Hughes County, South Dakota.

1.18 PRESENTATIONS/NEGOTIATIONS

An oral presentation by an Offeror to clarify a proposal may be required at the sole discretion of the State. However, the State may award a contract based on the initial proposals received without discussion with the Offeror. If oral presentations are required, they will be scheduled after the submission of proposals. Oral presentations will be made at the Offeror’s expense.

This process is a Request for Proposal/Competitive Negotiation process. Each Proposal shall be evaluated, and each respondent shall be available for negotiation meetings at the State’s request.

The State reserves the right to negotiate on any and/or all components 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.

1.18 DISCUSSIONS

At the State’s discretion, the Offeror may or may not be invited to have discussions with the State. The discussions can be before or after the RFP has been submitted. Discussions will be made at the offeror’s expense. At the discretion of the State, there will be a Technical Review involving the South Dakota Bureau of Information and Communications (“BIT” hereinafter) relating to the Offeror’s responses to the Security and Vendor Questions.

2.0 STANDARD CONTRACT TERMS AND CONDITIONS

Any contract or agreement resulting from this RFP will include, at a minimum, the substance of the contract terms and conditions as set forth in Appendix A. Pursuant to South Dakota Codified Law 1-33-44, the Bureau of Information and Telecommunications ("BIT" hereinafter), BIT requires the contract also include the provisions which are set forth in Appendix A, Exhibit B (BIT CLAUSES). As part of the negotiation process, the language of a specific term or condition listed in Appendix A could be modified upon agreement between the State and the vendor. Additional terms and conditions may be required. The Offeror should indicate in their response any issues they have with specific contract terms. If the Offeror does not indicate that there are any issues with any contract terms, the State will assume those terms are acceptable to the Offeror.

3.0 SCOPE OF WORK

3.1 Status of existing Microsoft Visual FoxPro data

Water Rights Database. Five tables currently in a one-to-one relationship as free tables, not within a database container:

• prmtinfo.dbf

• admninfo.dbf

• irrginfo.dbf

• wellinfo.dbf

• daminfo.dbf

Each table currently has 16,000 plus records, tables sizes range from 3.2 MB to 46 MB.

The unique identifier to relate the tables is the permit_no field. Even though tables are related one-to-one, much of the content should be in a one-to-many relationship.

Prmtinfo and Admninfo tables each have an affiliated file prmtinfo.FPT and admninfo.FPT “memo” type field. Each record in the five tables will have an associated PDF document which needs to be accessible from within the application. Currently, access to the associated PDF file is through a mapped network path available from the internet.

Some field contents in the above tables contain abbreviations for which lookup tables are used to provide the full name in either reports or in an online version of the database for the public. Lookup tables are as follows: aquifer, aq_mng, mng_unit, basin, county, legal_desc, use_type, status, surface.

Irrigation Water Use Reporting Database. One table, not within a database container:

• Iquest.dbf

This table contains annual water usage reported by irrigators who have a water right which has an associated record in the aforementioned Water Rights Database. The table contains about 4,000 records and the size of the table is about 9 MB. Records in the Iquest.dbf can be related to records in the Water Rights Database via the permit_no field.

Each year’s worth of reported irrigation water use is archived. These archived tables go from present back to 1994 and will need to be included in this database conversion. Each record in the table and archived tables will have an associated PDF document which needs to be accessible from within the application. Currently, access is through a mapped network path available from the internet.

3.2 Status of existing of Microsoft Access data

Nonirrigation Water Use Reporting Data.

• h20use.mdb

This is an Access table with approximately 340 records and serves the same purpose as the Irrigation Water Use Reporting Database except the water uses reporting are for nonirrigation purposes such as municipal, rural water, commercial, industrial, etc. Each record will have an associated PDF containing the reported usage. There are no archived years of data tables, only the reported use in PDF format.

3.3 Data Conversion Overview

The goal is to migrate our existing water rights data into a modern ESRI, GIS-centric database application with basic functionality which will be described in the following sections. It is anticipated there will be an ongoing service agreement for professional services concerning maintenance, possibly hosting, and feature additions as funds allow.

The successful Offeror needs to specify in their quote the price for the completed application to be hosted by the offeror compared with the price for the completed application being hosted by the State. This price comparison needs to identify pros and cons of both solutions and security provisions either required by state or employed by the offeror, or both, if the solution is hosted by the offeror.

3.4 Data Conversion

Water Rights Database. Data needs to be extracted from the FoxPro tables which the State can provide to the Contractor in a generic dbf or xls format. Converted data will need to be modified by the Contractor as needed to create the new ESRI GIS-centric database application including numerous one-to-many relationships that do not currently exist. Records in the database exist into perpetuity and each record has a PDF associated with it that needs to be accessible from the interface. PDFs will NOT be stored within the new database container but will be accessed via a storage location mutually agreed upon by the Offeror and the State. PDF generation of water right files is NOT needed as part of the water rights portion of this project. The new ESRI GIS-centric database application needs the following features with single sign on integration with role-based security to limit editing capabilities to agency staff:

• A user interface so agency staff can enter records into the database and modify existing database entries as needed. The user interface needs to accommodate entry not only of tabular data, but GIS-centric data such as points and polygons.

• The user interface needs to accommodate robust search capabilities, using both tabular content and GIS-based content. The search capabilities are to allow agency staff to, not only find/analyze data, but also allow editing of the search results. As noted, each record in the database will have a PDF document associated with the record that needs to be retrievable within the user interface. A similar web-based search will also be needed to provide the public access, but with no editing capability. No login credentials are needed for public access. The solution will require use of CAPTCHA.

• The capability to output search results into formats, such as XLSX, which can be used for MS WORD mail merges or used in adhoc reports allowing summarizing/grouping of search results. The reporting tool can be PowerBI or similar.

• Direct access to the data from within ArcGIS Pro will be needed to accommodate doing customized searches that may not be available within the user interface. Currently, the State is using ArcGIS Server version 11.3 and ArcPro 3.3.

• Certain records (permits – parent) in the database reserve an amount of water for future use and are subject to review every seven years. Other records (permits) take a specified amount of water out of the reserved water from what could be considered the “parent” permit. A relationship needs to exist between records reserving water (parents), records removing water reserved (children), amount of water remaining, and prompt to conduct a seven-year review needs to be part of the solution. The records all currently exist in the Water Rights database but the existing inventory of permits removing water, the amount of water removed, the amount of water remaining, and seven-year review has been tracked by hand.

Irrigation Water Use Reporting Database. Data needs to be extracted from the FoxPro tables which the State can provide to the Contractor in a generic dbf or xls format.

Records in this dataset contain annual reported water usage for records housed in the Water Rights Database described above. There is no GIS-related data in this dataset, GIS-related information is housed with the Water Rights Database with the permit number field serving as the key field to relate the datasets. Annual collection of water use reporting is via two means, a mailing with blank water use reporting forms and online via a web-based interface using a third-party vendor called Caspio. The intent is to continue using Caspio to collect data online. Data collected within Caspio is currently downloaded and imported into FoxPro using automated tasks running on a scheduled basis. Caspio does support “web hooks” allowing a data connection between Caspio and another dataset. It is anticipated that web hooks will be the interface used to connect Caspio to the dataset being developed by the successful vendor. Implementation of the web hooks with the vendor developed application will be the responsibility of the vendor.

Records in the database exist into perpetuity and each year’s collected data will need to be archived and accessible from with the developed application. In addition, each record for each year, has a PDF associated with it that needs to be accessible from the user interface. PDFs will NOT be stored within the new database container but will be accessed via a storage location mutually agreed upon by the Offeror and the State. The new database application needs the following features with single sign on integration with role-based security to limit editing capabilities to agency staff:

• A user interface so agency staff can enter records into the database and modify existing database entries as needed. The user interface needs to accommodate entry of tabular data. This includes the ability to enter historical data not currently in digital format. A few additional fields may be needed such as a contact person/renter name, address, etc. for reporting annual water use

• This database interface needs a connection to the user interface developed for the Water Rights database so edits can also be made in the Water Rights Database.

• The user interface needs to accommodate robust search capabilities, using both tabular content and GIS-based content available in the Water Rights database. For example, search by an aquifer name and return all historical reported usage for that water source. The search capabilities are to allow agency staff to, not only find/analyze data, but also allow editing of the search results. As noted, each record in the database will have a PDF document associated with the record for each year of reported usage that needs to be retrievable within the interface.

• Beginning-of-the-reporting year.

o Archive previous year’s water use reporting, then clear data entered from previous year to provide clean database for current year water use reporting.

o Generate a temporary password stored in the application to provide the persons reporting annual water use.

o Upload dataset to Caspio in preparation to receive online data entry via the Caspio application.

o Generate a reporting form, saved as a PDF, populated with information from the database related to that particular record, (e.g. permit no, name address, water source(s), temporary password, irrigated area). The PDFs will be printed to complete a mailing to permit holders needing to report water usage. A cover letter will also need to be generated, saved as a PDF, and accompany the paper reporting forms. Exporting the data for the cover letter as an XLSX file for merging with MS Word is an acceptable option.

Examples of the cover letter and paper reporting forms are available upon request.

o After the initial mailing, ad hoc reporting forms may need to be generated to send to as needed to anyone not receiving or misplacing the initial mailing.

• Mid-year.

o A second cover letter/notice (one of three versions) needs to be generated, saved as a PDF, and mailed to permit holders who have failed to report water use. Again, an export of the cover letter data as an XLSX file for a MS Word merge is an acceptable option. Blank reporting forms will also need to be generated to this mailing.

• End-of-the-reporting year.

o PDF generation for each record showing the reported water use data is needed as part of this project with each PDF named by permit number and year of reporting, e.g.

5432-3_2024.pdf. Regeneration of these PDFs should occur whenever the record is edited/updated during the reporting year.

o Three summary reports of all reported data need to be generated with the ability to save the generated reports as PDF documents for archival purposes. Examples of the generated summary reports is available upon request.

o Archival of the data which will be accessible from within the developed application.

Non-irrigation Water Use Reporting Database. Each record in this application will reference at least one reported volume of water pumped for the calendar year. Most records will contain only one reported volume of water used although some may have multiple volumes for the same water permit/right record. A permit holder may also need to report for several water permits/rights that they hold. Like the irrigation water use reporting application, this application will need to be connected to the water rights database. Annual collection of water use data has historically only been collected by mail, phone, or email. There has been no online collection. However, use of Caspio, as with the irrigation reporting, will be required with use of web hooks to sync data collected with the application being developed. The Caspio application will be developed after the structure of the new application is in place. It is anticipated that web hooks will be the interface used to connect Caspio to the dataset being developed by the successful vendor. Implementation of the web hooks with the vendor developed application will be the responsibility of the vendor. Records in the database exist into perpetuity and each year’s collected data will need to be archived and accessible from with the developed application. In addition, each record for each year, has a PDF associated with it that needs to be accessible from the user interface. PDFs will NOT be stored within the new database container but will be accessed via a storage location mutually agreed upon by the Offeror and the State. The new database application needs the following features with single sign on integration with role-based security to limit editing capabilities to agency staff:

• A user interface so agency staff can enter records into the database and modify existing database entries as needed. The user interface needs to accommodate entry of tabular data.

• This database interface needs a connection to the user interface developed for the Water Rights database so edits can also be made in the Water Rights Database.

• The user interface needs to accommodate robust search capabilities, using both tabular content and GIS-based content available in the Water Rights database. The search capabilities are to allow agency staff to, not only find/analyze data, but also allow editing of the search results. As noted, each record in the database will have a PDF document associated with the record for each year of reported usage that needs to be retrievable within the user interface.

• Beginning-of-the-reporting year.

o Archive previous year’s water use reporting, then clear data entered from previous year to provide clean database for current year water use reporting.

o Generate a temporary password stored in the application to provide the persons reporting annual water use.

o Upload dataset to Caspio in preparation to receive online data entry via the Caspio application.

o Generate a reporting form, saved as a PDF, populated with information from the database related to that particular record, (e.g. permit no, name address, water source(s), temporary password, irrigated area). The PDFs will be printed to complete a mailing to permit holders needing to report water usage. A cover letter will also need to be generated, saved as a PDF, and accompany the paper reporting forms. Exporting the data for the cover letter as an XLSX file for merging with MS Word is an acceptable option.

Examples of the cover letter is available upon request.

o After the initial mailing, ad hoc reporting forms may need to be generated to send to as needed to anyone not receiving or misplacing the initial mailing.

• Mid-year.

o A second cover letter/notice (one of three versions) needs to be generated, saved as a PDF, and mailed to permit holders who have failed to report water use. Again, an export of the cover letter data as an XLSX file for a MS Word merge is an acceptable option. Blank reporting forms will also need to be generated to this mailing.

• End-of-the-reporting year.

o PDF generation for each record showing the reported water use data is needed as part of this project with each PDF named by permit number and year of reporting, e.g.

5432-3_2024.pdf. Regeneration of these PDFs should occur whenever the record is edited/updated during the reporting year.

o Three summary reports of all reported data need to be generated with the ability to save the generated reports as PDF documents for archival purposes. Examples of the generated summary reports is available upon request.

o Archival of the data which will be accessible from within the developed application.

3.5. Non-functional requirements

3.5.1 User Experience

The Solution must provide a user experience that is simple, intuitive, and effective. It is expected that the user experience will, at minimum, allow for effective processing of work tasks and intuitive solution navigation that limits the number of clicks or touches required to accomplish work tasks.

3.5.2 Solution Access and Supported Browsers

The Solution must only require internet browser software for users to access it. All State of South Dakota web sites and software will be developed using technology that is compatible with all popular, modern web browsers. No site or application will be created using proprietary features available to the visitor only when using a certain brand of web browser.

3.5.3 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:

For public/citizens (Azure B2C):

• https://docs.microsoft.com/en-us/azure/active-directory-b2c/

• https://docs.microsoft.com/en-us/azure/active-directory-b2c/integrate-with-app-code-samples

For state employees, businesses, partners, providers, etc. (EntraID, formally Azure Active Directory)

• https://learn.microsoft.com/en-us/azure/active-directory/architecture/auth-oauth2

• https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-protocols-oidc.

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

3.5.4 SSO Logout Initiation

https://learn.microsoft.com/en-us/azure/active-directory/architecture/auth-oauth2

• Users must be able to initiate a logout from any SSO-protected application. A clear and easily accessible logout mechanism (e.g., a "Logout" button/link) must be provided within each application's user interface.

• Initiating a logout from any SSO-protected application must trigger a session-based logout process utilizing the sign-out endpoint found in the metadata document provided during implementation.

3.5.5 Session Timeout

• Inactive user sessions must automatically time out after a state-defined period. This timeout period may be adjusted for specific applications based on risk assessment and business requirements, with approval from BIT.

• Users must be notified of impending session expiration 5 minutes before the timeout occurs, providing them with the option to extend their session.

3.5.6 Session Termination on Browser Close

• Closing the browser window or tab must not be considered a valid logout. While the browser session might end, the SSO session may remain active. Users are responsible for explicitly logging out to ensure complete session termination. Clear communication regarding this behavior should be provided to users.

3.5.7 Onboarding/Provisioning Users

• The offeror shall provide an automated process for onboarding and offboarding users in the system using an external identity provider.

• If an automated process is not available, the vendor shall detail the process for onboarding and offboarding users that requires minimal manual steps.

• Vendor shall provide an Identity/SSO/Login Design Document which illustrates all interactions between the system, its components and an external identity provider.

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

3.5.9 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. All components, tools and products that the solution utilizes to meet the RFP requirements should be depicted.

3.5.10 Office Automation Integration

SDDANR has standardized on Microsoft Office suite products (Word, Excel, PowerPoint, etc.) and Adobe. The Solution must be compatible with these products to support, at a minimum, documents as attachments, automated generation of documents (e.g., PDF reports, XLSX spreadsheet, MS Word documents), and cut/paste of text into the Solution’s text fields.

3.5.11 Accessibility Requirements

Websites that are not open to the public must be secured by user login, which can be managed based on role configurations. Websites should be Americans with Disabilities Act (ADA) compliant.

3.5.12 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, illustrating the proposed solution's data provision mechanism.

3.5.13 Disaster Recovery Plan

The Contractor will have a disaster recovery plan for the Solution. This plan will document the sequence of events to follow in the circumstance that an internal or external interruption impacts services provided to the solution user community that may arise because of failure of one or more components that comprise the Solution’s infrastructure, hardware, software, interfaces, networks, Contractor’s data center facility, or power. This plan will be developed in consultation with SDDANR and in adherence with the State of South Dakota Information Technology Security policies, which include Disaster Recovery standards for the State. The Contractor will provide validation reports of disaster recovery tests successes or failures on an annual basis.

The activities of the disaster recovery plan are intended to reduce or minimize downtime of critical equipment, interruption of employee work schedules, and financial exposures for SDDANR and the Contractor. This plan will also document a sequence of communication events to follow during an internal or external infrastructure failure or natural disaster (act of nature).

3.6. Solution Implementation Requirements

3.6.1 Implementation Approach

SDDANR does not have a specific implementation schedule and is leaving the implementation schedule flexible to enable Proposers to provide the most effective and efficient implementation schedule for their proposed Solution, including a potential phased approach for implementation of functional requirements.

Offerors must provide details of their implementation approach in their project implementation plan. All proposal responses should be based on this implementation approach, including the project implementation plan. The project implementation plan will require SDDANR approval before beginning.

3.6.2 State Project Support

SDDANR and SDBIT (SDBIT level of support dependent on whether the Solution is hosted locally or by the Contractor) are committed to the success of this project and will provide staffing resources as appropriate. To help SDDANR and SDBIT better plan to have the right resources available in the right quantities at the right time, the Offeror must provide a state project support plan in their response. SDDANR and SDBIT understand that its participation is critical to ensure the goals of the project are accomplished;

therefore, advanced notice of the expected SDDANR and SDBIT resource support required is beneficial. This should include the roles (Project Manager, architect, DBA, etc.) and amount of recommended effort during specific timeframes.

3.6.3 Training

The Contractor will be responsible for providing adequate training to ensure SDDANR’s staff are properly trained to utilize the implemented Solution and access GIS-related features directly from within ArcGIS Pro. It is expected that the Contractor will develop and conduct training of Water Rights Program staff and BIT staff, if pertinent, at an appropriate time during implementation:

o SDDANR End Users: The Contractor must at a minimum provide onsite, instructor-led, computer-based, hands-on solution functionality training to key users who will be trained in a train-the-trainer approach, being thorough enough to enable those who are trained to then train and support other staff as needed.

o Key Technical Resources: The Contractor will provide a technical diagram/schematic of the Solution documenting the content of and relationships between data and location of data. It is also expected that the Contractor will provide SDDANR with documentation/help menu of the Solution sufficient for SDDANR staff to implement the Solution and refer to for training purposes.

The Offeror must provide a training plan in their response that at minimum identifies the approach and method of training recommended for the various users of the Solution.

3.6.4 Testing

Testing activities will check all aspects of the Solution, including but not limited to its functionality, performance, integration, and the conversion/migration of relevant data.

The Contractor is responsible for all unit, Solution, performance, and regression testing of the Solution and Solution-related changes. Such changes must not be introduced into a production environment until they have been through a complete test cycle and approved by SDDANR after successful user acceptance testing (UAT). Test conditions and test scenarios to be included in the Solution’s testing will be mutually agreed upon by the Contractor and SDDANR. These scenarios will be based on an analysis of the requirements, changes, and modifications that are approved for implementation.

SDDANR will be responsible for UAT execution while the Contractor will be responsible for test scenarios with SDDANR input and management and tracking of UAT activities. UAT verifies the usability of the new processes and ensures that the Solution meets the requirements and the needs of the organization and the end user. The Contractor must provide all support necessary for SDDANR to successfully conduct UAT. A key objective of UAT is to facilitate an understanding of the technology and the business change being implemented.

The Contractor must also provide all support necessary for SDBIT to conduct security testing as per SDBIT requirements.

The Contractor must remedy all bugs/defects discovered during testing in a timely manner and maintain a bug/fix tracking report that clearly identifies each bug detected in testing, the status of the resolution, and the projected fix/resolution date. The Contractor must also provide additional testing steps if needed as part of the bug fix/resolution.

3.6.5 Post-Implementation & Ongoing Support

Offerors must provide details for any on-going maintenance services provided following implementation of the Solution. Offerors should provide details of the following:

o Post-implementation support to ensure the Solution is implemented and running in a stable manner without major flaws following implementation.

o On-going maintenance/service agreement terms and costs, including costs associated with Offeror hosting the Solution.

o Regarding Solution upgrade/update support. SDDANR is interested in learning Offeror’s approach for incorporating agency feedback on proposed updates, enhancements, etc. to the Offeror’s Solution and associated costs with further development.

4.0 PROPOSAL REQUIREMENTS AND COMPANY QUALIFICATIONS

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

4.2 Provide the following information related to at least three previous and current service/contracts, performed by the Offeror’s organization, which are the most similar to the requirements of this RFP.

a. Name, address and telephone number of client/contracting agency and a representative of that agency who may be contacted for verification of all information submitted.

b. Dates of the service/contract.

c. A brief, written description of the specific prior services performed and requirements thereof.

4.3 Provide the following information:

4.3.1 Specialized expertise, capabilities, and technical competence as demonstrated by the proposed approach and methodology to meet the project requirements.

4.3.2 Resources available to perform the work, including any specialized services, within the specified time limits for the project.

4.3.3 Record of past performance, including price and cost data from previous projects, quality of work, ability to meet schedules, cost control, and contract administration.

4.3.4 Ability and proven history in handling special project constraints.

4.3.5 Proposed project management techniques.

4.3.6 Availability to the project locale.

4.3.6 Familiarity with the project locale.

4.4 Project Deliverables/Approach/Methodology

4.4.1 General Provisions

4.4.1.1 The Offeror must 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.

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

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

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

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

4.4.1.6 Include in your submission details on your:

• Data loss prevention methodology.

• 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.1.7 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.

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

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