Exhibit_C__Deliverables_and_Milestones_Table.docx

State of California Solicitation No. ISD26-3629 Department of Motor Vehicles

Exhibit C: DELIVERABLES AND MILESTONES The following table lists and describes the deliverables and milestones the Contractor will be required to deliver or meet, respectively, over the WS3A - DL/ID Mainframe Services, Data & Integration (WS3A) Contract, if awarded. These deliverables and milestones are intended to ensure the successful performance of all elements of the scope of this project:

· Comply with the project’s mandatory functional, non-functional, and project management requirements

· Complete DMV Driver’s License (DL) / Identification (ID) Card WS3A data analysis, cleansing, conversion, and migration

· Modernize DL / ID mainframe-based services and workflows to the DXP Salesforce Platform

· Use of DMV-approved enterprise tools and best practices

· Provide warranty and Hypercare support DMV DXP Project Approval Lifecycle (PAL) documents and other materials referred to in the "Deliverable / Milestone Description" column are provided in the Bidders' Library.

The Bidder must indicate agreement to each of the deliverables and milestone requirements listed below. A "Yes" response from the Bidder affirms that it understands the requirement and agrees to comply with the requirement. A "No" response from the Bidder deliverables or milestones listed will result in the Proposal being deemed non-responsive.

Failure of the Contractor to meet the due date of any deliverable or milestone, except for delays agreed upon in writing by both parties, may result in the rejection of the deliverable or milestone and termination of all subsequent activities, as solely determined by the State. The Contractor must immediately notify the State when a due date will not be met.

Table of Contents

Table of Deliverables

Yes/No

DEL-01

DEL-02

DEL-03

DEL-04

DEL-05

DEL-06

DEL-07

DEL-08

Project Management Plan and Sub-Plans Project Management Plan and Sub-Plans Overview

The Contractor, upon Contract award, shall:

Review existing DXP Project Approval Lifecycle (PAL) Plans.

Ensure the existing DXP PAL Plans contain all content described in the CDT PM Framework: https://capmf.cdt.ca.gov/ Agree to adhere to the methodologies in the DXP PAL Plans or propose updates for the DMV's written approval.

Next, the Contractor will assist in updating existing DMV DXP PAL PM Plan and Sub-Plans:

Project Management Plan (DEL-01) System Security Sub-Plan (DEL-02) DevSecOps Sub-Plan (DEL-03) Quality, Testing, and Production Release Sub-Plan (DEL-04-A) and Performance Management Sub-Plan (DEL-04-B) End-User Training Sub-Plan (DEL-05-A) and Technical Knowledge Transfer Sub-Plan (DEL-05-B) Organizational Change Management (OCM) Coordination Sub-Plan (DEL-06) Transition Exit & Interaction from Contractor to DMV Sub-Plan (DEL-07) Transition Entry & Interaction and Hypercare Delivery Sub-Plan (DEL-08) The Contractor's PM Management Plan and Sub-plan updates must utilize the DXP PAL plan templates that define the approach, methods, tools, and processes the Contractor will use to manage this project. The Contractor shall describe how any update to the PM Plans will align to the existing methodologies shown in the DXP PM Plans. It is imperative that the Contractor updates DXP PM Plans with narratives that describe the nuances and insights needed to manage this DXP DL/ID Workstream 3 project within the broader scope of DMV's DXP initiative.

This project will be conducted using an Iterative Waterfall approach. The Sub-Plans must be updated incrementally to reflect the progressive elaboration of phased completion of work. The Sub-Plans must describe how the Contractor will effectively implement Iterative Waterfall practices and deliver the Contract deliverables.

The Project Management Plan and Sub-Plans shall be maintained and updated through the life of the Contract.

The Contractor shall leverage DMV DXP's Project Approval Lifecycle (PAL) Stage 3 and Stage 4 planning documents, updating them as needed to create the PM Plan (DEL-01).

The plan shall be updated as needed to include the goals, detailed activities, and objectives for each of the following activities:

Discovery planning of business, technical, conversion, training, and implementation Roadmap and strategy development of iterations and production releases Team composition of the Contractor and the DMV Solution Backlog Management and Grooming Agile Playbook Iteration planning and iteration execution, including testing, demos, and Retrospectives Weekly Dashboard Reports Monthly Project Steering Committee Meetings and Reports Quarterly DMV Satisfaction Surveys Change Control (including the Change Control Board) Release Management Planning Subsection: Schedule Management The Contractor's Project Management Plan, Schedule Management Subsection, shall utilize and update DMV DXP's existing PAL Stage 2 Schedule Management Plan to describe the Contractor's strategy for developing and maintaining the schedule, define the tools used, and outline the methods for reporting schedule progress. The Plan shall also describe how the schedule will reflect the activities that will be tracked in the DMV's tool, OpenText's ALM Octane.

