ATTACHMENT 18- NARRATIVE REQUIREMENTS.pdf

ATTACHMENT 18: NARRATIVE REQUIREMENTS

The Bidder must provide a (page limits specified below) narrative describing their understanding of and approach to the questions/topics below. In preparing a response to the Narrative, do not simply restate or paraphrase information in this solicitation and the SOW. Describe or demonstrate, in the Bidder's own words, the information required below.

The response descriptions and explanations should be straightforward, detailed, and precise. Responses will be evaluated as stated in SECTION 6. EVALUATION.

Each Narrative Response must adhere to the instructions specified in SECTION 3.4.3. NARRATIVE REQUIREMENTS (MS) (DUE IN PHASE 1 AND PHASE 2), contain the content as shown on this attachment, and include the following:

1. Table of Contents (not included in page limit)

2. Separate headings to delineate sections (aligned with the Table of Contents)

3. Formatting to ensure greater ease of evaluation, by:

a. Use of bold headings and sub-headings to easily locate information

b. Use of sub-headings or bullets to address each requirement or element listed for each narrative

c. Use of tables for each project described to summarize relevant information

d. Use of tables to highlight other relevant content for the narrative sub-sections

e. Use of graphics to enhance readability of response

f. Avoid use of acronyms

g. Provide glossary at the end of each narrative if non-standard terminology is used

The Bidder must include with its proposal, a description of the Bidder’s understanding of the DL/ID Solution project and the Bidder’s role and approach to accomplish project implementation (including system configuration, testing, and training), maintenance and operations (M&O) objectives, meet timelines, and complete project deliverables. Each item’s response should not exceed the specified number of pages.

The Narrative Response is delivered by eligible Bidders across two (2) phases, both of which include evaluation for product and implementation responses. All Bidders are required to respond to Phase 1 Narrative Requirements. Only Bidders invited to Phase 2 will be required to respond to the Phase 2 Narrative Requirements. The product responses shall focus on the proposed product(s) itself and shall expand on the functional and non-functional requirements with a cohesive description of the product technology and functionality. The implementation responses shall focus on the implementation services and is in response to the Statement of Work.

NARRATIVE REQUIREMENTS SUMMARY MATRIX PHASE 1

https://sb.cityinnovate.com/account/solicitations/documents/404751#section-866460 https://sb.cityinnovate.com/account/solicitations/documents/404751#section-866442

Response No.

Phase Due

Max Pages Narrative Requirement Description Category Max Points

PHASE 1 Narrative Response Matrix

1-1 1 30 Pages Solution Architecture and Security Narrative

(MS) 420

1-2 1 15 pages Product-Solution Accelerator and Differentiator Narrative

(MS) 420

1-3 1 30 Pages Conversion, Integration, and Implementation Narrative

(MS) 420

1-4 1 20 pages HyperCare and Warranty Plan Narrative (MS) 420

NARRATIVE REQUIREMENTS SUMMARY MATRIX PHASE 2

PHASE 2 Narrative Response Matrix

Response No.

Phase Due

Classification (Max Pages)

Narrative Requirement Description

Category Max Points

2-1 2 15 pages Transition Entry and Interaction Plan Narrative

(MS) 420

2-2 2 15 pages Transition Exit and Interaction Plan Narrative

(MS) 420

2-3 2 15 pages Organizational Change Management (OCM) Coordination and Training Coordination Narrative

(MS) 420

2-4 2 10 pages Staff Loading Plan Narrative

(MS) 420

1. PHASE 1 NARRATIVE REQUIREMENTS

1-1. Solution Architecture and Security Narratives (30 Pages) (MS) The Bidder must provide this narrative to fulfill the requirement of this attachment.

This narrative shall not exceed thirty (30) pages, plus appendices as needed for diagrams, test plans, and detailed supporting evidence.

The Bidder shall provide a draft narrative of DL/ID Solution/System Architecture and Security that leverages the current DXP OL/VR/CC Architecture Narrative and includes the Bidder’s approach to managing system security.

SOLUTION/SYSTEM ARCHITECTURE NARRATIVE

The DL/ID Solution/System Architecture and Security Narrative must include and describe:

1. Solution Architecture Overview – Functional subsystem diagram and description of each functional subsystem that represents the business processes contained within the Solution.

2. Technology Stack – Programming languages, frameworks, libraries, patterns, servers, UI/UX solutions, software, and tools (including project management, developer, testing, and monitoring tools).

3. Business Rules Flexibility – How non-technical staff can implement and change business logic and modify business rules quickly and without coding.

