Exhibit G _ JMS Project Gates and Deliverable.pdf

Exhibit G - JMS Project Gates and Deliverable Acceptance

Project Gates and Deliverable Acceptance

Quality Stage Gates

The purpose of the Quality Gate process is to assist in monitoring the progress of the project and schedule compliance. The County has identified five primary stage gates as follows:

• Planning

• Requirements/Design

• Configure/Build

• User Acceptance

• Cutover

Expected deliverables and implementation activities have been grouped by Phase into sequential activities that largely follow a waterfall approval process for major milestones. Iterative deliverables such as agile configuration and testing of modules in phases can be accommodated within a required stage gate. Completion and acceptance of all activities and deliverables at a defined stage trigger a formal Quality Stage Gate Review.

The Quality Stage Gate Review is a higher-level review presented to representatives of the County and serves as a checkpoint to ensure all stakeholders are briefed on material changes to scope, design considerations and planning activities. Figure below provides a high-level outline of the anticipated Quality Stage Gate Process.

The Quality Stage Gate Review process is depicted in the diagram below which represents each phase and sub-phase of the project with five Quality Stage Gates and the acceptance criteria for each stage gate. Stage gates are represented by the red diamonds in the diagram below.

Quality Stage Gate Review Process

Project Implementation Reporting

Weekly Reports. The Vendor is expected to provide a status report each week to the County as well as the IV&V Vendor within two business days following the weekly Project Status Meeting, beginning the week after the Kickoff Meeting. The County will provide the template. This report highlights tasks completed, tasks planned for the following week, all Project risks and issues, deliverables, milestones, and important tasks. The report will conform to Project Management requirements, Functional Requirements, and Non-Functional Requirements.

Monthly Reports. The Vendor shall provide a Monthly Status Report to the County no later than the third business day of the month following the reporting month. This report shall summarize all items reported in the weekly summary report. This report will conform to Project Management requirements, Functional Requirements, and Non-Functional Requirements.

Ad Hoc Reports. The Vendor shall produce and submit additional reports that County may require on a daily, weekly, or monthly basis, as deemed by the County to be necessary. Each of these reports will be due within five business days (unless otherwise mutually agreed), upon written request of the County.

Stage Gate Closeout Report. The Vendor will develop and submit a Stage Gate Closeout Report to the County no later than seven business days following the close of each Stage Gate. All deliverables of each Stage Gate shall be accounted for and accepted by the County.

Post-Implementation Report. At the end of Project implementation, the Vendor will develop and submit to the County as well as the IV&V Vendor a Post-Implementation Report no later than 20 business days following the end of the Deployment Stage Gate. This report will conform to Project Management requirements, Functional Requirements, Non-Functional Requirements.

Project Closeout Report. At the end of the Project, the Vendor will develop and submit to the County a Project Closeout Report no later than 20 business days following the end of the Security Stage Gate. This report will conform to Project Management requirements, Functional Requirements, Non-Functional Requirements.

DELIVERABLE REQUIREMENTS & ACCEPTANCE

Part 1 – Project Deliverable

Project deliverables are generally either Document Deliverables or Software-based Deliverables. These two types of deliverables will follow unique acceptance and approval processes as follows:

1.1 – Document Deliverables

a. The Vendor will deliver all Document Deliverables to the County accompanied by a Deliverables Acceptance Form by the delivery date as established in the County’s Detailed Project Plan. If the Vendor is unable to meet the established delivery date, it will provide the County with written notice at least two (2) weeks prior to the delivery date. Such notice will specify the proposed new delivery date.

b. Unless otherwise noted, the County will review the Document Deliverable within ten business days of receipt of the Document Deliverable and deliver to the Vendor a Review Record which either:

a. Indicates the County has signed off on the Document Deliverable; or

b. Documents its comments on where and how the Document Deliverable fails to conform to the relevant Specifications.

Should the County not provide acceptance sign-off, or if no changes or comments are requested within the specified acceptance review period, the Vendor’s Project Manager will escalate the delay in sign-off to the County’s Project Manager for follow-up and action. Delays in sign-off can delay the County project's overall timeline. The Vendor’s Project Manager will assess any potential delays and provide this information as a part of the escalation process.

If the Vendor does not deliver the Document Deliverable by the established delivery date, the ten-business day period (unless otherwise noted) will be extended by the period reasonably required by the County to reallocate resources to perform the review.

a. If the Review Record indicates the County has not signed off the Document Deliverable, the Vendor will, within three business days from the time the County delivers the Review Record, respond in writing addressing the points raised by the County in the Review Record and, as appropriate, amend the Document Deliverable.

b. The County will, within three business days of receiving a written response to the points raised in the Review Record and/or the amended Document Deliverable, notify the Vendor in writing the County considers that:

a. All the points raised in the Review Record have been addressed and/or amendments have been incorporated into the Document Deliverable, and the County signs off the Document Deliverable; or

b. If not all the points raised in the Review Record have been addressed and/or not all the amendments, have been incorporated into the Document Deliverable, in which case the County will provide a revised Review Record documenting its further comments on the Document Deliverable.