The Contractor is responsible for developing and maintaining the schedule; the Contractor shall collaborate on a weekly basis with the DXP PMO to ensure that the DMV's and integrating partners’ scheduled tasks are integrated into the schedule and kept up to date.

Subsection: Risk and Issue Management The Contractor's Project Management Plan, Risk and Issue Management Subsection shall utilize and update DMV DXP's existing PAL Stage 3 Risk Management Plan to describe the Contractor's strategy for managing project-level risks and issues and define the tools used and methods for reporting risks and issues. The Plan shall also describe how risks and issues will be reported, tracked, and managed.

Subsection: Communications Management The Contractor's Project Management Plan, Communications Management Subsection shall utilize and update DMV DXP's existing PAL Stage 2 Communication Management Plan to describe the Contractor's strategy for managing communication across the project team organization structure, DMV management, DMV users, stakeholders, as well as the public, and define the tools used and methods for communication. The Communications Management Plan shall describe the Contractor's strategy for ensuring bi-directional communication with other DMV and DXP vendors to ensure continuity of architecture, design, configuration, development, integration, testing, implementation, Warranty, and M&O activities.

Subsection: Documentation Development and Maintenance The Contractor's Project Management Plan, Documentation Development and Maintenance Subsection shall describe the Contractor's strategy for developing and maintaining of the documentation including deliverables and work products. Deliverable development must include creating and approval of a Deliverable Expectation Document (DED) and a Deliverable Approval Document (DAD) for a deliverable or a group of deliverables. Work Products must be managed and provided to the DMV in the same manner as a Deliverable. Documentation must be updated incrementally with each production release. The Contractor should also reference usage of project repositories (e.g., ALM Octane) that will house project deliverable artifacts. The Contractor’s plan shall include the development and maintenance of a Requirement Traceability Matrix that maps project requirements to design specifications and build components. This matrix will be created using the State-approved template and will be continuously updated throughout the project lifecycle to ensure all requirements are accurately traced and validated.

30 calendar days after project start