4. Data Processing – The Solution’s capabilities and limits for batch and bulk data processing, including bi-directional batch flows, external data feeds, and real-time methods such as web services.

5. Logical and Physical Architecture Diagrams – Workflow, business rules, integration architecture, supported protocols, and technology.

6. Data Architecture – Logical schema and data model, including how the system implements:

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

◦ Reporting and analytics

◦ Data lineage and traceability

7. Infrastructure Architecture – Physical diagrams and lists of all infrastructure components (servers, firewalls, load balancers, IDS/IPS, cloud services, proprietary and third-party software).

8. Salesforce Detail – How Salesforce provides required functionality, where it does not, and what additional tools/accelerators are proposed.

9. Gap Assessment – Evaluation of differences between DMV’s as-is architecture and Salesforce/ MuleSoft/AWS foundational features, and any corresponding mitigation strategies.

10. Architecture Change Control – Process for DMV approval of solution architecture changes, escalation paths for vendor conflicts, and maintenance of a Solution Architecture Change Log.

11. Release Management – Contractor approach for:

◦ Coordinating releases across multiple vendors and workstreams

◦ Release impact analysis and rollback planning

◦ Release plans and roadmaps reviewed/approved by DMV

12. Implementation Overview – Integration of all solution components, including interfaces/APIs, add-ons, DMV’s Oracle Financials, Customer Communication Management, and enterprise integration platform.

13. Lessons Learned – From prior Salesforce and mainframe-to-Salesforce migrations (not to exceed five pages).

The Bidder must also provide:

14. Security Testing & Compliance

◦ Penetration testing, vulnerability scans, red team exercises, and remediation timelines

◦ SOC 2/ISO audits, zero trust architecture, PAM/key management, encryption in transit/at rest

◦ Cloud shared responsibility model (Salesforce, AWS, DMV delineation)

15. Operations, Monitoring, and Support

◦ End-to-end monitoring, alerting, and logging (application, integration, infrastructure)

◦ Capacity planning and load testing approach

◦ Support model for DMV staff, including escalation procedures

16. Governance and Decision-Making

◦ RACI matrix for architecture and release management decisions

◦ Decision turnaround SLA for change approvals

◦ Escalation pathways for cross-vendor disputes

17. Accessibility

◦ WCAG 2.1 compliance approach, plus Section 508 requirements and DMV-specific accessibility testing.

18. Innovation & Future-Proofing

◦ Plan for adapting to Salesforce’s three annual releases and MuleSoft/SaaS roadmap updates

SECURITY NARRATIVE

In addition to the above, the Bidder must address:

1. How the Solution will comply with applicable California State Information Management Manual (SIMM) and State Administrative Manual (SAM) security policies / standards and National Institute of Standards and Technology (NIST) Special Publications (SPs) and 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 Standards for Security Categorization, the ISO/IEC 27002 Code of Practices for Information Security Management, and applicable statutes and regulations. These standards shall, at a minimum, apply to all systems used in conjunction with department services; and all data where information is designated as confidential, personal, or sensitive.

2. How the project will be managed to address the policies, procedures, guidelines, and standards that protect the service continuity, confidentiality, integrity, and availability of any DMV information, including how the Contractor plans to address:

◦ Security Management

◦ Security Architecture

◦ Telecommunications and Networks

◦ Access Control Systems

◦ Application and System Development

◦ Operations Security

◦ Physical Security

◦ Cryptography

3. Description of the approach for ensuring the operationalization and utilization of the Salesforce manufacturer’s continuity plan, as well as maintaining 3rd-party product upgrades to ensure they continue to work with the SaaS, and for establishing security practices to prevent the likelihood of security breaches, including ransomware attacks, in accordance with industry best practices and

EXHIBIT E: INFORMATION SECURITY AND PRIVACY PROVISIONS.

4. Description of how changes to security policies and standards will be integrated into Contract Iterative Waterfall activities within a mutually agreed timeline.

5. If the Bidder’s Solution does not support WCAG 2.1, include how the Bidder plans to bridge the gap between its solution and WCAG 2.1.

1-2. Product-Solution Accelerator and Differentiator Narrative (15 pages) (MS)

With this narrative, the Bidder must include a list of any proposed product/solution accelerators as part of their RFP Phase 1 Response.

This narrative shall not exceed fifteen (15) pages, plus appendices for supporting documentation (e.g., case studies, certifications, test results).

Accelerators refer to software products that the Contractor has built, or third-party products that the

Contractor has configured, that are proposed to accelerate Solution development and service delivery.

Required Content

The Bidder must provide, for each accelerator:

1. Description and Purpose

◦ Functional overview, how it enhances the base PaaS solution, and business value to DMV.

