RFP 25-03_Exhibit 2_Statement of Work.pdf

RFP 25-03

Low-Code Application Development Services

Exhibit 2: Statement of Work 1 of 10

Exhibit 2: Statement of Work This Statement of Work (“SOW”) defines the responsibilities of the Contractor in support of the Department’s initiative to develop and implement a suite of low-code business applications using Microsoft Power Platform technologies, including PowerApps and Dataverse. The goal is to deliver a secure, modernized system that streamlines internal operations, facilitates regulatory compliance, and improves engagement with external citrus fruit dealers.

1. SOLUTIONS REQUIRED

The Contractor shall assist with the design, and shall directly configure, test, and deploy an integrated application ecosystem consisting of the following core solutions:

1. Administration Application – An internal-facing application for system administrators to manage users, roles, accounts, contacts, and key reference data such as assessment and conversion rates.

2. Data Warehouse – An internal-facing data solution which ingests Florida PALM interfaces (12 interfaces) data for use in the other Applications.

3. Dealer Portal – An external-facing web application that allows fruit dealers to manage their business information, submit regulatory forms, and indicate payment methods for outstanding revenues owed to the Department.

4. Mail Application – An internal-facing application used by mail processors to search, create, and manage physical check records and generate daily processing reports.

5. Revenue Application – A back-office application that enables revenue processors to define accounting strings, create and reconcile deposits, associate payments made in the Dealer Portal to deposits, manage receivables, and process multiple revenue streams.

6. Reporting Solution – An internal analytics tool that provides users with access to standard and ad-hoc reports for operational and financial insights.

The Contractor is responsible for delivering a complete, production-ready solution that meets the Department’s business and technical requirements, adheres to best practices in Power Platform development, and complies with relevant data governance standards.

2. AGILE DEVELOPMENT METHODOLOGY

The Contractor and the Department shall collaboratively develop the solutions described in this SOW using an Agile development methodology designed to promote transparency, adaptability, and incremental delivery of business value. Both parties acknowledge that successful execution depends upon active participation, timely communication, and clearly defined roles and responsibilities.

2.1.1 Work Locations and Environment

All work performed under this SOW shall be conducted remotely (i.e. not at the Department’s facilities) unless otherwise agreed in writing by the Department. The Contractor shall provide its own facilities, equipment, and personnel necessary to perform the services described herein. The Department and Contractor agree that for mutual benefit, in-person meetings may be scheduled, but none are required under this SOW. Any such meetings shall be agreed mutually in writing, and the costs associated with travel and lodging remain the responsibilities of the respective Parties.

Exhibit 2: Statement of Work 2 of 10

2.1.2 Location of Work Product

Notwithstanding the remote nature of the engagement, all development, configuration, testing, and deployment activities shall be performed within the Department’s Microsoft Tenant and associated environments, including Development, Test, and Production Power Platform and Azure Synapse environments, Azure DevOps, PowerBI Workspaces, and SharePoint as provisioned and governed by the Department. The Contractor shall not develop, host, or maintain solution components within a separate tenant or environment for purposes of fulfilling contractual deliverables, except for temporary prototyping or demonstration activities expressly prior authorized in writing by the Department.

2.1.3 Access and Security

Access to the Department’s Microsoft environments shall be provisioned in accordance with Department security policies and role-based access controls. The Contractor shall comply with all Department security, governance, and environment management standards, including coordination with the Department’s Managed Services vendor for solution promotion and release management activities.

Nothing in this SOW relieves the Contractor of responsibility for safeguarding Department data, complying with applicable security requirements, or ensuring that all work products remain the property of the Department as defined elsewhere in this SOW.

Both parties further acknowledge that changes to scope, priorities, or requirements may occur as part of the Agile process. Such changes shall be managed through Product Backlog updates, Sprint planning, and mutually agreed written adjustments as appropriate.

2.1.4 Initial Development Schedule

All development activities under this SOW shall be performed using an iterative delivery approach consisting of two-week Sprints. The Department anticipates that principal development work required to deliver the core system capabilities described in this SOW will be completed within eight (8) Sprints, equivalent to approximately sixteen (16) weeks of development effort. This estimate reflects the expected duration for delivery of the primary solution components but does not constitute a guarantee of completion unless the defined scope remains unchanged and all dependencies, inputs, and approvals are provided in a timely manner.

2.1.5 Optional Sprints

At the Department’s discretion, the Department may authorize up to eight (8) additional optional Sprints to extend system capabilities, implement enhancements, address newly identified requirements, or perform additional development within or related to the existing solution scope. These Optional Sprints shall be initiated only upon written authorization from the Department and shall follow the same Agile delivery structure, roles, responsibilities, and acceptance processes defined in this SOW.