The Contractor's System Security Sub-Plan shall utilize and update DMV DXP's existing PAL Stage 3 Security Management Plan to update, implement, and maintain a System Security Plan (SSP), subject to DMV approval, in accordance with security industry standards, such as State Federal Information Processing Standards (FIPS) (e.g., NIST 800-53, Rev. 4 Security and Privacy Controls for Federal Information Systems and Organizations, NIST 800-18, Rev. 1, Guide for Developing Security Plans for Federal Information Systems, and FIPS 199 and the ISO/IEC 27002 Code of Practices for Information Security Management and applicable statutes and regulations, DMV's Information Security and Privacy Provisions aligned to the State of California State Administrative Manual (SAM) and Statewide Information Management Manual (SIMM).

The SSP must detail how the Contractor implements its security requirements. It should include:

The roles and responsibilities of security personnel A high-level diagram of the system and communication with other systems Design philosophies include defense-in-depth strategies and allowed interfaces and network protocols.

Reference existing policies and procedures All the controls to protect DXP, including procedures that people should follow The Plan must provide the Contractor's approach for ensuring the operationalization and utilization of Salesforce's continuity plan, as well as maintaining third-party product upgrades to ensure they continue to work with the PaaS, and for establishing security practices to prevent the likelihood of security breaches, including ransomware attacks, in accordance with industry best practices and Attachment 26Exhibit E: Information Security and Privacy Provisions.

The Plan shall, at a minimum, apply to all personnel and data, as well as systems used in conjunction with DMV services, and include provisions that offer sufficient protection for information designated as confidential, personal, or sensitive.

The Plan must be approved by the DMV Project Manager prior to implementation and shall be reviewed and updated by the Contractor at least quarterly.

The Plan shall address the policies, procedures, guidelines, and standards that protect the confidentiality, integrity, and availability of all DMV information, including:

Security Management Security Architecture Telecommunications and Networks Access Control Systems Application and System Development Operations Security Physical Security Cryptography The Plan shall outline how the Contractor will analyze the requirements for functional access to Solution screens and data and assign user roles according to external and internal Solution user role requirements, with authorization at a screen/transaction/field/data access level, providing appropriate access for review, update, approval, and deletion.

If the Solution components do not support WCAG 2.1, the Plan must address how the Contractor plans to bridge the gap between its Solution and WCAG 2.1.

The Plan shall describe how the Contractor will provide a detailed report of any actual or suspected data breach to the DMV DXP Project Manager immediately (or within one (1) hour of the actual or suspected security event), a preliminary report of the security event within three (3) working days, and a full, detailed written report within ten (10) working days of the security event.

If any earlier incremental production deployment is planned, this plan is to be due 30 days prior to the first incremental deployment

The Contractor shall review DMV's existing DMV DXP Vehicle Registration (VR) DevSecOps Plan, updating the plan as needed to describe how its Solution will utilize ALM Octane to manage all aspects, including all Workstream 3 components, transactions and widgets, capacity management, configuration, customization, integration, security with other tools for CI/CD development, testing, and releases. The Contractor's DevSecOps Plan will incorporate a DevSecOps Dashboard and describe how its approach will leverage the existing DMV DevSecOps Plan and propose any necessary improvements to address project requirements.

The Contractor's Quality, Testing, and Production Release Plan shall utilize and update DMV DXP's existing PAL Stage 3 Quality Management Plan and Stage 4 Implementation Management Plan to describe the Contractor's proposed organizational team structure and processes required to manage quality through the course of this project until completion of Hypercare and warranty periods. The Plan shall describe practices to assure the quality of the Contractor's DXP DL/ID Workstream 3 Solutions/System components, specific deliverables to be produced, reviews and approvals associated with each deliverable, standards for baselining, overall test strategies, and other methods to be used within the project to assure quality and consistency throughout the life of the project. The DMV expects a dedicated Quality Team to be responsible for assuring quality prior to submission of Deliverables and Work Products to the DMV.

The DMV will maintain the Quality Management, Testing, and Release Plan for the project in the future to assure quality and consistency throughout the life of the Solution.

The Quality Management component of this Plan shall address the following:

Quality Control and Best Practices:

Description of how the Contractor will apply quality control, best practices, industry standards, defect density thresholds, and lessons learned to the project processes and deliverables.

Iterative Waterfall Framework:

Description of how the Contractor's Quality Management processes will be incorporated in an Iterative Waterfall implementation framework.

Quality Assurance and Control Techniques:

Description of the Contractor's quality assurance and quality control techniques to ensure quality service and Solution components, such as software, hardware, and any other integration or component, including:

Description of Solution components that will be subject to testing, quality assurance, and quality control, including those Solution components that can be expected to be reviewed by a person(s) conducting independent verification and validation (IV&V) work for this project.

Description of quality metrics and how the Contractor will perform quality audits.

Description of internal quality control processes to identify and reject unacceptable Solution components or hardware elements.

When root cause analysis will be performed, and how corrective actions will be implemented (e.g., procedures for handling Solution software elements that do not meet quality standards).

Testing Plans and Procedures:

Description of the Contractor's strategy for managing testing through all the test phases, including support during DMV User Acceptance Testing (UAT), definition of the tools used and methods for conducting testing, and how the Contractor will capture and report testing results, and manage defect resolution. These definitions focus on how the Contractor will utilize DMV's existing SDLC tools to manage test phases, defect management, and related items.

Description of how testing will be conducted under an Iterative Waterfall framework.

Plan for testing in accordance with industry standards, such as the "IEEE/ISO/IEC 15289-2019 – ISO/IEC/ IEEE International Standard – Systems and software engineering – Content of lifecycle information items" standard, to manage testing and defect tracking to provide an efficient error-correction process for system and UAT.

Identification of the overall tests to be performed and planned test levels (e.g., unit tests, System Integration Testing (SIT), UAT).

Description of testing with data converted from the legacy system(s), including Contractor support during UAT.

Description of testing with data exchange partners, including Contractor support during UAT.

Planned cycles of tests, test metrics, and thresholds for defect density.

How each DMV-approved transaction will be documented to form test cases used for testing activities, based on one (1) or more functional requirements.

Whether testing will be conducted remotely, if approved in writing by the DMV.

How automated testing will be applied.

Description of processes the Contractor will use for test script development for continuous system and UAT testing in support of Iterative Waterfall development and delivery.

Description of processes the Contractor will use for execution, defect management, and management of the automated script inventory.

Testing Phases:

How the following testing phases will occur:

Unit Testing:

Code Unit Test, Scripts, Known Defect Reports/Logs and Resolution, Complete Functionality/Code Complete Phase.

Other Testing Types:

Test Plan, Schedules, Scripts, Metrics, Report, DMV Signoff.

Iteration SIT, including interface and integration testing.

Iteration UAT.

End-to-End SIT (including UAT Plan, Schedules, Scripts, Metrics, Report, Signoff).

Automation Testing Approach and Scripts.

Performance/Load/Stress Testing: Performance Test Plan, Schedules, Scripts, Report, DMV Signoff.

Specified User Group Acceptance Testing (including Functional and Performance/Reliability Testing).

Vulnerability and Penetration Testing.

Regression Testing.

Security Compliance Testing (including Security Test Plan, Schedules, Scripts, Report, and Signoff).

ADA Compliance Testing.

Mobile Testing.

Test Phase Prerequisites include:

Business Requirements, Test Strategy Plan, Test Environment Requirements, Test Data Strategy, Third-Party Vendor Testing Engagement, Build Release Schedules, Code Completion Date, Architecture/Technical, and Solution. Additional components include:

Dedicated Support for SIT and UAT:

The Contractor shall provide dedicated support teams for SIT testing phase. This team will also be responsible for assisting with defect resolution and onsite supporting testers during UAT.

Defect Management:

The Plan shall include a detailed defect management process outlining how defects will be tracked, prioritized, and resolved. The Contractor will specify the tools used for defect tracking and the communication process for defects to the DMV.

Clear timelines for defect resolution, especially for critical and high-priority defects, shall be defined to ensure prompt addressing.

SIT Validation:

The Contractor shall provide a plan detailing how they will work with DMV to validate the results of SIT, ensuring all components meet the required standards and function as expected before proceeding to UAT.

UAT Assistance:

Roles and responsibilities of the Contractor's team during UAT, including handling tester queries and issues.

Test Data Management:

A comprehensive plan for managing test data, including data preparation, data masking, and data refresh strategies, shall be included to ensure realistic and consistent test scenarios for both SIT and UAT.

Test Environment Setup:

Detailed setup and maintenance of test environments for SIT and UAT shall be included. This will cover environment configuration, access control, and ensuring the environments are stable and closely reflect production.

Automated Testing:

The automated testing approach shall be expanded to specify which tests will be automated and how automation will be integrated into the SIT and UAT processes. Details on the tools and frameworks used for automation shall be included.

Reporting and Metrics:

Reporting mechanisms for SIT and UAT, including the frequency of status reports, the content of these reports, and the communication process to the DMV, shall be defined.

Metrics for tracking testing progress, defect density, test coverage, and other relevant KPIs shall be included to provide transparency and ensure accountability.

Regular Reviews and Updates:

Schedule regular reviews and updates of the Quality, Testing, and Production Release Plan to incorporate lessons learned and adapt to any changes in project scope or requirements.

Stakeholder Involvement:

Ensure that key stakeholders, including DMV representatives, are involved in the planning and execution of SIT and UAT. Their input and feedback shall be actively sought and incorporated.

The Contractor shall describe how it plans to collaborate with DMV to measure, monitor, and report against Service Level Agreements (SLAs). The SLAs are covered in Section 37: Service Level Agreements of the Scope of Work. The Sub-Plan must:

1. Define key performance indicators (KPIs) aligned with the SLAs Describe the methodology and tools to be used for data collection and performance measurement Describe procedures for regular performance reporting, including format, frequency, and distribution of reports Describe the process for the Contractor and DMV joint review and validation Identify corrective action processes for instances of SLA non-compliance

The End-User Training Sub-Plan shall include, at a minimum, the Contractor’s plans for Train-the-Trainer, End-User Training, and Go–Live training, and shall describe the Contractor's strategy for contributing to, coordinating with, and collaborating with the DXP Workstream 2 Vendor and DXP OCM Vendor to provide end-user training, as applicable, to Workstream 3. The Plan should describe how the Contractor plans to collaborate with other DXP Vendors to successfully manage training. The Contractor must describe how its training activities will comply with DMV’s methods and tools, which include but are not limited to:

· Utilizing the Analysis/Design/Development/Implementation/Evaluation (ADDIE) model for training and learning;

· Using the Articulate 360 E-Learning tool for design

· Including master Sharable Content Object Reference Model (SCORM) units and source files in training materials and their iterations

· Using the DMV’s Learning Management System (LMS), Blackboard.

The Contractor must describe how it plans to report training progress against the plan. The Plan shall be implemented upon approval by the DMV and updated by the Contractor during the period of the Contract.

The Sub-Plan shall include, at a minimum:

1. A DMV Learning and Development approved plan for how the End-User training (to DMV staff and DMV business partner users) shall be achieved for Train-the-Trainer and End-User Training A skills assessment and gap analysis, with a listing of the target skills needed for the training audience, and a roadmap for skills development. Additionally, this should directly connect to the learning objectives and transactions.

Mechanisms for measuring and reporting on the progress towards target skill development.

ADDIE Model approach must be used to develop the course curriculum (including facilitator guides, learn guides, presentations, PowerPoints, job aides, and quick reference guides (and any other guides and tools Contractor wishes to provide) and to ensure quality training products. All course curriculum and training materials must be federal Section 508 C complaint for digital content accessibility for individuals with disabilities at all stages of development.

Instructional methods and deliverables to be used to provide training to existing and future staff. All deliverables must be compatible with DMV Learning Management System (Blackboard).

Instructional methods and deliverables to be used to train future staff to be brought up to speed from the perspective of a new support staff position. DMV requires formats to support all learners, which include self-paced online training, live virtual training, virtual hands-on training, and blended training modalities.) Contractor must provide recording of live virtual training for topic trained and the class ratio cannot exceed 25 learners to 1 trainer.

DMV requires contractors to use Articulate360 to design and develop all self-paced training and FlexClip to support video accessibility. All training components (including but not limited to eLearning, facilitator guides, learn guides, presentations, PowerPoints, job aides, and quick reference guides) must be federal Section 508 C compliant for digital content accessibility. DMV will verify and approve all training materials to ensure accessibility prior to use in any DMV training.

The plan must describe methods to be used for training material quality assurance, to obtain feedback from DMV on reviews, to make edits, to support accountability for completion of updating and making edits, and to ensure DMV acceptance of training contents in a final decision.

The plan should include contractor quality assurance reviews prior to sharing with DMV. DMV will also have at least two weeks to provide our own quality assurance on the different waves of material to ensure transparency and completion of material. DMV will approve final product for all training component releases.

Methods to be used for obtaining feedback on the training effectiveness and report out to DMV The method must be connected in the DMV Learning Management System (Blackboard) to support ongoing feedback of effectiveness. The DMV encourages a Sharable Content Object Reference Model (SCORM) approach for constructing training and ensuring traceability in the DMV’s learning management system (LMS).

Methods to be used to incorporate feedback from UAT incidents that are not functioning as desired as well as resolve the incident Remedial training hours, office hours, and refresher training approaches are new features that are introduced to the Solution after go-live. Office hours will also be required after Train-the-Trainer to support effective training/knowledge transfer of system/information.

Approach of creating a training environment with data needed with refresh capabilities for Train-the-Trainer, End User Training, and post go live ongoing training.

Approach of creating a practice environment that will allow train the trainers and end users to experiment in the system without impacting production or the training environment.

Creating a Training schedule for Train-the-Trainer and End-User Training that will be inclusive of office hours, remedial training, and refresher training

The Technical Knowledge Transfer Plan shall describe the Contractor's strategy for coordinating and managing the transfer of technical knowledge and skill development to designated DMV information technology staff. The plan shall define the tools and methods used to report progress on knowledge transfer against the plan. The Knowledge Transfer Plan must describe the techniques and tools, knowledge transfer requirements, schedule for formal and informal training, curriculum, materials, and equipment required for all knowledge transfer activities.

The Plan must include the approach for on-the-job training opportunities, job shadowing, and coaching of technical staff to achieve knowledge transfer objectives.

The detailed Plan is due to the DMV for review and approval one (1) year following the Project start date or later, if agreed in writing by the DMV. This is to ensure all technical aspects of operating and supporting the Workstream 3 Solutions/systems can be comprehensively captured within the Plan.

The Plan shall be implemented upon DMV approval and updated by the Contractor during the period of the Contract.

The Plan shall include, at a minimum:

1. A plan to show the knowledge transfer objectives and how the knowledge transfer shall be accomplished.

A skills assessment and gap analysis, with a listing of the target skills needed for the DMV or state IT staff to take over from the Contractor to support project lifecycle activities, and a roadmap for skills development.

Support model covering all technical and service layers and Responsible, Accountable, Consulted, Informed (RACI) matrix covering the entire solution lifecycle.

Mechanisms for measuring and reporting on the progress towards target skill development.

The approach to be used to develop the course curriculum.

Scope and schedule of planned knowledge transfer and training activities.

Instructional methods and deliverables to be used to provide knowledge transfer to existing staff.

Instructional methods and deliverables to be used to train future staff to be brought up to speed from the perspective of a new IT support staff position. DMV requires formats to support all learners which includes self-paced online training, live virtual training, virtual hands-on training, and blended training modalities.)

