Rfi Seed To Sale Implementation

Section VI – Tasks

The Commonwealth intends the base year to establish operational readiness and reduce program risk as quickly as practicable. Offerors shall propose a structured Phase 0 discovery effort (fixed price) resulting in an approved roadmap, followed by execution under one of two possible pathways: (1) replacement/transition to a new platform, or (2) stabilization/hardening of an existing platform. The Commonwealth will determine the applicable pathway post-award.

Implementation Philosophy

The Commonwealth seeks an implementation approach that prioritizes risk reduction, early operational readiness, and disciplined configuration of a configurable Seed-to-Sale solution.

The Department’s objective is not to achieve theoretical completeness prior to production use, but to:

• Establish a stable, compliant, and operationally viable core system;

• Enable an orderly and, if necessary, accelerated transition from the existing seed-to-sale system to the to-be system or harden the existing system for longer term viability;

• Iteratively enhance functionality in a controlled and governed manner that includes testing of working software releases with users, and the incorporation of validated learning into future work.

The selected Offeror shall propose an implementation methodology that reflects these objectives and does not rely on a strictly sequential “waterfall” deployment model, where operational completeness is a predicate to user testing and eventual implementation of the complete system.

Discovery and Implementation Roadmap (Not to Exceed Four Months)

Immediately following contract execution, the selected Offeror shall conduct a structured discovery and alignment phase that will not exceed 4 months.

Objectives of Discovery Phase

The purpose of this phase is to:

1. Validate statutory and regulatory requirements in operational context (input: Appendix G);

2. Conduct a detailed fit/gap analysis against the proposed solution;

3. Identify configuration versus customization requirements;

4. Assess integration dependencies and data migration scope;

5. Evaluate risks associated with the incumbent system;

6. Define minimum viable functionality required for production cutover; and

7. Develop a prioritized, phased implementation roadmap.

Offeror will include, as part of its proposed discovery phase approach, what resources and support it may require of DOH subject matter experts.

Inputs of Discovery Phase

Offeror should consider the following documents in preparation of the Discovery and Implementation Roadmap:

• Appendix A: Current State

• Appendix G: Medical Marijuana Seed-to-Sale System Requirements

• Appendix J: Bolstering Service Delivery

• Appendix K: Medical Marijuana Seed-To-Sale Service Level Agreements (SLAs)

Discovery Phase Deliverables

Within 5 business days of the conclusion of the discovery phase, the Selected Offeror shall deliver:

• A validated Requirements Traceability and Gap Analysis Report, to include an updated Appendix G based on the results of the discovery phase;

• A Configuration Blueprint that describes its approach to the setup and configuration of solution requirements, to include the number of environments, users of the environments, and timing and availability of each environment through Ready for Use (RFU) documentation to be approved by DOH;

• A Data Management Plan and Migration Strategy;

• An Integration Inventory and Interface Plan;

• A Risk Register with mitigation strategies;

• A prioritized Implementation Roadmap or platform hardening and sustainment plan if current system is retained, identifying:

o Critical statutory and operational capabilities;

o In scope and out of scope systems or features;

o Success criteria including key performance indicators;

o Dependencies;

o Estimated effort/resource management, to include the ongoing resources and support that offeror will require from stakeholders and Commonwealth subject matter experts;

o Change management plan;

o Proposed sequencing for conversion & cutover, to include project timeline and Product Backlog of features that are not essential to cutover; and

o Milestone structure demonstrating how offeror will prioritize work in an iterative manner to enable and accelerate system cutover from incumbent.

The Implementation Roadmap must explicitly identify the minimum functionality necessary to enable production cutover from the existing system.

The Discovery Phase deliverables shall establish the approved baseline (fit/gap, configuration blueprint, migration strategy, interface plan, risk register, and roadmap) that will be used to execute and complete the Section VI Tasks and deliverables.

Upon receipt of the final discovery phase deliverables, DOH will have ten business days to review and provide comment. The selected Offeror will complete additional revisions to these deliverables within five business days or as otherwise agreed to in writing by DOH.

Risk Management and Incumbent Transition Planning

The Selected Offeror must:

• Identify transition or current platform risks during discovery;

• Propose contingency plans in the event of current platform instability;

• Define data extraction and conversion sequencing;

• Identify dependencies that may delay cutover; and