c. The parties will repeat the above processes until the County signs off the Document Deliverable per the acceptance process for Document Deliverables. Should the County not provide acceptance sign-off within the specified acceptance review period, the Vendor’s Project Manager will escalate the delay in sign-off to the County’s Project Manager for follow-up and action. Delays in sign-off can delay the County project's overall timeline. The Vendor’s Project Manager will assess any potential delays and provide this information as a part of the escalation process.

1.2 – Software-based Deliverables

a. Each Software-based Deliverable will progress through the established test phases in accordance with the County Testing Plan.

b. The County will sign off on Test Plan developed by the Vendor in conjunction with County representatives. Test Cases for User Acceptance Testing will be provided by the County.

c. The Vendor will execute each Test Phase in accordance with the Testing Strategy and Approach included as a part of the SOW, and as further defined in the Detailed Test Plan. Test Phases include the following activities:

i. Environment Setup Verification

ii. Unit Test

iii. System Test

iv. User Acceptance Test

d. The Vendor may only allow a Software-based Deliverable to enter a Test Phase if the entry criteria for the applicable Test Phase, as set out in the Detailed Test Plan, have been met or if otherwise agreed by both parties in writing, and/or as further defined in the Detailed Test Plan.

e. A Software-based Deliverable may only exit a Test Phase if Vendor has demonstrated to the County in a Test Summary Report that the exit criteria for the Test Phase, as set out in the Detailed Test Plan, have been met and the County has signed off the Test Summary Report in accordance with the established sign-off process.

1.3 – User Acceptance Testing

a. For User Acceptance Testing (UAT), the County will leverage County-provided Use/Test Cases as modified or developed for System Testing. UAT will be performed by the County in accordance with the Vendor Test Strategy and the relevant Detailed Test Plans. The County will manage UAT and provide testers to complete UAT. The successful Responder will support UAT by providing test environment support and batch execution.

b. The User Acceptance Test aims to determine whether the tested System Deliverables conform to the Requirements documented in Functional Requirements and Non-Functional Requirements (as they may have been amended by the parties, in writing, during the design and configuration process).

c. The successful Responder will provide an updated requirements traceability matrix to the UAT team, which maps each Requirement to the functionality or system component which fulfills that requirement.

1.4 – Go-Live Criteria

Preliminary list of go-live criteria for assessing the system and County readiness for Go Live. It is a task within the Deploy Phase to finalize these criteria:

1) System Functionality – The successful Responder solution configured in support of the Implementation meets the functional and operational requirements as specified in the Fit/Gap Analysis and as evidenced by the County’s acceptance of UAT. Additionally, the system will be accepted for operation use when it satisfies the following four (4) requirements:

a. No Severity 1 issues (defined below)

b. No Severity 2 issues

c. All Severity 3 issues have workarounds identified, agreed with the County, and communicated to users

d. All Severity 4 issues identified, agreed, and documented

2) Data Readiness – Data migrated from source systems to the Vendor has completed QA and satisfies the following four (4) requirements:

a. No Severity 1 issues (defined below)

b. No Severity 2 issues

c. All Severity 3 issues have workarounds identified, agreed with the County, and communicated to users

d. All Severity 4 issues identified, agreed, and documented

3) Reporting – All reports identified elsewhere in the SOW to be completed by Vendor have been tested and accepted by the County. Acceptance criteria are:

a. No Severity 1 issues (defined below)

b. No Severity 2 issues

c. All Severity 3 issues have workarounds identified, agreed with the County, and communicated to users

d. All Severity 4 issues identified, agreed, and documented

4) User Readiness – All affected County departments/divisions have completed the training according to the Training Plan in order to prepare them to use the solution on Day 1, including:

a. All classroom training completed per the Training Plan

b. County department/division personnel have received soft copies of all finalized training materials

5) User Support – User support requirements defined and accepted by the County for the two-month post go-live support period. All post go-live support staff are named and identified two weeks prior to go-live.

a. Go-live plan is documented and accepted and includes the specific duties and expectations of the on-site support staff

b. Process for capturing, logging, and resolving operational issues during the post go-live support period is documented and agreed upon

c. Support escalation process documented and agreed upon

6) Operational Readiness – Support infrastructure, equipment, tools and procedures are in place and ready for use. Operational staff are trained (user and system administration). Technical support staff are in place and prepared to handle reporting, prioritizing and fixing problems.

a. Planning, Help Desk, and Change Control processes in place

b. User and System Administration training completed per Training Plan

c. Knowledge Transfer post go-live to System Admins

7) External Factors – Interfacing Organizations/Departments, stakeholders, and affected staff have been communicated with, and the County is ready for launch

8) Go Live Plan – The Go Live Plan is developed and accepted by business owners, and has been vetted via a dry run so that any potential gaps are identified and resolved prior to go-live

Severity Level Description

1 This is a “must fix” problem, a “showstopper.” The problem is causing a major system error, fatal error, serious database corruption, serious degradation in performance, major feature malfunction, or is preventing a major business goal from being realized. The problem does not have a workaround that is reasonably acceptable to the corresponding end-users.

2 This is a problem that is causing significant loss of feature functionality, but the system can recover from the problem, and it does not cause total collapse of the system. The system does not meet a business goal or a portion of a business goal; performance degradation is minor, but not within established exit criteria; or minor database issues may exist (e.g., single rows or fields may be locked). The problem does not have a workaround that is reasonably acceptable to the corresponding end-users.