Methods to be used for obtaining feedback on the training effectiveness. The Contractor will be responsible for completing modifications to training materials based on feedback on training effectiveness and on training materials used.

Method to be used to achieve progressive elaboration of the training approach to introduce more complex concepts and skills to the knowledge transfer audience.

Creating a Training schedule.

Shadowing can start as early as 6 months after project start

The Contractor will coordinate, collaborate, and act as a lead and facilitator, along with DMV DXP's OCM Vendor, DXP Workstream 2 Vendor, and other vendors to support OCM needed to ensure the success of the developed system and process improvements. The Contractor is expected to bring expertise, knowledge, and experience in industry-proven practices to provide recommendations that support stakeholders in adopting the DL/ID Workstream solutions. The OCM Coordination Sub-Plan will include sections outlining how the Contractor plans to assess, anticipate, and collaborate with the DXP OCM Vendor to perform activities and deliverables that ensure the adoption of changes associated with implementing the DL/ID Workstream 3 solutions.

The Plan will entail the following activities and include a description of the following:

Overall OCM coordination approach – including, but not limited to, developing plans to understand and support user personas Approach to documenting key solution changes -including, but not limited to, understanding current processes and identifying change impacts and new terminology Approach to communicating Solution changes with DXP OCM Vendor Approach to communication planning Approach to understanding and supporting business and partner-specific needs Approach to ensuring the Contractor’s plans and roadmap for program change identify tasks, validating mechanisms, and benchmarks/milestones and success for expected results relevant to the DL/ID Workstream 3 Solutions.