• Recommend strategies for parallel operations, if required.

The Implementation Roadmap should include a cutover plan that addresses:

• Data migration sequencing;

• Freeze periods;

• Validation protocols;

• User readiness;

• Technology assets that DOH may require regardless of system or platform provider; and

• Rollback procedures.

System Transition Strategy

The purpose of system transition is to reduce dependency on the existing system as soon as practicable, through the implementation of compliant and functional replacement components. In the event that the current system is retained, this transition strategy will still be required for use in any future system transition.

Accordingly, the Selected Offeror’s roadmap shall:

a. Identify the minimum viable configuration required to meet statutory compliance;

b. Prioritize functionality necessary to support:

o Traceability;

o MMU enforcement;

o Registry validation;

o Inventory controls;

o Testing and quarantine;

o Core reporting; and

o Essential integrations.

c. Sequence non-critical enhancements and optimization work for post-cutover phases wherever possible and practicable.

d. Describe how it will provide a fully configured Test for Production (TFP) environment containing DOH migrated data that adheres to Commonwealth IT policies, security standards, and compliance requirements, to be approved by DOH.

The Offeror will propose a strategy that enables partial operational readiness and testing prior to full system optimization, allowing the Department to:

• Validate essential functionality with real users;

• Conduct controlled pilot testing with internal and external users;

• Execute phased rollouts by entity type or functionality; and

• Accelerate full cutover if operational conditions require.

The Commonwealth may elect to perform phased pilots or parallel operations to reduce risk and accelerate readiness; however, production cutover and final acceptance shall only occur after completion of required testing/UAT and DOH approval.

System Transition Strategy Deliverables

The selected Offeror will propose a Product Management plan that describes how task and activity progress will be reported to Commonwealth stakeholders, to include how the Product Roadmap will be executed.

System Test Plan

The selected Offeror shall manage a continuous testing process throughout the system transition and implementation process, and an ongoing operational testing plan as appropriate for the operations and maintenance phase of remaining contract terms.

The system testing process will require, at a minimum, the following elements:

a. Comprehensive Test Plan: the selected Offeror shall create a test plan that includes, at a minimum, the approach to all types of testing to be performed (including system and user acceptance testing (UAT)) and roles and responsibilities.

b. Test plans shall include the following minimum elements:

o Resources required for testing

o Test scheduling process

o Test mapping of requirements and associated components with associated pass/fail criteria

o Test design cycles and procedures, to include sequencing and dependencies

o Ownership and responsibilities

o A process for DOH sign-off and final approvals of test result findings

c. Development of Test Scenarios: the selected Offeror will develop test scripts and scenarios that reflect all requirements in Appendix G. Scenarios must be approved by DOH before testing will occur. DOH may, at its sole discretion, develop additional test scenarios.

d. System Testing: the selected Offeror shall create a testing log to ensure that tests are performed and that results are made available to DOH for review, feedback, and acceptance.

e. Performance Testing: The selected Offeror shall ensure performance tests are performed and the results are made available to DOH for review, feedback, and acceptance. Elements of performance testing include, but are not limited to, the following:

o Stress and Load Testing: System load tests are expected on an annual basis and before major releases or enhancements. The purpose of stress and load tests is to enable Health and Human Services (HHS) IT Delivery Center to fully understand the performance characteristics of the system under various scenarios and the limits of the system’s performance capabilities and associated failure modes.

o Load Testing: The selected Offeror shall be responsible for writing load scripts.

o Test Strategy and Plan: The selected Offeror shall include business and engineering analyses of the results along with its strategy for stress and load testing.

f. UAT: The selected Offeror shall be responsible and accountable for managing all aspects of UAT, to include planning, execution, and completion. A comprehensive UAT process should be well-documented and effective at validating that system components meet all functional and business needs prior to production deployment. This UAT process should include, but is not limited to, the following elements:

o Providing training for agency testers;

o Provisioning and maintaining all test environments;

o Developing and executing test scenarios;

o Aligning with business requirements;

o Managing all defect tracking and resolution activities; and

o Formal UAT signoff from BMM

g. Test Results: The selected offer will document test results to include defect management reporting and confirmation of errors being retested and resolved. Test result documentation shall include an updated requirements traceability matrix that shows all requirements have been successfully tested.