Optional Sprints may be used for purposes including, but not limited to, functional expansion, usability improvements, reporting enhancements, integration work, performance optimization, or technical refinements. The scope, objectives, and priorities for each optional Sprint shall be defined through the Department’s Sprint Charter process.

Authorization of optional Sprints does not obligate the Department to utilize the full allotment under the Contract. If ordered, the Optional Sprints shall commence within 2 weeks of the initial deployment period to ensure continuity of the Contractor’s Delivery Team. The Department reserves the right to

Exhibit 2: Statement of Work 3 of 10 activate any number of optional Sprints, from zero up to the maximum allowed, based on program needs, funding availability, and delivery outcomes.

2.2 Work Items

Work performed under this SOW shall be organized, tracked, and managed using a structured hierarchy of Work Items to ensure traceability from high-level business objectives to individual development tasks.

Work Item is the smallest unit of planned, trackable effort within the Agile delivery framework. It represents a defined piece of functional, technical, or corrective work that can be estimated, assigned, executed, and validated within a Sprint, and is recorded in Azure DevOps for purposes of traceability, status tracking, and alignment to higher-level Features and Epics.

All Work Items shall be maintained in the Department-provided Azure DevOps system, which shall serve as the system of record for planning, execution, status tracking, and reporting.

2.2.1 Work Item Hierarchy

Work Items shall be structured using the following hierarchy:

• Epics – Epics represent major business capabilities, solution domains, or program-level objectives that span multiple Sprints. Epics define broad functional outcomes aligned to Department goals and may encompass multiple Features and subordinate Work Items. For this SOW, Epics will represent major capabilities or whole solutions within the environment.

• Features – Features represent discrete functional components or service capabilities that deliver measurable business value and contribute to completion of an Epic. A Feature may require multiple Sprints to complete and shall be decomposed into smaller executable work items prior to Sprint commitment.

• Work Items – Work Items represent the smallest unit of planned and trackable effort that can be completed within a Sprint. Work Items shall be sufficiently detailed to allow estimation, assignment, implementation, and validation.

Each Work Item shall be traceable to a parent Feature and Epic where applicable, ensuring full alignment between Sprint-level execution and Department business objectives.

2.2.2 Types of Work Items

Work Items may consist of several categories, including but not limited to the following:

• User Stories – Functional requirements expressed from the perspective of an end user or system actor, describing desired capability and business value. User Stories shall include acceptance criteria and shall be the primary mechanism for delivering functional solution components.

• Technical Work Items – Tasks necessary to support system architecture, configuration, integrations, data structures, security setup, environment configuration, performance optimization, or other technical implementation activities that may not directly represent user-facing functionality but are required for successful delivery.

• Defects – Documented issues or errors identified during development, testing, or review that must be corrected to meet requirements or acceptance criteria.

Exhibit 2: Statement of Work 4 of 10

• Spikes or Research – Time-boxed investigative or exploratory work performed to reduce uncertainty, evaluate design options, or determine technical feasibility. Outcomes of such items shall be documented and used to inform subsequent Backlog Refinement.

• Operational or Support – Activities required to support deployment, release management, data migration, or environment coordination that contribute to overall solution readiness.

2.3 Agile Artifacts

For purposes of this SOW, the following Agile artifacts shall be maintained to provide transparency, traceability, and structured management of work performed under this engagement. All artifacts shall be maintained within the Department-provided Azure DevOps and associated SharePoint environment unless otherwise agreed in writing. These artifacts collectively establish the framework for planning, executing, monitoring, and accepting work under this SOW and shall serve as the official record of Agile delivery activities for the engagement.

2.3.1 Product Backlog

The authoritative, prioritized list of Work Items maintained in the Department-provided Azure DevOps system required to deliver the overall solutions. The Product Backlog shall be owned and prioritized by the Department Product Owner. The Contractor shall provide effort estimates, technical input, and dependency analysis to support prioritization and readiness of all Work Items.

2.3.2 Sprint Charter

A written document provided by the Department at the start of each Sprint that defines the Sprint objectives, scope, priorities, and success criteria. The Sprint Charter shall serve as the formal authorization to proceed with the work for that Sprint and shall guide establishment of the Sprint Backlog.

2.3.3 Sprint Backlog

The subset of Product Backlog items selected for implementation during a specific Sprint, together with the associated technical tasks required to complete them. The Sprint Backlog shall be maintained by the Contractor and reflect the work committed to for the duration of the Sprint.

2.3.4 Increment