Stakeholder and business readiness Go-live readiness and support model approach The OCM Coordination Plan shall be implemented and maintained upon DMV approval and updated by the Contractor during the life of this Contract.

The Contractor Transition Exit and Interaction Plan shall outline the comprehensive approach for ensuring a successful, seamless transfer of Solution ownership, control, and operations from the Contractor to either the DMV or a successor Contractor. The plan must be structured, proactive, and measurable to mitigate risks, preserve operational continuity, and safeguard the State’s interests.

1. Plan Development and Maintenance The Contractor must:

Develop and submit a detailed Transition Exit and Interaction Plan.

Maintain and update the Plan throughout the Contract term, subject to DMV review and approval.

Ensure the Plan identifies all activities, timelines, owners, and interdependencies related to transition.

2. Transition Phases and Milestones The Plan shall include and elaborate on the following phases:

Transition Planning: Deliver a structured schedule, task matrix, and stakeholder coordination framework.

Knowledge Transfer (KT): Define sessions, documentation, content, format (recorded, written), and recipient roles.

KT Verification: Include validation through walkthroughs, quizzes, or supervised operations.

Full Cutover: Provide readiness checklists, mock cutover exercises, and go/no-go criteria.

Post-Cutover Stabilization: Define support window, staffing, escalation procedures, and incident response coverage.

