RFP 25-03

Low-Code Application Development Services

Exhibit 2: Statement of Work 1 of 14

RFP 25-03 Addendum No. 2

The Request for Proposals, RFP 25-03 Low-Code Application Development Services, is hereby amended within this Addendum No. 2 as noted below. All additions and deletions are indicated through highlighting and strikethrough, respectively. In the event of a conflict between previously released information and the information contained herein, the information herein shall control. The information included in this addendum is now made part of this solicitation.

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.

Exhibit 2: Statement of Work 2 of 14

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.

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.

Exhibit 2: Statement of Work 3 of 14

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

Exhibit 2: Statement of Work 4 of 14

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

• 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

Exhibit 2: Statement of Work 5 of 14 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.

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

Exhibit 2: Statement of Work 6 of 14

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.

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

Exhibit 2: Statement of Work 7 of 14 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.

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, Exhibit 2: Statement of Work 8 of 14 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.

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

Exhibit 2: Statement of Work 9 of 14

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.

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 Post-implementation Support Services shall include break-fix support, minor enhancements, and technology updates, as described below.

All Post-implementation 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.

Exhibit 2: Statement of Work 10 of 14

5.1 Break-Fix Support

The Contractor shall investigate, diagnose, and resolve defects, errors, or failures Issues 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 Issues as described below and shall document issue status, root cause, and resolution in and provide this information to the Department-designated tracking system quarterly. Break-fix support shall be provided between the hours of 8:00 AM and 5:00 PM EST/EDT.

5.1.1 Definitions of Break-Fix Terms

For the purposes of this SOW, the following definitions shall apply to Break-Fix Support:

5.1.1.1 Issue

An Issue is any defect, error, malfunction, or unexpected behavior in the system that results in the degradation, interruption, or failure of application functionality, performance, security, or data integrity.

Issues may be identified by end users, system monitoring processes, or support personnel and may include, but are not limited to:

• Application errors or failures

• Incorrect calculations or data processing results

• Integration or interface failures

• User access or permission problems

• Performance degradation or system unavailability

An Issue is considered active from the time it is reported or detected until it is resolved and validated.

5.1.1.2 Impact

For the purposes of Issue prioritization and response, each Issue shall be assigned one of the following four priority levels that reflects both the technical impact of an Issue and the business criticality of resolving it:

• Critical: A Critical Impact Issue represents a complete or near-complete failure of the system or a core business function, with no viable workaround available. The Issue results in immediate and significant disruption to essential operations, regulatory compliance, or time-sensitive processes.

• High: A High Impact Issue represents a significant degradation of system functionality or performance that materially impacts business operations, but where limited workarounds may exist.

• Medium: A Medium Impact Issue represents a partial loss of functionality or performance that affects operations but does not prevent the continuation of core business activities.

• Low: A Low Impact Issue represents a minor defect with little to no impact on system operations or business processes.

5.1.2 Service Levels

The Contractor shall meet the following response and resolution service levels based on the assigned Issue priority. All timeframes are measured during agreed-upon support hours unless otherwise specified. The following definitions apply to Service Levels:

Exhibit 2: Statement of Work 11 of 14

• Response Time: Time from Issue reporting to initial acknowledgment and engagement

• Resolution Time: Time from Issue reporting to full resolution or implementation of an acceptable workaround

• Continuous Effort: Work performed without interruption (including extended hours if necessary) until Issue is resolved or mitigated

Impact Level

Initial Response Time

Target Resolution Time

Escalation Requirement Service Expectation

Critical ≤ 2 business hours

≤ 1 business day Immediate escalation to senior technical and management staff

Continuous effort until resolved; includes after-hours and weekends as required

High ≤ 4 business hours

≤ 2 business days Escalation if not resolved within 1 business day

Prioritized resolution with dedicated resources

Medium ≤ 2 business days

≤ 4 business days Escalation if not resolved within 2 business days

Scheduled resolution within normal support operations

Low ≤ 4 business days

≤ 5–10 business days (or next release cycle)

Escalation upon request by Department

Addressed as part of planned maintenance or Minor Enhancement backlog

5.1.3 Additional Requirements

The following additional requirements apply to the resolution of Issues:

• The Contractor shall provide regular status updates for all Critical and High Issues at intervals agreed upon with the Department.

• The Contractor shall maintain a ticketing system to track all Issues, including status, priority, actions taken, and resolution details.

• The Department reserves the right to reclassify Issue priority levels based on changing operational conditions or business needs.

• Resolution of an Issue may include a temporary workaround, provided that a permanent fix is documented and scheduled.

• The Contractor shall document all root cause analyses for Critical and High Issues and provide recommendations to prevent recurrence.

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 include updates to forms, workflows, business rules, reports, data elements, or user interface

Exhibit 2: Statement of Work 12 of 14 components. Such enhancements shall be prioritized by the Department and scheduled through agreed the work planning processes defined below.

5.2.1 Development Effort