3 This is a problem that is causing minor loss of feature functionality.

Optional workarounds reasonably acceptable to the corresponding end-users are available.

4 These are minor issues, misspellings, cosmetic changes, etc.

Vendor will also follow the Quality Gate process when it comes to the commencement of work and final acceptance of deliverables and exit of a quality gate. The purpose of the Quality Gate process is to assist in monitoring the progress of the project and schedule compliance. However, the primary project monitoring documents will be the Project Management Plan (PMP) and the Project Schedule.

Both the County and Vendor recognize that there will be instances requiring changes to the deliverable acceptances flow as outlined. When these instances occur, the County and Vendor PMs will discuss them in advance to reach mutual agreement and will communicate the proposed change to the appropriate stakeholders from both Parties, seeking their assent where necessary. A mutually agreed-to change to the flow of the Quality Gate process with no impact to project scope and schedule will not require a change request but will be documented in the Project Management Plan and the Work Breakdown Structure.

Vendor will meet with the County to develop the acceptance criteria for each deliverable. Vendor will subsequently develop a Deliverable Expectation Document (DED) for each deliverable. The County will provide input as required or requested by Vendor within five business days of the request by Contractor.

Deliverable Development and Acceptance Process

Deliverable Step DED Process Non-DED Process

Deliverable Definition

Vendor will meet with the County to refine the acceptance criteria for each deliverable beyond what is included in this statement of work

Vendor will subsequently develop a DED for each deliverable.

County will provide input as required or requested by Vendor within five business days of the request by Vendor.

The County will then accept and sign-off the DED.

Acceptance criteria for each deliverable is defined within this statement of work

Deliverable Development and Submittal

Vendor will develop and submit each deliverable following the criteria and standards defined in the respective

DED.

Vendor will develop and submit each deliverable following the criteria and standards defined in this scope of work

Deliverable Review

County will facilitate a detailed walk-through review of each deliverable with assigned project team resources.

After reviewing each deliverable, County will then prepare a written Deliverable Review Report, communicating to Vendor any issues and items to be resolved with the deliverable that does not meet the criteria established in the DED prior to formal acceptance.

The time frame for County to review a deliverable will be defined in the DED, based on what is defined in Deliverable Acceptance Process above.

County will facilitate a detailed walk-through review of each deliverable with assigned project team resources.

After reviewing each deliverable, County will then prepare a written Deliverable Review Report, communicating to Vendor any issues and items to be resolved with the deliverable that does not meet the criteria established in this statement of work prior to formal acceptance.

The time frame for County to review a deliverable is based on what is defined in this statement of work

Deliverable Step DED Process Non-DED Process

Deliverable Revision

Unless a change is disputed, Vendor will address feedback received in the Deliverable Review Report, updating the deliverable for final review and acceptance by the County.

This time frame will generally be two business days.

Unless a change is disputed, Vendor will address feedback received in the Deliverable Review Report, updating the deliverable for final review and acceptance by the County.

This time frame will generally be two business days.

Review Period/Timeline

The default review period/timeline is 5 days; however the DED form can supersede the default review period/timeline based on mutual agreement between the Parties.

The default review period/timeline is 5 days for document deliverables and in accordance with the test plan for software deliverables however this can be extended based on mutual agreement between the Parties.

Part 2 – Requirements and Descriptions

2.1 – System Requirements & Design Deliverable Descriptions

Deliverable Name Type DED Required Project Stage Deliverable Requirement (Vendor) Deliverable Requirement (County)

1A - Project Kickoff Presentation

Written, No Planning

1. Conduct a formal onsite Kickoff meeting. The objective of this meeting is to communicate the objectives of the project, gain commitment from the team and explain the roles and responsibilities of each stakeholder. During the meeting the Vendor will discuss the project scope, roles and responsibilities, deliverables, and timeline, including but not limited to the following:

a. The overall project objectives, project plan, management of project schedule, risks, change, quality, communication, resources, and the various deliverables associated with the complete System Development Life Cycle (SDLC) of the Project.

b. The key stakeholders required to review and validate information relative to all steps of the project throughout the SDLC.

c. The process to provide input to the strategic and tactical reports on a regular basis.

d. Project performance measurements and critical success factors.

2. Vendor will create, collaborate, and review the Project Initiation presentation content with Key Project Stakeholders as directed by the County. The presentation will be reviewed by the County prior to presenting it and will include, at minimum, the following topics:

a. Project Overview.

b. Project Schedule (high level).

c. Objectives and Definitions.

d. Phases and Quality Stage Gates

e. Artifacts

f. Roles and Responsibilities.

g. Keys to Success.

h. Next Steps.

i. Questions and Answers (Q&A).

j. Resources.

1. Key County staff co-present on the objectives, values, and expectations of the project, and the importance of the project to County’s overall vision.

2. Ensure participation in the project planning activities as this will be a pre-requisite to the development of the kick-off presentation.

3. Ensure participation in the Project Kickoff Meeting.

Deliverable Name Type DED Required Project Stage Deliverable Requirement (Vendor) Deliverable Requirement (County)