2. Time/Effort Savings

◦ Estimated development effort savings quantified in staff hours saved per Contract year.

◦ Supporting evidence from prior implementations or case studies.

3. Cost Transparency

◦ All licensing, subscription, or usage costs must be detailed in the Cost Workbook.

◦ Include renewal terms, license duration, and cost escalators, if any.

4. Proven Effectiveness

◦ Evidence of prior use at comparable scale (references, case studies, success metrics).

◦ Demonstrated compatibility with Salesforce/MuleSoft/AWS in recent releases.

5. Support & Lifecycle Management

◦ Maintenance and support plan, including patching, upgrades, and vendor support model.

◦ Commitment to ensure compatibility with Salesforce’s three annual releases and other

SaaS updates.

6. Security & Compliance

◦ Security validation evidence (penetration test, vulnerability scan, SOC 2/ISO certifications).

◦ Compliance with SIMM, SAM, NIST, FIPS, ISO/IEC 27002, and DMV’s Information

Security & Privacy Provisions.

7. Integration & Risk Management

◦ Integration strategy (batch/real-time), monitoring, rollback plan, and exception handling.

◦ Dependencies on proprietary APIs or external systems must be disclosed.

8. Intellectual Property and Ownership

◦ Clear statement of ownership, licensing rights, restrictions, renewal terms, and exit strategy.

◦ Disclosure of whether the accelerator is portable to other vendors or only supported by the

Bidder.

9. Training & DMV Readiness

◦ Description of training required for DMV staff to operate/support the accelerator.

◦ Documentation to be provided to DMV (user guides, admin guides).

1-3. Conversion, Integration, and Implementation Narrative (30 pages)

(MS)

This narrative shall not exceed thirty (30) pages, plus appendices for supporting detail.

DRAFT CONVERSION, IMPLEMENTATION, AND INTEGRATION APPROACH NARRATIVE

The Bidder’s conversion, implementation, and integration approach must be documented in descriptive narrative form to describe how the Bidder will implement and integrate all Solution components during the project. The narrative must be complete and adequately address implementation of software and other components to meet all aspects of project requirements with sufficient text, diagrams, charts, and images to clearly depict the implementation of product components in the Bidder’s proposed Solution.

Required Content

The narrative must include, at a minimum, the following:

Conversion and Data Migration

1. Proposed approach for cleansing, converting, and migrating data from DMV’s legacy systems.

2. Minimum of three (3) full mock conversions plus one (1) dress rehearsal prior to cutover.

3. Reconciliation strategy including record counts, control totals, referential integrity checks, financial balancing, and exception handling.

4. Rollback and recovery plan if conversion fails or produces unacceptable variances.

5. Post-cutover smoke testing and Day-1 / Day-7 / Day-30 reconciliation checkpoints.

6. Roles and responsibilities of Contractor and DMV (including data steward participation).

Implementation and Integration

7. Approach to re-engineering legacy back-end services/systems and integrating all components.

8. Logical and physical diagrams of the integration architecture, including supported protocols, message flows, retry logic, rollback procedures, and monitoring.

9. A description of the planned functionality for each major release to support Iterative Waterfall

Product delivery processes, detailing:

◦ How the major releases planned will establish a development cycle that delivers products in an iterative fashion, within 12 to 24 months of project initiation.

◦ How the major releases will reduce cycle time for automation changes and new service delivery, with delivery timeframe reduced

◦ The approach to developing and maintaining bridges or “temporary interfaces” for each major release, including methods, processes, and tools that to be used; the approach to removing bridges or temporary solutions for each major release, including methods, processes, and tools to be used; and estimated complexity and level of effort for both.

◦ How continuous integration and continuous delivery (CI/CD) will be applied, and any tools to be used to support this approach

10. How interfaces/APIs and other non-prepackaged features will be added on

11. End-to-end integration testing strategy across multiple vendors/workstreams, including error handling and SLA monitoring.

Demonstrated Integration with DMV Components

12. The Solution must show demonstrated integration with DMV’s existing components and systems, including:

◦ DMV’s existing services, data, and databases.

◦ DMV’s existing enterprise application integration platform (service bus).

◦ DMV’s Oracle Financials/e-Business Suite for financial data reporting and reconciliation.

◦ DMV’s OpenText Extreme Customer Communication Management solution.

◦ DMV’s Mainframe Batch Printer.

◦ Any other required interfaces/APIs, including how they will be built to satisfy Solution requirements.

◦ How the proposed Solution will coexist with unchanging DMV IT/system elements, including DMV’s enterprise architecture.

Performance, Scalability, and Availability