The working, potentially deployable functionality completed during a Sprint that meets agreed acceptance criteria and the Definition of Done. Each Increment shall be demonstrated during the Sprint Review.

2.3.5 Definition of Ready

The mutually agreed standard that a Product Backlog item must meet before it may be selected for inclusion in a Sprint Backlog. The purpose of the Definition of Ready is to ensure that work items are sufficiently defined, understood, and actionable so that the Development Team can execute them within a Sprint without undue ambiguity or rework.

A Product Backlog item shall be considered “Ready” when, at a minimum:

• The business objective and expected outcome are clearly described.

• Functional requirements and acceptance criteria are documented and testable.

• Dependencies, assumptions, and constraints are identified.

Exhibit 2: Statement of Work 5 of 10

• Required data elements, integrations, and security considerations are known.

• The item has been reviewed with the Development Team and reasonably estimated.

• The Department Product Owner has prioritized the item for upcoming delivery.

Only Product Backlog items that meet the Definition of Ready may be included in a Sprint Charter and committed to a Sprint Backlog during Sprint Planning, unless both parties explicitly agree to include exploratory or discovery work. The Definition of Ready does not guarantee completion within a Sprint;

rather, it establishes a shared baseline of clarity and preparedness necessary for effective Sprint execution.

2.3.6 Definition of Done

The mutually agreed standard that determines when a Product Backlog item or Increment is considered complete. The Definition of Done shall include, at a minimum, successful configuration or development, testing, documentation as required, and readiness for demonstration and acceptance. Prior to the beginning of the first Sprint, the Contractor shall propose, and the Department shall accept, a Definition of Done for all work items.

2.3.7 Burndown or Progress Tracking Metrics

Visual or quantitative tracking tools maintained within Azure DevOps to reflect Sprint progress, remaining work, and overall delivery status.

2.4 Agile Ceremonies

For purposes of this SOW, the following Agile Ceremonies shall govern the execution of work. These Ceremonies shall constitute the standard operating framework for iterative delivery under this SOW.

Adjustments to ceremony format or frequency may be made only by mutual agreement of the Department and the Contractor and shall be documented in writing. These ceremonies are intended to ensure transparency, alignment, continuous feedback, and incremental delivery of working functionality. Both parties shall participate in standard Agile ceremonies, including Sprint planning activities, Daily Standups, Sprint Reviews, and Backlog Refinement sessions, to ensure alignment, visibility, and continuous improvement. Agile Ceremonies will be conducted remotely via Microsoft Teams. The Contractor and the Department agree to participate in these ceremonies as described below:

2.4.1 Sprint Planning

Conducted at the beginning of each two-week Sprint to confirm Sprint objectives, review the Department-provided Sprint Charter, establish the Sprint Goal, and finalize the Sprint Backlog. The Department Product Owner shall clarify requirements and priorities, and the Contractor shall provide effort estimates and confirm feasibility.

2.4.2 Daily Standup

A brief daily meeting facilitated by the Contractor’s Delivery Manager during which the Development Team reviews progress, identifies impediments, and coordinates work. The Department may attend for visibility and coordination purposes but is not required unless participation is needed to resolve questions or blockers.

Exhibit 2: Statement of Work 6 of 10

2.4.3 Backlog Refinement

Conducted periodically, as needed, to review, clarify, estimate, and prioritize upcoming Product Backlog items. The Department Product Owner shall lead prioritization, and the Contractor shall provide technical input, sizing, and dependency identification to ensure items are ready for future Sprint Planning.

2.4.4 Sprint Review

Held at the conclusion of each Sprint to demonstrate completed functionality and confirm alignment with Sprint objectives and acceptance criteria. The Contractor shall present working software, and the Department shall review deliverables, provide feedback, and determine acceptance of completed work.

2.4.5 Sprint Retrospective

Conducted after each Sprint Review to evaluate team performance, processes, collaboration, and opportunities for improvement. The Contractor’s Delivery Manager shall facilitate this session, and both parties shall participate in good faith to promote continuous improvement.

3. DEPARTMENT RESPONSIBILITIES

The responsibilities of the Department described in this section establish the governance, decision-making authority, and operational support necessary for successful execution of this engagement. The Department’s role is to provide timely direction, business context, prioritization, and validation to ensure that the solution being developed aligns with statutory obligations, operational needs, and program objectives. Active participation by the Department is essential to enable iterative delivery, informed decision-making, and acceptance of completed work throughout the Agile development lifecycle.