3. Transition Manager and Roles The Contractor must:

Appoint a Key Staff member from the Scope of Work, Section 12, as Transition Manager.

Ensure participation of the Project Manager and Project Director in all transition planning and governance activities.

Collaborate with DMV and the successor organization through a dedicated Transition Governance structure.

4. Transition Deliverables and Handoff Artifacts The Plan must define the delivery of all required transition artifacts, including:

System Operation Manual (Runbook) Code repositories, build scripts, and version histories Configuration files and job schedules Test cases, logs, defect reports System architecture diagrams and process flows Data lineage documentation and transformation logic Incident management procedures and knowledge base articles License inventory with ownership and transfer documentation Hardware/software environment inventories

5. Validation and Acceptance The Contractor shall:

Support DMV in validating knowledge transfer effectiveness and operational readiness.

Participate in mock cutovers, data handover verifications, and functional demonstrations.

Ensure DMV signs off on all completed deliverables using formal acceptance criteria.

6. Risk and Issue Management The Plan must include:

A Transition Risk Register documenting identified risks, owners, mitigation strategies, and escalation paths.

A mechanism to review and update risks during weekly transition meetings with DMV.

7. Communications and Coordination The Contractor must:

Develop a Transition Communications Plan that includes status updates, stakeholder roles, and escalation paths.

Coordinate timelines, handoffs, and deliverables with other vendors and DMV teams.

Ensure all communications and updates are archived and traceable.

8. Licensing Transfer and Compliance The Contractor must:

Ensure transfer of all applicable licenses including source code, tools, and third-party software.

Provide documentation confirming license rights and usage terms.

Assist DMV in reassigning license ownership to successor organizations as needed.

· The Contractor must develop, maintain, and implement a Hypercare and Warranty Plan within ninety (90) calendar days following Project start. The Plan shall include the processes, methodologies, and tasks the Contractor will employ, and the documents the Contractor will deliver, to perform Hypercare and Warranty services for the DL/ID Workstream 3 Solutions.

· This plan is expected to be the foundation of how the Contractor will carry out its responsibilities for the successful installation, implementation, and deployment of the Solution to comply with the performance and availability requirements of this Contract. In addition, the Hypercare and Warranty Plan shall define the processes and procedures the Contractor will employ to maintain the Solution, following full Feature Delivery and Solution acceptance, to ensure uninterrupted operation as required by this Contract, and that Project documentation is kept current throughout the Hypercare and Warranty period.

· The Hypercare and Warranty Plan shall address the following operational areas and processes:

Application Administration Application Architecture Application Development Asset Management Availability Management Build Management Business (Service) Continuity Management Capacity Management Change Management Configuration Management Database Administration Service Desk Support Incident Management Network Administration Network and Infrastructure Architecture Problem Management Program Management Project Management Performance Management Release Management Security Management Service Level Management Storage Management System Administration