13. Performance testing approach, including load, stress, and volume testing at DMV’s daily and peak transaction levels.

14. Demonstration of throughput and cutover feasibility within defined windows.

15. Defined SLAs for response times, batch throughput, error handling, and cutover duration.

16. High availability and disaster recovery plan, including RPO, RTO, multi-zone deployment, failover testing, and DR exercises.

Testing and Quality Assurance

17. The proposed testing strategy and methodology for system testing and acceptance testing

18. Test environments (SIT, UAT, Performance, Security, Accessibility) and their purposes.

19. Tools and processes for automated testing, penetration testing, vulnerability scanning, accessibility testing (WCAG 2.1/Section 508), and continuous integration/delivery (CI/CD).

20. Defect management process with severity, prioritization, SLA for remediation, and burn-down reporting.

Security Approach

21. The proposed security approach and security standards to be applied (out-of-the-box and any additional standards applied)

22. Security standards to be applied (SIMM, SAM, NIST, FIPS, ISO 27002, DMV Information Security

& Privacy Provisions).

23. How data will be masked or obfuscated in test environments.

24. Approach to continuous monitoring, key management, and identity/access control.

25. Shared responsibility model across DMV, Salesforce, AWS, and Contractor.

Governance and Release Management

26. Roles and responsibilities for Contractor and DMV, including a RACI matrix for decision rights.

27. Decision turnaround SLAs for approvals to prevent delays.

28. Approach for coordinating releases across multiple vendors/workstreams with rollback and hotfix planning.

29. Escalation process for conflicts between vendors or workstreams.

Organizational Change Management and Training

30. How the Bidder will collaborate with DMV’s OCM Vendor and other Workstreams to align with the DXP OCM Plan.

31. Training approach for DMV technical staff, business users, and data stewards (including reconciliation and exception handling).

32. Approach to adoption measurement and continuous improvement.

Post-Go-Live Operations and Support

30. Integration with DMV’s Service Desk, Salesforce CRM, chatbot, and IVR, if applicable.

31. Operational readiness testing (Day-1, Day-7, Day-30 checkpoints).

32. Monitoring and observability plan (dashboards, logging, alerts, telemetry).

33. SLA-driven support model for defect triage, incident response, and resolution.

1-4. HyperCare and Warranty Plan Narrative (20 pages) (MS) This narrative shall not exceed twenty (20) pages, plus appendices for supporting materials such as SLA frameworks, dashboards, escalation workflows, RACI matrices, and sample reports.

HYPERCARE & WARRANTY PLAN NARRATIVE

Contractor will provide warranty services for all portions of the modernized DL/ID solution/system across development, testing, and production environments. If a phased deployment is adopted, some solution components may be live while others are still in development. Warranty support must therefore extend across all phases of implementation and transition.

The Hypercare & Warranty Plan must describe the processes, methodologies, SLAs, roles, responsibilities, and deliverables the Contractor will use to maintain and operate the Solution, ensure enhancements are supported, and keep all documentation current.

The plan must align with EXHIBIT C: DELIVERABLES AND MILESTONES TABLE, DEL-08

(Transition Entry, Interaction, and Hypercare Sub-Plan).

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

Required Content

1. Roles and Responsibilities

• Define roles and responsibilities for Contractor, DMV, and any third parties.

• Provide a RACI matrix showing accountability for incident resolution, defect remediation, monitoring, SLA compliance, change management, escalation, documentation, DR testing, and transition-out activities.

2. Communication and Coordination

• Describe methods for coordinating with DMV ESD and CSD Service Desks, including triage workflows, escalation steps, and troubleshooting procedures.

• Define communication channels, reporting cadence, and escalation hierarchy.

3. Warranty Scope and Duration

• Define the scope of warranty coverage (e.g., defects, performance issues, security vulnerabilities).

• Clarify that the warranty applies through Hypercare until DMV accepts transition to steady-state operations.

• Identify any proposed exclusions and how they will be handled.

4. Operational Areas (ITIL-Aligned)

Describe the approach to managing the following:

• Application and System Administration

• Architecture (Application, Infrastructure, Network)

• Database and Storage

• Asset and Configuration Management

• Capacity and Availability Management

• Incident, Problem, and Service Desk Support

• Change, Release, and Build Management

• Security Management

• Performance Management and Monitoring

• Business Continuity / Disaster Recovery (DR)

• Program and Project Management during Hypercare

5. Solution Functionality & Performance Assurance

• Explain the methods, tools, and metrics used to ensure the Solution remains fully functional and meets contractual performance standards.

• Include monitoring coverage, SLA compliance, defect resolution, change validation, and performance reporting across all environments.