The Department shall fulfill the responsibilities set forth below in a timely and collaborative manner so as not to delay or impede the Contractor’s performance. These responsibilities do not transfer accountability for technical execution or delivery of the solution from the Contractor to the Department, but rather define the Department’s role as business owner, product authority, and governance body for the system being developed.

3.1 Department Personnel

The Department will assign qualified personnel to fulfill the roles and responsibilities described in this SOW. The Department acknowledges that active engagement by designated personnel is essential to the success of the Agile delivery model and to ensure that the solution meets statutory, operational, and regulatory requirements.

Department personnel will participate in required Agile ceremonies, provide timely clarification of requirements, review and validate deliverables, and render decisions necessary to maintain delivery momentum. The Department will ensure continuity of key roles, including the Product Owner and designated subject matter experts, and will promptly communicate any personnel changes that may impact project governance or delivery timelines.

3.1.1 Product Owner

The Department will designate a Product Owner who will serve as the primary authority for defining business requirements, prioritizing work, clarifying functionality, and accepting completed deliverables.

Exhibit 2: Statement of Work 7 of 10

The Product Owner shall maintain and prioritize the Product Backlog and provide timely decisions, feedback, and approvals necessary to support development progress.

3.1.2 Subject Matter Experts

The Department will ensure availability of appropriate subject matter experts and stakeholders as needed to support requirements clarification, testing, validation, and review activities.

3.1.3 Managed Services Vendor

The Department maintains a Managed Services vendor that provides administrative oversight and quality assurance functions for applications deployed within the Department’s Microsoft Power Platform environments. The Managed Services vendor shall serve as the environment administrator and quality assurance authority responsible for governing the promotion of solution components through the Development, Test, and Production environments in accordance with the Department’s established release management procedures.

The Contractor shall coordinate with the Department’s Managed Services vendor for environment access, solution deployment approvals, configuration validation, and quality assurance reviews. The Managed Services vendor shall be responsible for administering environment controls, managing deployment pipelines or promotion workflows, and ensuring compliance with Department standards for security, performance, and configuration management prior to advancement into Test or Production environments.

3.2 Agile Artifacts

3.2.1 Sprint Charter

As part of the Backlog Refinement process, the Department’s Product Owner will develop and provide a Sprint Charter prior to the start of each Sprint to the Contractor that establishes the Sprint objectives and defines the work items to be undertaken. The Sprint Charter

Prior to the start of each Sprint, the Department will provide a Sprint Charter that defines the scope, objectives, priorities, and success criteria for that Sprint. The Sprint Charter shall serve as the authoritative basis for establishing the Sprint Backlog.

3.2.2 Sprint Acceptance

At the conclusion of each Sprint, the Contractor shall present completed work to the Department during the Sprint Review for evaluation and feedback. The purpose of Sprint Acceptance is to provide the Department’s Product Owner with a structured opportunity to review delivered functionality, confirm alignment with Sprint objectives and acceptance criteria, and formally indicate whether presented work is accepted.

Following demonstration of Sprint deliverables, the Product Owner shall review completed items against the Sprint Charter, defined requirements, and agreed Definition of Done. The Product Owner may, within a reasonable period following the Sprint Review, provide one of the following determinations for each completed work item:

• Accepted – The deliverable meets agreed requirements and is approved as complete.

• Accepted with Comments – The deliverable is approved but includes minor feedback or non-blocking observations that may be addressed in a future Sprint or backlog item.

Exhibit 2: Statement of Work 8 of 10

• Not Accepted – The deliverable does not meet agreed requirements or acceptance criteria and must be revised or completed in a subsequent Sprint.

The Product Owner shall document acceptance decisions and feedback within the Department-provided Azure DevOps system, which shall serve as the official record of Sprint Acceptance. Feedback shall be sufficiently detailed to enable the Contractor to understand any required adjustments or remaining work.

Failure of the Department to provide acceptance determination or feedback within the agreed review period shall not constitute automatic acceptance unless otherwise specified in writing. Likewise, Sprint Acceptance shall not be unreasonably withheld when delivered functionality conforms to the defined requirements and acceptance criteria.

3.3 Azure DevOps

The Department shall provide and maintain access to the Azure DevOps platform to be used as the authoritative system for work planning, backlog management, Sprint tracking, and related project coordination activities. The Contractor shall utilize this system for all planning, task tracking, and work status updates associated with this engagement.

Nothing in this SOW shall be interpreted to transfer responsibility for business decisions, requirement definitions, or acceptance authority from the Department to the Contractor.

4. CONTRACTOR RESPONSIBILITIES