· The Hypercare and Warranty Plan shall include a description of the following:

Roles and responsibilities of the Hypercare and Warranty Team, including DXP project staff Methods for ensuring the Solution is fully functional and performs in accordance with the terms of this Contract Methods of communication and coordination with DMV staff while executing Hypercare and Warranty tasks, including an approach to partnering with DMV ESD and CSD Service Desks to develop triage processes, procedures, and steps for troubleshooting issues related to the Solution How deficiencies will be escalated and resolved How troubleshooting will be performed to diagnose and resolve defects or performance anomalies (with reference to SOW Section 35.L: Solution Deficiency Correction) Methods for monitoring of Solution performance and other Service-Level Agreements Contingency planning for end-of-life technology changes Management of changes to the Solution to support end users, including:

Changes due to deficiencies in the Solution components Configuration changes recommended by the manufacturer, including firmware patches and updates to software Testing of changes and reporting of testing results (Note: Implementation of the new functionality may only begin after approval by the DMV of the test results and required outputs) Periodic updates of reference table values Coordination of the timing of any changes Methods for and frequency of updating Solution documentation as changes are applied, including to user manuals and training materials Continuation of end user support through training and documentation Performance of required security activities such as backups and updates Software end-of-life contingency planning Planned annual maintenance schedule, including the following:

The Plan for software upgrades, patches, and hardware upgrades When maintenance will be performed and how long the maintenance tasks will take Parameters for Solution downtime during preventive maintenance

· The Hypercare and Warranty Plan shall be implemented and maintained upon DMV approval and updated by the Contractor as required during the life of this Contract. Monthly project status reporting shall include updates on Hypercare and Warranty activities above, as well as monitoring and reporting on Service-Level Agreement results for the month.

The State expects the Contractor to coordinate with the DMV DXP Program Manager and Project Scheduler to develop a Workstream 3-specific Project Schedule that utilizes the Iterative Waterfall framework for managing the project, where design and development tasks will be tracked and managed using a combination of Microsoft Project Schedule and DMV's management tool, ALM Octane.

The State requires a Project Schedule for activities including, but not limited to:

DEDs and DADs of all Contract Deliverables Contract Deliverables Contract Milestones All teams – Project Management, Business, Product, Testing, Technical, Conversion, Implementation, Training, OCM Coordination, etc.

Backlog, requirements, design, development, demos, SIT, UAT, Conversion, Cutover, and Production Release Pre-Design, Design, Iterative Development and Testing (Iteration SIT and UAT), End to End SIT, End to End UAT, Conversion Cutover, Production Release, Hypercare and Warranty Transition Exit from implementation to Hypercare and Warranty phases This Project Schedule shall be dynamic and forecast variance in the implementation date. It shall also be implemented and maintained upon DMV approval and updated by the Contractor as required during the life of this Contract. The Contractor must provide detailed tasks every month for the upcoming two (2) months' activities.

Initial draft due 30 calendar days after Project start

The State expects the utilization of an Iterative Waterfall Framework for managing this project, where Hypercare and Warranty tasks will be tracked and managed using Snow Incident Management and ALM Octane.

The State requires a Hypercare and Warranty Project Schedule for activities including, but not limited to:

DEDs and DADs during Hypercare and Warranty resulting from approved Change Control Requests and all other Contract Deliverables Hypercare and Warranty Milestones Resource needs and capacity planning to include teams for Project Management, Business, Product, Testing, Technical, Conversion, Implementation, Training, OCM Coordination, etc.

Program Increment narrative(s) to support Iterative Waterfall development Backlog, requirements, design, development, demos, SIT, UAT, Conversion, Cutover, Production Release Hypercare and Warranty Transition Entry Hypercare and Warranty Transition Exit This Project Schedule shall be dynamic and forecast variance in the implementation date. It shall also be implemented and maintained upon DMV approval and updated by the Contractor as required during the life of this Contract. The Contractor must provide detailed tasks every month for the upcoming two (2) months' activities.

The Contractor must leverage the current DXP OL/VR/CC Solution architecture and update it to include the Solution Architecture required for this project. This Solution Architecture Document must be maintained throughout the Contract, describing the architectural details of the Solution and the technologies used to meet all aspects of the project requirements.

The proposed architecture aligns with DMV’s enterprise architecture principles, standards, and technology stack guidelines. Any deviations from DMV standards must be clearly documented and submitted for DMV review and written approval.

The content requirements of the Solution Architecture Document shall be agreed upon with the State. The final version of the Solution Architecture Document shall reflect what is deployed to production at the end of the project.

The Solution Architecture Document must include the following:

1. Solution Architecture overview, functional sub-system diagram, and associated description of each of the functional sub-systems that represent the business processes contained within the Solution.

1. The technology stack involved in the proposed Solution, including programming languages, frameworks, libraries, patterns, servers, UI/UX solutions, software, and tools to be used by the Contractor. Such tools may include project management tools, developer tools, testing tools, and other software.

1. A description of how non-technical staff can implement and change business logic and modify business rules quickly and without complicated coding.

1. The Solution's capabilities and limits for batch and bulk data processing, including how batch processes will be bi-directional and will process external data sources and feeds. Describe how the Solution will address real-time data processing methods, including web services.

1. Logical and physical Architecture Diagrams (and associated descriptions and technology) of the sub-systems used for workflow and business rules.

Logical and Physical Diagram (and associated description and technology) of integration architecture, including supported protocols for both batch and real-time integrations (see Exhibit B: Functional and Non-Functional Requirements – Interfaces section for additional information).

1. Data Architecture Diagram (and associated descriptions) of how the system implements:

· Data security (e.g., FTI, PHI, PII)

· Reporting

1. A detailed Security Architecture section that addresses:

· Identity and Access Management (IAM), including roles, authentication, and authorization mechanisms

· Data encryption (in transit and at rest)

· Firewall and security zone design

· Security monitoring, audit logging, and integration with DMV's security operations

· Compliance with applicable data protection and cybersecurity regulations Physical Architecture Diagram and a list of all infrastructure components (e.g., servers, firewalls, load balancers, intrusion protection/detection system) and all software (including proprietary and third-party software) that comprise the Solution.

1. How Salesforce will provide the required functionality, in detail, and to what extent.

1. Assessment of the Solution, including architecture, development methodology, data structures, Salesforce and AWS features, user interface/user experience (when applicable), integrations, and all other Solution components, to determine gaps between the as-is architecture and foundational features of Salesforce, MuleSoft, and any other proposed Solution.

1. Architecture Governance Model that includes:

1. Roles and responsibilities of the Contractor, DMV, IV&V, and any other vendors

1. Architecture review cadence (e.g., monthly or milestone-based)

1. Approval workflow for architectural decisions and proposed changes

1. A Solution Architecture Change Log capturing proposed, approved, and rejected changes

1. All architecture decisions impacting shared components, interfaces, or multiple workstreams must be reviewed with DMV prior to implementation.

1. A method for agreeing upon Solution Architecture changes that incorporates approval from DMV, for changes that may affect other solutions downstream, and a Solution Architecture Change Log that documents such proposed and approved decisions regarding change; Escalation to DMV regarding conflicts between vendors regarding changes that impact concurrent work streams and deliverables.

1. This Plan sub-section should also address:

· Coordination of release management and the potential impact on the user community

· Ability for releases to be coordinated across multiple vendors with coordinated dates

· Contractor approach to developing release plans and roadmaps to be reviewed and approved by DMV

1. The Solution description must include text, diagrams, charts, and images to adequately depict the Architecture and features/components to be integrated into its Solution.

1. The Solution Architecture Document shall also incorporate:

· An overview of the implementation approach taken, including diagrams and details of how the Solution integrated all components

· How the Solution handles interfaces/APIs and other non-prepackaged features or add-on enhancements/accelerators

· How the Solution provides demonstrated integration with existing DMV components when and where applicable:

· DMV's existing services, data, and databases

· DMV's existing enterprise application integration platform

· DMV's Oracle Financials/e-Business suite for financial data reporting/ reconciling

· DMV's Customer Communication Management Platform for customer notifications generation

· DMV's unchanging IT/system elements, including DMV's enterprise architecture

1. Dedicated sections that describe:

· Horizontal and vertical scalability mechanisms

· High availability (HA) configuration, including failover strategies and redundancy

· Disaster Recovery (DR) strategy, including Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO)

· Load balancing, session management, and data replication strategies where applicable

1. Provide a logical data schema and logical data model of underlying data components.

1. Provide a physical data schema and physical data model of the database(s), as built.

1. How the system will be monitored post-deployment. This must include:

1. Toolsets and frameworks for monitoring application health, usage, and system performance

1. Logging strategy, including structured/unstructured logs, log retention, and access control

1. Alerting mechanisms and integration with DMV's enterprise monitoring platforms

1. Reporting dashboards for DMV operations and technical teams

1. Architecture and configuration of all required environments, including development, test, staging, UAT, training, and production. This must include:

· Environment topology and logical separation

· Configuration management across environments

· Data refresh strategy, including masking of sensitive data in non-production environments

· Environment promotion workflow and version control procedures A traceability matrix mapping architectural components and design decisions to the corresponding functional and non-functional requirements outlined in Exhibit B.