6. Service Level Agreements (SLAs)

Describe the Contractor’s proposed SLA framework, including:

• Response and resolution commitment timeframes for incidents and defects categorized by severity level.

• Availability targets and how uptime/availability commitments for production and other environments, including how availability will be measured and reported.

• Defect management, logged, prioritized, tracked, and resolved during Hypercare, including proposed burn-down thresholds for Hypercare exit.

• How SLA compliance will be monitored, reported, and communicated to DMV.

• Approach to vendor End-of-Life (EOL) or deprecation events: notification to DMV, timeframe for impact assessments, and proposed remediation/replacement timelines.

• Escalation process and remedies for SLA non-compliance.

7. Defect and Incident Management

• Methods for logging, triage, prioritization, and resolution of incidents/defects.

• Reporting on defect aging, trends, closure rates, and burn-down progress.

• Escalation workflow for unresolved or systemic issues.

8. Monitoring and Observability

• Describe real-time dashboards, alerts, and telemetry for monitoring performance, availability, integrations, and security events.

• Automated alerting to DMV Service Desk and Contractor support.

• Explain how monitoring integrates with DMV’s existing tools.

9. Security & Compliance

• Approach to patch and vulnerability management, including urgent issues.

• Vulnerability management cadence and remediation timelines.

• Planned cadence for security scans, penetration testing, and remediation.

• Compliance with SIMM, SAM, NIST, FIPS, ISO 27002, and DMV’s Information Security & Privacy

Provisions.

• Methods for backups, encryption, and recovery procedures for data and systems.

10. Management of Changes to the Solution

Describe how changes will be managed to support end users, including:

• Deficiency-driven changes.

• Manufacturer-recommended changes (firmware, SaaS, or software updates).

• Testing and DMV approval of changes before release.

• Coordination of change timing to minimize disruption.

• Updating documentation (system, user manuals, training materials).

• Supporting DMV staff and end users through updated training and job aids.

11. Documentation and Knowledge Transfer

• Frequency and method for updating system and training documentation.

• Knowledge transfer approach (workshops, shadowing, playbooks).

• DMV sign-off required before Hypercare exit.

12. Training and End-User Support

• Training plan for DMV technical staff, business users, and data stewards.

• End-user support (self-service resources, documentation, refreshers).

• Approach for measuring adoption and satisfaction.

13. Business Continuity and Disaster Recovery (DR)

• Annual DR exercises, including failover testing.

• Define expected Recovery Point Objective and Recovery Time Objective targets.

• Continuity planning for SaaS and third-party dependencies.

14. Contingency and Maintenance Planning

• End Of Life Contingency Planning – How vendor roadmap monitoring, impact assessments, remediation options, and documentation updates will be handled to avoid disruption.

• Preventive Maintenance Schedule – Define when maintenance will occur, expected task durations, and acceptable downtime parameters.

15. Exit and Transition Out

• Describe the transition-out plan for handover to DMV or successor vendor.

• Knowledge transfer, documentation, and DMV sign-off on completeness.

• Final post-warranty report summarizing system health, defect closure, and performance trends.

2. PHASE 2 Narrative Requirements

Only Bidders invited to Phase 2 are required to respond to the following Narrative Requirements. Bidders must submit the Phase 2 Narrative Response with their Phase 2 submission.

2-1. Transition Entry and Interaction Plan Narrative (15 pages) (MS) The California DMV has embarked upon an Enterprise Modernization Project – Digital eXperience Platform (DXP) to automate existing DMV systems and business processes utilizing Salesforce Public Sector as the primary service delivery platform. DXP is a multi-year, multi-phased effort with Occupational Licensing (OL) and Vehicle Registration (VR) implementation upgrades underway.

The Driver License/Identification Card (DL/ID) phase will be implemented through a series of Workstreams:

• Workstream 0 – Foundational requirements, Human-Centered Design (HCD), workflows, implementation plan

• Workstream 1 – Data profiling, modeling, synchronization foundation, incremental data approach

• Workstream 2 – Enhanced front-end user experience, online services, portal, shopping cart, CC/

IM integration, front-end interfaces

• Workstream 3 – Modernization of legacy back-end services, data, and related integrations

Successfully completing the DXP phases requires extensive coordination and collaboration across DMV and its multiple vendors.

Bidder Narrative Requirements

The Bidder shall provide a Transition Entry and Interaction Narrative (maximum 15 pages) describing how it will successfully integrate into the DXP project framework and fulfill all responsibilities under this Contract. The narrative must address, at minimum, the following:

1. Transition Entry Deliverables and Milestones