h. Defect Resolution: The selected Offeror shall be responsible for defect resolution such that any errors, defects, or unsuccessfully tested functions can be efficiently retested. DOH reserves the right to define defects and impose turnaround times to fix those defects.

System Test Deliverables

The selected Offeror shall provide a testing strategy and initial test scenarios within 30 days of completion of the discovery process.

A comprehensive test plan, inclusive of all above elements, shall be submitted to DOH for review and acceptance within 6 months of contract award.

Iterative Configuration, Data Conversion, and Validation

The Commonwealth does not intend to defer user validation until all configuration is complete.

The Selected Offeror shall propose an implementation approach that:

• Uses iterative configuration cycles;

• Incorporates stakeholder demonstrations at defined intervals;

• Enables functional testing of prioritized capabilities prior to final system completion (e.g., testing plans and test scenarios);

• Provides TFP environments for configuration, testing, and user validation;

• Supports incremental release of validated features; and

• Allows feedback to inform backlog prioritization (and reprioritization).

The Offeror shall describe how it will ensure that configuration decisions are validated early and often, reducing the risk of large-scale rework late in implementation. Test plans and scenarios will be submitted to DOH for approval.

Data Conversion and Validation

Commonwealth data contained in the incumbent system must be accurately converted into the proposed solution. The data available for conversion in the current system includes the following, but is not limited to:

Source	Approximately
Volume DB/Size	64.42 GB
Total Records	916,044,481
Drive Size	Technically unlimited
Number of Files	DOH’s domo instance includes: 7 folders with 19 dashboards.

Testing is required for each iteration of data conversion. The selected Offeror shall report test results to DOH, which will be used to discover and remediate errors and to refine the process to achieve accurate test results. Data cleansing will be performed by the existing contractor and selected Offeror to ensure data cleansing has occurred. The selected Offeror shall identity data requiring cleansing to achieve conversion success.

In the event that a new platform is selected, the selected Offeror will perform the final conversion of data into the configured and successfully tested solution, including the final conversion into the production environment at appropriate cutover intervals and upon approval by DOH. The selected Offeror will provide the following materials to DOH for review and acceptance in order for data conversion tasks to be considered successfully completed:

a. Data conversion and validation plan

b. Final conversion test results showing all data has been successfully converted into the test and training environment

c. Final data conversion into the production environment

Offeror shall describe in its proposal an approach to data conversion and validation, including elements such as:

a. Approach and methodology to data conversion and validation;

b. Familiarity or experience with the current system;

c. Recommended conversion approach that describes the level of effort and DOH resources required; and

d. Assumptions or risks related to the conversion effort.

Iterative Configuration, Data Conversion, and Validation Deliverables

Within 5 days of discovery phase completion, the selected Offeror shall submit a conversion plan for DOH acceptance that shall include these minimum elements:

a. Clearly defined roles and responsibilities for Offeror and Commonwealth staff participating in the conversion;

b. Controls and programs used to assist in the conversion;

c. A system to track, document, and manage conversion issues within the overall product roadmap;

d. An iterative test plan to verify successful data conversion and mutually agreed reporting cadence to DOH;

e. Data models, relationship diagrams, and data dictionaries;

f. A detailed mapping of legacy data fields to the fields in the new solution;

g. A dynamic conversion schedule that can be continuously updated to reflect all steps, tasks, activities, events, milestones, and resources necessary for the selected Offeror to progressively convert the legacy data to the new solution; and

h. A resolution plan for records with conversion data issues.

Training Plan

The selected Offeror shall provide training for the users of the solution. The training plan should address the training requirements of all defined user types and roles. DOH will determine what functions end users shall utilize based on security roles. The proposed training plan shall include, at a minimum, the following:

a. Types of training (e.g., instructor-led, computer-based, hybrid) for each user type or role;

b. A plan for training MMOs on any major system release or change;

c. Number of training hours recommended for each user type or role

d. A training syllabus or curriculum outline; and

e. Training materials.

The selected Offeror shall provide resources for ongoing and new user training to support all functions in the system and maintain updated training materials in a knowledge base to support all users of the system. Offeror shall describe its proposed training program. Actual training will be conducted at a mutually agreed upon location or virtually. Any travel or training material expenses related to this training shall be at no cost to the Commonwealth.

Training Plan Deliverables