The Contractor shall be responsible for executing work defined in each Sprint Charter and Sprint Backlog in accordance with Agile best practices and within the established Sprint timeframe. The Contractor shall manage Sprint execution activities, including maintaining the Sprint Backlog, tracking progress, identifying risks or impediments, and communicating status to the Department through the Department-provided Azure DevOps platform.

4.1 Delivery Team

The Contractor shall provide a qualified Delivery Team consisting of a designated Delivery Manager and Development Team with the technical, functional, and delivery expertise necessary to design, configure, build, test, and deploy the solutions.

4.1.1 Delivery Manager

The Contractor shall designate a Delivery Manager who will be responsible for facilitating Agile delivery practices and ensuring adherence to Agile principles throughout the duration of this engagement. The Delivery Manager shall act as the primary facilitator for Agile ceremonies, including Sprint Planning, Daily Standups, Sprint Reviews, and Sprint Retrospectives, and shall support effective collaboration between the Contractor’s Development Team and the Department.

The Delivery Manager shall be responsible for identifying, tracking, and assisting in the resolution of impediments that may affect delivery progress; promoting transparency of work status; reinforcing agreed Agile processes; and ensuring that artifacts, metrics, and reporting within Azure DevOps are accurate and current. The Delivery Manager shall also guide the team in continuous improvement practices and help ensure that Sprint commitments are realistic, achievable, and aligned with Sprint objectives.

Exhibit 2: Statement of Work 9 of 10

The individual assigned to the Delivery Manager role must possess a current, recognized Agile certification (such as Certified ScrumMaster (CSM), Professional Agile Master (PSM), PMI Agile Certified Practitioner (PM-ACP) or equivalent industry-recognized credential) and shall demonstrate prior experience facilitating Agile delivery for enterprise application development projects of comparable size and complexity.

4.1.2 Development Team

The Contractor shall provide a qualified Development Team responsible for designing, configuring, developing, testing, and delivering the solution components defined in each Sprint Charter and Sprint Backlog. The Development Team shall consist of personnel with appropriate expertise in Microsoft Power Platform technologies, including but not limited to PowerApps, Dataverse, integrations, security configuration, and reporting components.

The Development Team shall be self-organizing with respect to task execution and technical approach, while remaining accountable for delivering working software increments that meet agreed requirements, acceptance criteria, and the Definition of Done. Team members shall collaborate closely with the Department’s Product Owner to clarify requirements, refine backlog items, and ensure delivered functionality aligns with business needs.

The Development Team shall maintain accurate work tracking, estimates, and status updates within the Department-provided Azure DevOps system, and shall promptly communicate risks, issues, or dependencies that may affect delivery timelines or solution quality.

4.1.3 Agile Ceremonies

The Contractor shall actively participate in Agile ceremonies, including Daily Standups and Sprint Reviews, and shall provide demonstrations of completed functionality for Department feedback and acceptance. The Contractor shall also ensure that all work planning, task tracking, and status updates are maintained within the Department-provided Azure DevOps platform.

5. POST-IMPLEMENTATION SUPPORT

Following deployment of the production solution, the Contractor shall provide ongoing support services to maintain system functionality, reliability, and alignment with evolving operational and technical requirements. Ongoing Support Services shall include break-fix support, minor enhancements, and technology updates, as described below.

5.1 Break-Fix Support

The Contractor shall investigate, diagnose, and resolve defects, errors, or failures identified in the production system that prevent or impair normal operation. Break-fix activities include troubleshooting application behavior, correcting configuration or development defects, restoring functionality, and validating resolution. The Contractor shall respond to reported issues within agreed service response timeframes and shall document issue status, root cause, and resolution in the Department-designated tracking system.

5.2 Minor Enhancements

The Contractor shall implement small-scale improvements, adjustments, or refinements to existing functionality that do not materially alter system architecture or scope. Minor enhancements may

Exhibit 2: Statement of Work 10 of 10 include updates to forms, workflows, business rules, reports, data elements, or user interface components. Such enhancements shall be prioritized by the Department and scheduled through agreed work planning processes.

5.3 Technology Updates

The Contractor shall support ongoing platform maintenance by evaluating and applying updates required to maintain compatibility with Microsoft Power Platform releases, security requirements, and Department standards. This includes reviewing platform changes, updating solution components as needed, validating functionality following updates, and coordinating with the Department and its Managed Services vendor to promote updates through environment workflows.

All Ongoing Support Services shall be performed in coordination with the Department and in accordance with established governance, change management, and deployment procedures. Nothing in this section shall be interpreted to transfer ownership of the system or operational authority from the Department to the Contractor; rather, it establishes the Contractor’s responsibility to provide technical support and maintenance services necessary to sustain the solution’s effective operation.

3.3 Azure DevOps