a. Provide a Transition Entry Plan with key deliverables (e.g., onboarding plan, knowledge transfer schedule, RACI matrix, communication protocols, toolset alignment).

b. Define transition success metrics, such as:

▪ % of knowledge transfer sessions completed on schedule

▪ % of integration defects resolved during first 90 days

▪ SLA compliance rates during transition period

c. Include a timeline with milestones for achieving transition readiness.

2. Cross-Vendor Coordination

a. Describe how the Bidder will coordinate with:

▪ DXP VR Vendor

▪ DXP Maintenance & Operations (M&O) Vendor

▪ DL/ID Workstream 0, 1, and 2 Contractors

▪ DXP Organizational Change Management (OCM) Vendor

▪ DMV and oversight bodies

b. Provide a vendor interaction playbook that includes:

▪ Dependency management and sequencing of activities

▪ Governance forums and decision-making processes

▪ Escalation procedures for conflicts/issues

3. Performance and Availability Alignment

a. Describe how the Bidder will ensure the Solution complies with all performance, scalability, and availability requirements during transition.

b. Propose KPIs and monitoring mechanisms that will be used to track compliance (e.g., response time benchmarks, uptime %, throughput metrics).

4. Organizational Change Management (OCM) Alignment

a. Describe how the Bidder’s transition activities will support DMV’s OCM efforts, including staff training, communications, and business readiness.

b. Provide examples of how technical activities will be synchronized with cultural/operational change activities.

5. Methodology Alignment

a. Explain how the Bidder will implement its transition activities under an Iterative Waterfall delivery model.

b. Address how the Bidder will reconcile Iterative Waterfall practices with DMV and other vendors’ methodologies (agile, hybrid, etc.).

c. Provide examples of cadence alignment (e.g., sprint reviews tied to waterfall milestones).

6. Governance and Risk Management

a. Propose a governance structure for cross-vendor coordination, including meeting cadence, roles, and decision rights.

b. Describe the approach to risk identification, tracking, and mitigation specific to transition entry.

c. Provide examples of measurable early-warning indicators (e.g., unresolved interface defects, missed knowledge transfer milestones).

2-2. Transition Exit and Interaction Plan Narrative (15 pages) (MS) The purpose of this narrative is to ensure a successful Solution and engagement transfer from the Contractor to DMV or to a succeeding Contractor under a new Contract. This Attachment is limited to fifteen (15) pages.

Bidder Narrative Requirements

The Bidder shall provide a Transition Exit and Interaction Narrative describing how it will fulfill all tasks and responsibilities necessary for DMV or a succeeding organization to assume full ownership and operation of the Solution. The narrative must address, at a minimum, the following:

1. Transition Exit Deliverables and Milestones

a. Provide a Transition Exit Plan with key deliverables, including but not limited to:

▪ Knowledge Transfer (KT) schedule and curriculum

▪ RACI matrix defining transition responsibilities

▪ Asset inventory of licenses, documentation, extensions, and environments to be transferred

▪ Environment decommissioning plan and checklist

▪ Governance and escalation protocols specific to transition

b. Include a timeline with milestones for each phase of transition.

c. Define completion criteria for transition acceptance (e.g., 100% asset transfer validated, KT sign-offs, SLA compliance maintained).

2. Phased Transition Activities

The narrative must describe how transition activities will be executed across the following DMV-defined phases:

a. Transition Planning – detailed work plan, roles, deliverables, risk register

b. Knowledge Transfer (KT) – structured KT sessions, tools, documentation handoff, shadowing, recorded materials

c. Verification of Knowledge Transfer – validation methods (quizzes, demonstrations, DMV sign-off, dual-run monitoring)

d. Full Cutover – controlled handover of operational responsibilities, environment removal, final acceptance

3. Cross-Vendor and DMV Coordination

a. Describe how the Bidder will coordinate transition with DMV, successor Contractor(s), and other DXP vendors.

b. Provide a transition governance model including:

◦ Meeting cadence

◦ Escalation paths

◦ Dependency management and issue tracking

c. Identify one (1) of the Key Staff roles in Scope of Work Section 12 to serve as the Transition Managerresponsible for oversight and delivery of all transition activities.

4. Performance and Availability During Transition

a. Describe how the Bidder will ensure DMV’s Solution continues to meet performance, security, and availability requirements throughout the transition period.

b. Provide measurable KPIs (e.g., uptime %, defect resolution time, incident response times).

5. Knowledge Transfer (KT) Methodology

a. Provide detailed KT methodology, including:

◦ Formats (workshops, shadowing, hands-on labs, recorded sessions)