• Final Training Plan and Schedule

• Training Documentation, to include materials

• Fulfillment of User Training Sessions

Post-Cutover Operations, Monitoring, and Optimization

From the period of initial production cutover through completion of the base year, the Selected Offeror shall:

• Track and manage all requirements for the life of the contract, to include additional requirements identified during discovery;

• Support a defined stabilization and support period, consistent with Section V.L Solution Support;

• Monitor performance and defect resolution;

• Refine configuration based on operational feedback; and

• Transition to a governed enhancement backlog model.

Enhancements beyond minimum viable compliance should be sequenced according to Department-approved priorities and available funding.

Offeror shall propose a method for operating, maintaining, and optimizing the post-cutover system for the duration of the base period, to include product management, requirements management, adherence to SLAs, resource utilization, and project reporting.

Ongoing Operations & Maintenance

Following the base year, if option years are exercised, the selected Offeror will move into an operations and maintenance support service offering, made up of the following elements.

Solution Support

The selected Offeror shall provide solution support services as described in Section V.L Solution Support.

Maintenance

The selected Offeror shall perform all system maintenance needed to ensure the solution remains operational and meets the requirements detailed in this resultant contract and below.

a. All routine solution and hardware maintenance shall be completed outside of business hours, defined as 7:00am to 9:00pm eastern time, 7 days a week, including Commonwealth holidays.

b. The selected Offeror must provide DOH with advance notice of planned maintenance activities at a minimum of two weeks.

c. The selected Offeror must receive DOH approval before implementing any software upgrades in any environment used by the Commonwealth.

d. The selected Offeror shall describe their approach to ongoing operations, maintenance and system support. Offerors should describe how standard software upgrades, bug fixes, patches, data updates, configuration changes, and other improvements will be addressed in each release cycle.

i. Describe how an active backlog will be managed, to include prioritization for each release cycle. An example or breakdown of the regular maintenance cycles that have been used for operations and maintenance of other state-run seed-to-sale systems is requested.

e. The selected Offeror shall describe how the updates will be tested before updating any Commonwealth environment.

f. The selected Offeror shall describe how and when it updates online help systems, training tutorials, reference guides, and user manuals.

g. The selected Offeror shall notify DOH of any additional upgrade that is considered an additional feature to the solution as they become available. DOH, at its sole discretion, may choose to implement the feature. The selected Offeror must provide a written quote for any costs associated with the additional features for DOH approval.

h. DOH reserves the right to determine whether an issue is a defect and the severity level after any major or minor software release. Offeror agrees to address any defects as determined by DOH in accordance with timeframes established in Appendix K.

Change Control & Management

All changes to the system must be approved by DOH. The selected Offeror will be responsible for change management to include, not limited to, change request tracking, approvals process, and communication approach. Offeror shall describe a change control approach for this project, including elements such as how it plans to identify, evaluate, document, prioritize, categorize, resolve, schedule, and close out changes.

The change management process will be used to manage all system changes to include changes for defect management, system maintenance, and enhancements. After the initial acceptance of the solution, the selected Offeror shall make modifications for new items as required by the Federal Government or the Commonwealth at no additional cost to the Commonwealth.

User Documentation

The selected Offeror shall provide electronic versions of all documentation, in a format acceptable to DOH, and employ change control processes and version control to ensure documentation is kept current during the term of the contract. Where appropriate, a table of contents, an index, and keywords shall be available for information searching. DOH, at its discretion, may request or accept printed documentation on a case-by-case basis. User documentation shall include, but may not be limited to, data models, relationship diagrams, data dictionaries, and user guides.

Documentation is important not only for the ongoing maintenance and operation of the system, but also to facilitate any future changes to the system by a new or independent entity, to include transition to a new system or an expanded version of the current system should Commonwealth laws or regulations necessitate.

Governance and Accountability

The Offeror shall describe in its proposal:

• A governance model for phased implementation, to include resources required from the Commonwealth;

• A methodology for tracking burn rate against approved phase budgets for the post-discovery work, for which payment will be time and materials based;

• An approach to distinguishing configuration from enhancement;

• A mechanism for milestone review and acceptance; and

• An escalation process for risks and delays.

Implementation success will be measured not solely by completion of configuration tasks, but by operational readiness, statutory compliance, and successful transition from the incumbent platform.