The Contractor shall provide a monthly capacity allocation of up to forty (40) development hours for Minor Enhancements. These hours are strictly limited to actual development, configuration, testing, and deployment activities. Time spent on the following activities shall not count toward the 40-hour monthly development cap:

• Requirements clarification and intake discussions

• Prioritization meetings and backlog grooming

• Technical design discussions and solution planning

• Effort estimation and scoping

• Status meetings and coordination activities

The Contractor is expected to participate in these activities as part of ongoing support and delivery coordination.

5.2.2 Enhancement Intake and Backlog Management

All Minor Enhancement requests will be maintained by the Department in a prioritized enhancement backlog. The Department, in coordination with the Contractor, will review and refine backlog items on a recurring basis to ensure clarity, feasibility, and alignment with operational priorities. The Department retains final authority over prioritization and selection of enhancement work to be performed within the monthly allocation.

5.2.3 Prioritization Levels

Minor Enhancements shall be assigned one of the following priority levels to guide scheduling and execution:

• High: High-priority enhancements are those that provide significant operational value or address time-sensitive business needs.

• Medium: Medium-priority enhancements are those that improve functionality or user experience but are not time-sensitive.

• Low: Low-priority enhancements are those with minimal operational impact and primarily represent optional improvements or future optimizations.

5.2.4 Development Input

The Contractor shall:

• Provide level-of-effort estimates for each enhancement request

• Advise the Department on feasibility, dependencies, and risks

• Execute selected enhancements within the approved monthly hour allocation

• Track and report hours consumed against the 40-hour monthly cap per enhancement

• Carry forward any uncompleted work to subsequent periods, subject to reprioritization

5.2.5 Governance and Flexibility

The Department reserves the right to:

Exhibit 2: Statement of Work 13 of 14

• Reprioritize enhancement work based on operational needs

• Defer or reallocate enhancement efforts across months

• Suspend enhancement work during periods of critical operational activity

• Request bundling of smaller enhancements to maximize efficiency

5.2.6 Scope Exclusion

Enhancements that are determined to exceed the scope of Minor Enhancements (i.e., requiring substantial effort, new feature development, and/or architectural changes) shall be separately scoped, estimated, negotiated, and approved in writing outside of the monthly allocation.

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.

5.3.1 Semi-Annual Review of Microsoft Power Platform Changes

The Contractor shall be responsible for monitoring, evaluating, and advising the Department on updates and changes to the Microsoft Power Platform that may impact system functionality, performance, security, or integration. This responsibility is intended to ensure that the Department’s solution remains current, stable, and aligned with platform capabilities and best practices.

On a semi-annual basis, the Contractor shall conduct a formal review of Microsoft Power Platform releases, including but not limited to:

• PowerApps (Canvas and Model-Driven applications)

• Dataverse

• Power Automate

• Platform governance and administrative features

The purpose of this review is to identify new features, deprecations, behavioral changes, or other platform updates that may affect the Department’s solution(s).

5.3.2 Impact Assessment

Following each semi-annual review, the Contractor shall provide the Department with a written summary of findings, including:

• Identification of relevant platform changes

• Assessment of potential impacts to existing functionality, integrations, security, or performance

• Identification of any required or recommended actions

• Classification of impacts as no impact, potential impact, or material impact

Exhibit 2: Statement of Work 14 of 14

For any identified impacts, the Contractor shall clearly describe the nature of the risk or opportunity and the potential consequences of taking or not taking action.

5.3.3 Testing Plan and Effort Estimation

For any platform update determined to have a potential or material impact, the Contractor shall:

• Develop and submit a testing and validation plan outlining how the impact will be assessed

• Identify affected system components and integration points

• Provide a level-of-effort estimate for testing, validation, and any required remediation

• Recommend a timeline for evaluation and implementation

The Contractor shall coordinate with the Department to prioritize and schedule testing activities in alignment with operational needs and system availability.

5.3.4 Use of Minor Enhancement Capacity

Where feasible, the Contractor shall optimize the implementation of platform-related updates and adjustments within the established Minor Enhancement framework. The Contractor shall:

• Identify opportunities to address platform changes using the monthly Minor Enhancement allocation

• Prioritize such work in coordination with the Department

• Avoid unnecessary escalation to separately billed development efforts when the work can reasonably be accommodated within the existing enhancement capacity

Only when platform changes require effort beyond the scope, capacity, or timeframe of Minor Enhancements shall the Contractor propose separately scoped and priced development efforts, subject to Department approval.

5.3.5 Ongoing Advisory Responsibility

The Contractor shall serve as a technical advisor to the Department regarding platform evolution and shall:

• Proactively communicate emerging risks or opportunities outside of the semi-annual review cycle when necessary

• Recommend adoption of new features that provide measurable value

• Advise on deprecations or changes that may require proactive remediation

• Support the Department in maintaining alignment with Microsoft Power Platform best practices and lifecycle changes

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