◦ Tools (documentation repositories, knowledge portals, collaboration platforms)

◦ Validation approach (testing, DMV sign-offs, competency checks)

6. Asset Transfer Requirements

a. Describe how the Bidder will ensure complete and secure transfer of:

b. Contractor’s environments (with decommissioning and access removal)

c. All licenses, including licenses to source code

d. Product extensions, enhancements, and custom code

e. Network and Solution documentation

f. All Solution components and environments necessary for continued operation

g. All project environments, including software, hardware, and equipment

7. Security and Compliance

a. Provide plan for secure transfer of data, source code, and environments.

b. Describe access de-provisioning, credential handoff, and DMV data protection measures.

c. Identify compliance with DMV security policies and applicable state/federal requirements.

8. Risk Management

a. Identify potential risks to successful transition (e.g., staff turnover, incomplete KT, data loss).

b. Provide mitigation strategies, early warning indicators, and contingency actions.

2-3. Organizational Change Management (OCM) Coordination and Training Coordination Narrative (15 pages) (MS)

The Bidder’s Organizational Change Management (OCM) Coordination and Training Coordination approaches must be submitted as part of this narrative. This narrative is limited to fifteen (15) pages.

1. Introduction (1 page)

a. Purpose of OCM and Training Coordination Narrative.

b. Relationship to DMV Workstreams (Workstream 2, Workstream 3) and OCM Vendor.

c. Commitment to align Attachment 20 narrative with the DMV Training Sub-Plan (DEL-05-A) deliverable.

2. OCM Coordination (4–5 pages)

a. Overall OCM Coordination Approach

▪ Strategy for anticipating, assessing, and managing organizational impacts.

▪ Vendor collaboration model (OCM Vendor, Workstream 2 Vendor, other vendors).

b. Documentation of Key Solution Changes

▪ Approach to documenting solution and process changes.

▪ Tools/methods used for traceability and transparency.

c. Communication of Solution Changes

▪ Process for communicating to OCM Vendor and stakeholders.

▪ Sample templates and timing for communications.

d. Integration with OCM Vendor Roadmap

▪ How Contractor ensures OCM deliverables align with DL/ID implementation.

▪ Feedback loops to ensure adoption metrics are achieved.

3. Training Coordination – End User (4–5 pages)

a. Overview of Coordination Approach

▪ Roles and responsibilities of Contractor vs. OCM Vendor vs. Workstream 2 Vendor.

i. Use of ADDIE Model for curriculum development (aligned to DEL-05-A).

b. End User Training Components

▪ Train-the-Trainer strategy.

▪ End User Training strategy (DMV staff, DMV business partner users).

▪ Office Hours after Train-the-Trainer to reinforce knowledge transfer (NEW).

c. Skills Assessment and Gap Analysis

▪ Roadmap to skills development tied to transactions and learning objectives.

d. Curriculum Development and Standards

▪ Tools: Articulate360 (self-paced eLearning), FlexClip (accessible video). (NEW)

▪ All materials 100% 508C compliant at all stages (NEW).

▪ Deliverables: facilitator guides, learner guides, job aides, reference guides.

e. Instructional Methods and Formats

▪ Self-paced, live virtual, hands-on, blended.

▪ Recordings required for all live virtual training (NEW).

▪ Max ratio: 25 learners to 1 trainer (NEW).

f. Feedback and QA Process

▪ Contractor QA review prior to DMV review (NEW).

▪ DMV receives ≥ 2 weeks for QA per wave of materials (NEW).

▪ DMV final approval required before release.

▪ Feedback integration from UAT incidents.

g. Training Environments

▪ Training environment with refresh capabilities.

▪ Practice environment for experimentation without impacting production.

h. Training Schedule

▪ Inclusive of remedial training, refresher training, office hours, and go-live support.

4. Training Coordination – Administrative and Technical Staff (3–4 pages)

a. Knowledge Transfer Strategy

▪ Objectives, roadmap, and progressive elaboration (basic → advanced concepts).

▪ Formal and informal training schedule.

b. Support Model & RACI Integration

▪ Skills assessment and gap analysis for DMV IT staff.

▪ RACI for full solution lifecycle (operations, maintenance, enhancements).

c. Knowledge Transfer Methods

▪ Curriculum and materials for technical training.

▪ Job shadowing, coaching, and on-the-job training opportunities.

d. Instructional Methods & Formats

▪ Self-paced, live virtual, hands-on labs, blended.

▪ Progressive elaboration of training modules for advanced IT support skills.

e. Measurement & Reporting

▪ Mechanisms to measure progress toward skill transfer.

▪ Feedback incorporation cycle (ongoing).