3. Vendor will capture any decisions or agreements from the kickoff meeting and submit the documentation to the County for review and acceptance.

1B - Project Management Plan

Written Yes Planning Project Management Plan: Vendor will develop and continuously update as needed, but no less than every three months, a Project Management Plan that includes the following sub-plans (as defined by PMBOK):

1. Scope and Requirements Management Plan – Project Scope Management includes the processes required to ensure the project completes all the work required, and only the work required, to complete the project successfully. Managing the scope is primarily concerned with what is in and out of the scope of the project and the traceability of scope items throughout the project. The Scope and Requirements Management Plan will include the following elements:

a. Define the scope of the project (scope statement) and the product (specified features, functions, etc.)

i. Product

ii. Deliverables

iii. Services

iv. Scope Exclusions

b. Define the project approach and methodology

c. Define the requirements management approach

i. How requirements will be planned, tracked, and reported

ii. Configuration management activities such as how changes will be initiated;

how impacts will be analyzed; how they will be traced, tracked, and reported;

as well as the authorization levels required to approve these changes

iii. Requirements prioritization process

iv. Metrics that will be used and the rationale for using them

v. Traceability structure that reflects the requirements attributes captured in the Requirements Traceability Matrix (see 3B – Requirements Traceability Matrix)

d. Define the work breakdown structure (WBS)

1. Ensure participation in meetings and activities.

2. Create, in conjunction with The Vendor, project performance metrics.

Deliverable Name Type DED Required Project Stage Deliverable Requirement (Vendor) Deliverable Requirement (County)

i. Work to be completed by project team to accomplish the project objectives and create the required deliverables, decomposed into work packages used to group the activities, work products and deliverables. (WBS is an input to the Project Schedule)

e. Define scope validation and acceptance process for project deliverables.

Define the entrance and exit criteria for each Quality Stage Gate.

2. Schedule Management Plan – This plan establishes the policies, procedures, and documentation for planning, developing and managing the project schedule. The Schedule Management Plan will:

a. Define the scheduling method (e.g., critical path, agile/iterative, Kanban)

b. Process for baselining the schedule and schedule updates

c. Provide a milestone list

3. Cost Management Plan – This plan aligns the project budget with the WBS to track progress and financial performance. The Cost Management Plan will be used on an ongoing basis to do the following:

a. Define standard thresholds and criteria for escalation.

b. Continually monitor and analyze project financial performance for risk, negative trends, or early indicators of unfavorable performance.

c. Provide performance reports based on the County and Vendor’s developed criteria.

4. Quality Management Plan – The Quality Management Plan addresses the management of the project and the deliverables of the project. Quality measures and techniques are specific to the type of deliverables being produced and will be specified in the Deliverable Expectations Document for project deliverables. The Quality Management Plan will include the following elements.

a. Defined quality assurance responsibilities.

b. Detailed definition of all deliverables by phase and associated acceptance criteria.

c. Project deliverable review and acceptance process.

d. Regularly scheduled reviews of key project phases, stage gate exit criteria and milestones.

Deliverable Name Type DED Required Project Stage Deliverable Requirement (Vendor) Deliverable Requirement (County)

5. Resource Management Plan – The Resource Management Plan includes the processes to identify, acquire, and manage the resources required to successfully complete the project successfully (both human resources and physical resources). The Resource Management Plan will include at a minimum:

a. Identification of resource requirements (Vendor and County), activities, roles and responsibilities, skill requirements, expertise, required level of engagement and duration

b. Define training requirements for project resources (if needed)

c. Define organizational structure for resources (reporting and coordination of project tasks)

d. Defined process to replace resources who have left the project

e. Office Space, equipment, background checks, access requirements, meeting room requirements, etc.

6. Risk Management Plan – The purpose of the Risk Management Plan is to identify and manage risks that can have a positive or negative effect on the project objectives if they occur. The object of Risk Management is to exploit or enhance positive risks (opportunities) while avoiding or mitigating negative risks (threats). THE Vendor will develop a Risk Management Plan which will be used on an ongoing basis to do the following:

a. Create and update the Risk Assessment Log.

b. Anticipate and identify risks.

c. Identify the severity and quantify the potential impact of each identified risk.

d. Quantify the probability of each identified risk.

e. Support the development of risk mitigation plans for each identified risk.

f. Provide guidance for assessing the efficacy of risk mitigation actions.

g. Describe work products and processes for assessing and managing risks.

h. Detail the escalation and remediation mechanisms for risks.

i. Detail how risks and issues will be tracked and reported and the format of risk and issues reports (depth, detail, and content).

7. Communications Management Plan – The Communication Management Plan defines the communication activities for the project, including method, Deliverable Name Type DED Required Project Stage Deliverable Requirement (Vendor) Deliverable Requirement (County) cadence and artifacts for both internal (project team) and external stakeholders. The Communication Management Plan includes:

a. Types of meetings and frequency including, status meetings, stakeholder meetings, project scrum meetings

b. Communication methods (email, reports, presentations, etc.)

c. Distribution methods

d. Approach for documenting and distributing meeting minutes

e. Collaboration tools

8. Stakeholder Management Plan – The Stakeholder Management Plan provides a structured approach to the identification, prioritization, and engagement of all stakeholders. The Stakeholder Management Plan includes:

a. Identification of all project Stakeholders (both internal and external and expectations and level of interest/support/influence in the project

b. Stakeholder register (position, location, contact details)

c. Engagement plan for each stakeholder (communication / engagement strategy)

9. Change Management Plan – This plan covers both technical and non-technical changes and will be jointly developed by the Vendor and County. The Change Management Plan will be used on an ongoing basis to do the following:

a. Track all Change Requests, including providing a status. It will contain at a minimum the following:

i. Tracking Number and date of the request.

ii. Priority Rating of the request.

iii. Category of the Request (Technical or Non-Technical), as long as the non- Technical changes do not include Organizational Change Management (OCM) changes.

iv. Scope Determination (In Scope or Out of Scope).

v. Requestor Information (name, title, department, contact information).

vi. Impact of Requested Change (budget, schedule, staffing, etc.).

vii. Benefit of the Requested Change.

Deliverable Name Type DED Required Project Stage Deliverable Requirement (Vendor) Deliverable Requirement (County)

viii. Urgency of the Requested Change (e.g., routine, urgent, immediate, critical).

ix. Assessment of contract language and alterations necessary.

ix. Authorization or Denial of the Change Request.

x. Status of the Change (in work, not started, on hold).

xi. Required Completion Date.

xii. Point of Contact for follow-on action(s) required.

xiii. Due date for next action.

b. Analyze the impact of Change Requests. The impact of the proposed Change Request will be documented in the Change Request Form.

c. Authorize or Deny the Request. The authorization or denial will be in writing using the Change Request Form.

d. Change Orders will be signed by the Vendor Project Manager and County Contract Authorized Representative and any contract amendments required signed by all original parties prior to execution of any work related to the change.

The Vendor Responsibilities

1. Shall facilitate and lead the discussions to finalize the various sub-plans within the Project Control document.

2. Shall incorporate related decisions made during the project planning and kickoff meetings into the plan.

3. Maintain complete and up-to-date team organization charts as well as contact lists that provide names, titles, phone/pager/cell phone numbers, and email information for all personnel assigned to the project.

4. Shall create, in conjunction with the County, project performance metrics.

1C – Project Schedule

Written Yes Planning Project Schedule: The Vendor will provide a Project Schedule including Work Breakdown Structure, Resource Allocation, Gantt charts and a project calendar in a tool agreed upon by the parties and developed and maintained in accordance with the best practices outlined in the Project Management Body of Knowledge (PMBOK).

1. Provide input into the Project Schedule.

Deliverable Name Type DED Required Project Stage Deliverable Requirement (Vendor) Deliverable Requirement (County)

The Work Breakdown Structure (WBS) will define the project’s overall objectives by describing the project tasks, deliverables, milestones, and resourcing.

1. The WBS will include:

a. A consolidated view of the activities, activity descriptions, and activity durations assigned to the County and the Vendor.

b. Resources (County, Vendor, and third-party vendors) assigned to each activity and their required level of effort.

c. A list of all required project deliverables tied to the appropriate project milestones.

d. Identification of all key Project Milestones.

e. Deliverable approval periods in concert with County’s DED process as described in the Project Management Plan Deliverable Development and Acceptance Process.

f. A critical path analysis and reporting process.

The Vendor Responsibilities

1. Shall develop the Project Schedule with input from the County PM and others designated by the County.

2. Shall baseline the Project Schedule

3. Shall maintain the Project Schedule on an on-going basis throughout the life of the project and update it, in collaboration with the County’s PM as necessary, but no less than weekly to reflect the accurate status of the project.

4. Shall ensure the availability of the Project Schedule in a central location.

1D – Change Log

Written No Planning Change Log: The Vendor Project Manager will maintain a project Change Log that tracks all proposed change orders and will include at a minimum the following:

a. Tracking Number and date of the request

b. Priority Rating of the request

c. Category of the Request (Technical or Non-Technical), as long as the non-technical changes do not include Organizational Change Management (OCM) changes

1. Follow the project change management processes

2. Approve, Deny, Defer Change Orders in accordance with change management processes

Deliverable Name Type DED Required Project Stage Deliverable Requirement (Vendor) Deliverable Requirement (County)

d. Scope Determination (In Scope or Out of Scope)

e. Requestor Information (name, title, department, contact information)

f. Impact of Requested Change (budget, schedule, staffing, etc.)

g. Benefit of the Requested Change

h. Urgency of the Requested Change (e.g., routine, urgent, immediate, critical)

i. Authorization or Denial of the Change Request

j. Contract Amendment Status

k. Status of the Change (in work, not started, on hold)

k. Required Completion Date

l. Point of Contact for follow-on action(s) required

m. Due date for next action

Vendor Responsibilities

1. Shall maintain the Change Log on an on-going basis throughout the life of the project and update it, in collaboration with the County’s PM as necessary, but no less than weekly to reflect the accurate status of the project.

2. Shall ensure the availability of the Project Change Log in a central location.

3. Shall update the Requirements Traceability Log based on Change Order decisions

1E – Risk Log

Written No Planning Risk Log: The Vendor Project Manager will maintain a project Risk Log that tracks all Risks and Issues and will include at a minimum the following:

a. Date Risk was Identified

b. Description of Risk

c. Impact Description (budget, schedule, staffing, etc.)

d. Severity of the Risk

e. Probability of the Risk

f. Risk Mitigation Strategy

1. Follow the project risk management processes

2. Participate in risk identification and mitigation activities

Deliverable Name Type DED Required Project Stage Deliverable Requirement (Vendor) Deliverable Requirement (County)

g. Action Items and Assignment

h. Status of the Risk (Open, Closed)

Vendor Responsibilities

1. Shall maintain the Risk Log on an on-going basis throughout the life of the project and update it, in collaboration with the County’s PM as necessary, but no less than weekly to reflect the accurate status of the project.

2. Shall ensure the availability of the Project Risk Log in a central location.

3. Shall provide an update on key risks and issues on Weekly Status Reports

1F - Decision Log

Written No Planning Decision Log: The Vendor Project Manager will maintain a Decision Log that will track all major project decisions. The decision log will include at a minimum the following:

a. Issue/ Decision No

b. Status (open, closed)

c. Description of Issue

d. Decision Description

e. Priority (L/M/H)

f. Raised by

g. Owner Decision Maker

Vendor Responsibilities

1. Shall maintain the Decision Log on an on-going basis throughout the life of the project and update it, in collaboration with the County’s PM as necessary, but no less than weekly to reflect the accurate status of the project.

2. Shall ensure the availability of the Decision Risk Log in a central location.

3. Shall provide an update on key issues and decisions on Weekly Status Reports

1. Participate in Issue resolution / project decision making

1G – Monthly Project Management

Written Yes

Planning

Write County specific requirements for Monthly Project Management

1. TBD

Deliverable Name Type DED Required Project Stage Deliverable Requirement (Vendor) Deliverable Requirement (County)

2A – Gap Analysis Report

Written, Yes Requirements/Design Gap Analysis Report. The purpose of the Gap Analysis Report is to provide a detailed description of how each functional and non-functional requirement will be met within the software solution. Where the solution does not adequately address a requirement, detailed remediation recommendations will be proposed to the County for decision. The content of the report will include at a minimum:

a. Introduction

b. Purpose

c. Scope

d. References & Related Documentation

e. Glossary of Terms

f. Classification Approach (e.g., Standard Feature, Configuration, Gap, etc.)

g. Requirements Analysis (Functional & Technical) – per functional/technical group

i. Analysis Approach

ii. Client Objectives (per functional/technical group)

iii. Scope of Analysis

iv. Client Business Overview (capabilities, systems in use, processes, reports,

v. Analysis

vi. Recommendations

h. List of Gaps with Proposed Remediation Options

i. Proposed Gap Remediation

Vendor Responsibilities

Identify how all requirements will be addressed within the solution, identify gaps, identify options to resolve gaps, document gap resolution decisions in the Project Decision Log. Resolutions can include modifications to business processes, solution enhancements, removal from scope, etc.

1. Confirm and accept gap analysis, select resolution for each gap.

Deliverable Name Type DED Required Project Stage Deliverable Requirement (Vendor) Deliverable Requirement (County)

2B – Requirements Traceability Matrix

Written

Yes Requirements/Design Requirements Traceability Matrix. The purpose of the Requirements Traceability Matrix (RTM) is to document and trace the requirements identified by the County to the system being implemented. The RTM is used to track each project requirement from its origin through the various Phases of the project. It provides a means to track requirements throughout the project life cycle helping to ensure that requirements approved in the requirements documentation are delivered at the end of the project. It also provides a structure for managing changes to project scope. Elements of an RTM should include at a minimum:

a. Requirements ID

b. Source of Requirement (SOW, Gap Analysis, Stakeholder Request, etc.)

c. Create Date

d. Description of Requirement

e. Technical / Functional Grouping

f. Status of Requirement (proposed, approved, rejected, gap, etc.)

g. Classification (e.g., Critical, Important, Useful)

h. Configuration status

i. Design status

j. Development status

k. Test Case ID

l. Test Status

Vendor Responsibilities: Maintain Requirements Traceability Matrix (real-time), provide the County access to RTM, publish reports derived from Traceability items, identify change items, and generate change orders.

1. Review & Validate RTM, approve/deny change orders.

2C – Software Architecture Document

Yes Requirements/Design Software Architecture Document: The Software Architecture Document (SAD) provides a comprehensive overview of the technology infrastructure and all its components. A software architecture document is a map of the software used to see, at a glance, how the software is structured. It helps to understand the software’s modules and components without reviewing the code. It is a tool to communicate with others— developers and non-developers—about the software. The document is intended to communicate the overall System Architecture – including hardware and software – so the County may proceed with the implementation of the necessary resources, and to

1. Provide input based on County architectural requirements. Review & Validate SAD.

Deliverable Name Type DED Required Project Stage Deliverable Requirement (Vendor) Deliverable Requirement (County) address architectural compliance with County standards and best practices. Elements of a SAD should contain at a minimum:

a. Solution Architecture Overview

b. Architecture Components

c. Architecture Diagrams

d. Applications

e. Infrastructure

f. Sites

g. Middleware

h. Integration

i. Interfaces

j. Processes

k. Environments

l. Hosting Service Specifications

m. Licenses / Agreements

n. Security (end-user authentication, access control configuration)

o. Software/Hardware requirements

p. Auditing

q. Configuration Management Plan

r. Help Content Development & Maintenance

Vendor Responsibilities: Tailor SAD to County context (hosting, user authentication, environments, licensing, etc.).

2D – System Configuration Specifications

Yes Requirements/Design System Configuration Specifications: The purpose of the System Configuration Specifications (SCS) is to identify the System Configuration Baseline addressing the software components and interfaces and the system parameters, focusing on the configuration items which may affect the functionalities. The SCS describes how the system will be configured to match its functions to the business processes. The actual

1. Provide input based on County specific configuration requirements.

Review & Validate SCS.

Deliverable Name Type DED Required Project Stage Deliverable Requirement (Vendor) Deliverable Requirement (County) configuration process usually occurs on-site after system installation and will be performed by the system vendor.

Elements of a SCS should contain at a minimum:

a. Hardware Configuration

b. Operating System Configuration

c. Software Configuration

d. Interface Configuration

e. Data Configuration

Vendor Responsibilities: Work with County Subject Matter Experts to tailor the configuration based on gap analysis review / decisions. Provide spreadsheets to the County to document configuration values. Update Requirements Traceability Matrix.

2E – System Design Specifications

Yes Requirements/Design System Design Specifications: The purpose of the System Design Specifications (SDS) is to describe in detail how the solution will be enhanced to support requirements that will not be met through configuration. Elements of an SDS should contain at a minimum:

a. Navigation

b. User Interface (screen / report mock-ups)

c. Inputs/Outputs

d. Db Tables/Columns

e. Field Edits/Validation Rules

f. Error Handling & Messages

g. Access Roles

h. Report Parameters, Sort, Groups, etc.

i. Business Rules

j. Logical Data Model

k. Audit Logging

l. References and Standards

1. Provide input based on County requirements. Review & Validate

SDS

Deliverable Name Type DED Required Project Stage Deliverable Requirement (Vendor) Deliverable Requirement (County)

m. Requirements Traceability

Vendor Responsibilities: Work with County Subject Matter Experts to elaborate the design based on gap analysis review / decisions. Update the Requirements traceability Matrix.

2F – Inventory of Reports, Dashboards, Forms & Queries

Yes Requirements/Design Inventory and specifications of Reports, Dashboards, Forms & Queries: The Inventory of Reports, Dashboards, Forms, & User Queries is required to provide the County a consolidated list of the scope of the Reports, Dashboards, Forms, & User Queries that will be provided within the solution. Elements of the inventory should contain at a minimum:

a. Report Listing

a. Name of Report

b. Description

c. Fields

d. Parameters

e. Calculations

f. Sort Order

g. Filtering

b. Dashboard Listing

a. Name of Dashboard

b. Description

c. Columns

d. Parameters

e. Sort & Filter Options

c. Forms Listing

a. Name of Form

b. Description

c. Fields

1. Provide input based on County requirements. Review & Validate listing.

Deliverable Name Type DED Required Project Stage Deliverable Requirement (Vendor) Deliverable Requirement (County)

d. Parameters

e. Calculations

d. Queries Listing (supported by analytics tools)

a. Name of Query

b. Description

c. Data

d. Calculations

Vendor Responsibilities: Work with County Subject Matter Experts to compile the inventory based on gap analysis review / decisions. Update Requirements Traceability Matrix

3A – Environment Configuration

Software No Configure/Build Environment Configuration: The objective of this task is to initialize and deploy the Cloud or Hybrid environment configuration components to County specifications. The Environment Configuration shall include:

a. Cloud or Hybrid Infrastructure Deployment mapped to County Design Requirements

b. Infrastructure Security Components Deployment mapped to County Specifications

c. Backup(s), Snapshot(s) and Replication(s) Deployment mapped to County Specifications

d. Environment Performance, Security, Audit Logging and Alerting Deployment mapped to County Specifications

Vendor Responsibilities: Deploy the Infrastructure Environment Configured to County provided specifications. Facilitate workshops to validate County specific configurations. Deploy and Publish the Infrastructure Environment for County review and approval. Provide a transmittal release document to County with Environment release number, release notes that outline progress and changes from the previous build.

1. Allocate and assign County SMEs to participate in validation sessions.

Review, Test & Validate the Infrastructure Environment Configuration builds as they are released per schedule.

3B – Application Configuration

Software No Configure/Build Application Configuration. The objective of this task is to deploy the application configuration variables and solution options to County selected configuration specifications. The Application Configuration shall include:

1. Allocate and assign County SMEs to participate in validation sessions.

Review, Test & Validate the

Deliverable Name Type DED Required Project Stage Deliverable Requirement (Vendor) Deliverable Requirement (County)

a. System Configuration to Design Specifications

b. Configure Parameters by Type (e.g., Structural, Validate Values, Set Read-only and System Overrides)

c. Configure Data Types

d. Set Name and Label Configurations

e. Set User and User Role Configurations

f. Set System Administration Configurations

Vendor Responsibilities: Configure the Application Build(s) to County provided specifications. Facilitate workshops to validate County specific configurations. Build and Publish the Application for County review and approval. Provide a transmittal release document to the County with build number, release notes that outline progress and changes from the previous build.

Application Configuration builds as they are released per schedule.

3C – Develop Reports, Dashboards, Custom Design & Enhancements

Software No Configure/Build Develop Reports, Dashboards, Custom Design & Enhancements: The objective of this task is to deploy the application reporting environment, reports, dashboards, and custom developed components to County requirements. The reports, dashboards and custom components shall include but are not limited to:

a. Reporting Infrastructure

b. Self-Service, User and Administrator reports and dashboards

c. Custom components developed to specifications mapped to County requirements

d. Third-party Software

e. Administrative Tools

Vendor Responsibilities: Deploy the Reporting Infrastructure, Reports, Dashboards, and Custom Components to the County provided specifications. Facilitate workshops to validate County requirements. Build and Publish the Reporting Infrastructure, Self- Service, User & Administrator Reports and Dashboards for County review and approval. Provide a transmittal release document to the County with build numbers and release notes that outline progress and changes from the previous build.

1. Allocate and assign County SMEs to participate in validation sessions.

Review, Test & Validate the Application Configuration builds as they are released per schedule.

4A – Detailed Data Cleansing Plan(s)

Software Yes Configure/Build Detailed Data Cleansing Plan(s): The objective of this task is to identify County data sources required for migration and develop a thorough understanding of data to be

1. Allocate and assign County SME resources to participate in workshop

Deliverable Name Type DED Required Project Stage Deliverable Requirement (Vendor) Deliverable Requirement (County) cleaned. The plan(s) will also include the strategy for manual and automated approaches. The Detailed Data Cleansing Plans shall include:

a. Approach

a. Clearly stated data cleansing objectives

b. Identified Vendor and County Assumptions

c. Identified Constraints

d. Risks

b. Data Cleansing Strategy

a. Cleansing Scope

b. Cleansing Approach

c. Roles & Responsibilities

d. Cleansing Schedule

e. Cleansing Quality Assurance and Validation

c. Data Cleansing Preparation

a. Prerequisites (e.g., Sandbox Environments & Tools)

b. Backup / Snapshot Strategy

c. Backout and Restore Process

d. Data Cleansing Specifications

Vendor Responsibilities: Develop the Detailed Data Cleansing Plan(s) with County provided input. Facilitate workshops to identify County specific requirements. Publish the Detailed Data Cleansing Plans for County review and approval.

sessions. Review & Validate the Detailed Data Cleansing Plans(s)

4B: Detailed Data Conversion Plan(s)

Written Yes Configure/Build Detailed Data Conversion Plan(s): The objective of this task is to identify the areas and rules to convert County data sources to the Vendor data model. The plan(s) will also include the strategy for manual and automated approaches. The Detailed Data Conversion Plans shall include:

a. Approach

a. Clearly stated data conversion objectives

1. Allocate and assign County SME resources to participate in workshop sessions. Review & Validate the Detailed Data Conversion Plans(s).

Deliverable Name Type DED Required Project Stage Deliverable Requirement (Vendor) Deliverable Requirement (County)

b. Identified Vendor and County Assumptions

c. Identified Constraints

d. Risks

b. Data Conversion Strategy

a. Conversion Scope

b. Conversion Approach

c. Roles & Responsibilities

d. Conversion Schedule

e. Conversion Quality Assurance and Validation

c. Data Conversion Preparation

a. Prerequisites (e.g., Sandbox Environments & Tools)

b. Backup / Snapshot Strategy

c. Backout and Restore Process

d. Data Conversion Specifications

Vendor Responsibilities: Develop the Detailed Data Conversion Plan(s) with County provided input. Facilitate workshops to identify County specific requirements. Publish the Detailed Data Conversion Plans for County review and approval.

4C: Detailed Data Migration Plan(s)

Written Yes Configure/Build Detailed Data Migration Plan(s): The objective of this task is to identify the data source dependencies, order, and priority of the migration efforts to load County cleansed and converted data sources to the Vendor data repositories. The plan(s) will also include the strategy for manual and automated approaches. The Detailed Data Migration Plans shall include:

a. Approach

a. Clearly stated data migration objectives

b. Identified Vendor and County Assumptions

c. Identified Constraints

d. Risks

1. Allocate and assign County SME resources to participate in workshop

Detailed Data Migration Plans(s).

Deliverable Name Type DED Required Project Stage Deliverable Requirement (Vendor) Deliverable Requirement (County)

b. Data Migration Strategy

a. Migration Scope

b. Migration Approach

c. Roles & Responsibilities

d. Migration Schedule

e. Migration Quality Assurance and Validation

c. Data Conversion Preparation

a. Prerequisites (e.g., Sandbox Environments & Tools)

b. Backup / Snapshot Strategy

c. Backout and Restore Process

d. Data Migration Specifications

Vendor Responsibilities: Develop the Detailed Data Migration Plan(s) with County provided input. Facilitate workshops to identify County specific requirements. Publish the Detailed Data Migration Plans for County review and approval.

4D: Conduct Data Conversion(s) and Migration(s)

Software No Configure/Build Conduct Data Conversion(s) and Migration(s): The objective of this task is to conduct the Data Conversion(s) and Migration(s) to County specifications.