5. Conclusion (≤1 page)

a. Summary of commitment to coordination with OCM and Workstream vendors.

b. Assurance that this Attachment 20 narrative is aligned with DEL-05-A Training Sub-Plan requirements.

c. Emphasis on compliance (ADDIE, 508C, Blackboard LMS, Articulate360/FlexClip, QA process).

2-4. Staff Loading Plan Narrative (10 pages) (MS)

1. The purpose of this narrative is to ensure that the Bidder provides a clear and detailed resource allocation across all project SDLC phases, including Transition Entry, Development, and Transition Exit from Hypercare and Warranty. The Staffing Plan shall demonstrate how the proposed staffing approach supports successful delivery of the project.

2. The Staff Loading Plan Narrative (Narrative 2-4) must demonstrate the adequacy and appropriateness of proposed staff assignments to project tasks across the Workstream 3 system development life cycle (SDLC):

◦ Planning

◦ Design and Transition Entry into Iterative Waterfall Development

◦ Development / Coding / Implementation

◦ Testing

◦ Deployment

◦ Maintenance and Transition Exit through Hypercare and Warranty.

Bidder Narrative Requirements This narrative must be arranged into the following sections:

1. SDLC Phases, Tasks, Deliverables/Milestones, and Staffing Overview

For each SDLC phase, the Bidder must describe:

• The tasks it intends to perform during that SDLC phase.

• The project tasks identified may be used for potential payment milestones to the

Contractor, which will be confirmed during contract negotiation.

• The Workstream 3 Deliverables and/or Milestones produced upon completion of the tasks within the SDLC phase (refer to EXHIBIT C: DELIVERABLES AND MILESTONES TABLE)

• Skills and qualifications of staff needed to complete the tasks, and whether these skills and qualifications will be met by the Contractor’s staff, contractors, partner resources, or a combination of some or all these types of resources.

• The full-time equivalent (FTE) staff allocated for the tasks, the location of the staff (on-site at DMV, remote within the U.S., remote offshore, or hybrid on-site and remote), and whether each identified staff member is designated as Key Staff or Non-Key Staff.

• The DMV only specifies 11 Key Staff Roles as mandatory (scored), and gives the Bidder the flexibility to specify an additional 9 Key Staff Roles (scored) for a total of 20 Key Staff, and any number of Non-Key Staff roles (scored only in the context of this narrative) so long as no more than 75% of hours are allocated to Non-Key Staff.

▪ See Part 1 SECTION 3.3.3. KEY STAFF QUALIFICATIONS (M) (DUE WITH

PHASE 2 RESPONSE), SECTION 11. CONTRACTOR’S ROLES AND

RESPONSIBILITIES, and SECTION 12. KEY STAFF QUALIFICATIONS AND SKILLS for a more detailed list of staffing requirements.

• FTE staffing represents 1,900 hours per year per individual, or 158 hours per month per individual. An individual identified as Key Staff is required to work full-time (158 hours per month assigned or 1,900 hours per year assigned).

2. Staff Loading/Unloading Method and Approach

The Bidder will describe in this section:

• Its approach to staff ramp-up, peak staffing, and ramp-down across the contract period.

• Its justification for how staffing aligns with workload intensity at key phases (e.g., data migration, mock runs, UAT, cutover, Hypercare).

• Its rationale for phasing of resources (why certain skills enter or exit at specific points).

3. Alignment to Deliverables and Milestones

The Bidder will describe in this section:

• How it has cross-walked staff assignments to contract deliverables (DELs), milestones, and project SDLC phases.

• How its deliverable-to-staffing approach will ensure adequate resourcing and successful deliverable delivery.

• How it has identified staffing required for high-risk, high-effort activities (e.g., legacy integration, defect remediation, performance tuning).

4. Work Location Requirements

The Bidder will describe in this section:

• Its rationale for the staff work location (on-site at DMV HQ, remote within California, remote within the U.S., hybrid on-site and remote, or offshore) for each role.

• How it will ensure compliance with DMV requirements for security-sensitive roles (e.g., data migration, infrastructure, cutover).

• Its justification for any offshore roles, including impact on time zone coverage, communications, and security.

5. Staff Continuity and Risk Mitigation

The Bidder will describe in this section:

• Its approach to ensuring continuity of Key Staff and critical technical roles.

• How it intends to provide mitigation strategies for:

◦ Attrition and backfill

◦ Knowledge retention across staff transitions

◦ Surge capacity to support peak workloads

• Identify early warning indicators DMV should expect if staffing sufficiency is at risk.

ATTACHMENT 18: NARRATIVE REQUIREMENTS