Contract No. XXXXXX-XXX, Exhibit C

EXHIBIT C – IMPLEMENTATION STATEMENT OF WORK (SOW) TEMPLATE

Statement of Work (SOW) Between [AGENCY] and [SUPPLIER NAME]

Issued Under

CONTRACT NUMBER XXXXXX-XXX

BETWEEN

AGENCY NAME

AND

[SUPPLIER NAME]

This Implementation Statement of Work (“SOW”), between (Name of Agency) (hereinafter referred to as “Agency”) and [Supplier Name] (“Supplier”) is issued pursuant to the terms of Contract Number (XXXXXX-XXX) (“Contract”) In the event there is any conflict between the terms of this SOW and the terms and conditions of the Contract, the terms and conditions of the Contract will control.

[[Note to Agency: Supplier must comply with all applicable COV ITRM policies, standards and guidelines located at: https://www.vita.virginia.gov/policy--governance/policies-standards--guidelines/.

If an Agency determines any area of non-compliance with the ITRM PSGs at the above link, the Agency’s Project Manager must obtain an approved exception from VITA in accordance with the exception process prior to placing any related order or authorizing Supplier to commence any work. To submit an exception, please complete the COV IT Security Policy and Standard Exception Request Form located at this link: https://www.vita.virginia.gov/policy--governance/policies-standards--guidelines/ and submit to VITA for approval. Your Agency Customer Account Manager (CAM) can assist you with the exception process.]] [[Note to Template Users: Instructions for using this template to draft a Statement of Work are in gray highlight and denoted by double opening and closing brackets [[ ]]. These instructions should be deleted after the appropriate text has been added to the Statement of Work. Contractual language is text that is highlighted in blue which should remain in the document, is variable, and should be modified by the Agency based on the nature of the project.]]

The objective of the implementation project described in this SOW is for the Supplier to provide Agency with implementation services to implement the Solution (“Solution”) or Services (“Services”) or Software (“Software”) or Hardware or Licensed Application Services for Agency’s (Enter Solution Name). [[Customize the previous sentence to state what you are getting from the Supplier, based on your Agency’s Contract language, and with your project name.]]

Implementation Period of Performance The implementation work authorized in this SOW will commence XX (XX) days after execution of the Contract and will continue for a period of XX (XX) months. Implementation Services will be considered complete when all work detailed in this SOW is finalized, the Solution is in productive use by the Agency, and the Agency has issued formal Acceptance of the Solution to the Suppler. [[Customize this section to match what you are getting from the Supplier, based on the allowable scope of your Contract and your project’s specific implementation needs within that allowable scope]] Place of Performance for implementation [[Assign performance locations to major milestones or any other project granularity, depending on your transparency and governance needs, if needed]] Tasks associated with this project implementation will be performed at the Agency’s location(s) in City/State, at Supplier’s location(s) in City/State, or other locations as required by the effort and mutually agreed to under this SOW.

Project Definitions [[ All definitions related to your project need to be defined in the Contract definition section. Definitions should not be added to this SOW]] All definitions are located in the Contract and shall apply to and take precedence over this SOW.

Project Scope FOR IMPLEMENTATION [[Provide a description of the scope of your project implementation and carve out what is NOT in the scope of your project implementation. Remember that it must fit within your Agency’s Contract scope.]]

0. Project Scope and Purpose The Implementation work authorized in this SOW will include delivery, installation, implementation, integration, testing, training, and Acceptance of all products and services necessary to implement the Agency’s (Enter Solution Name), this includes any support, other than on-going maintenance services.

0. Project Boundaries [[Agency to describe any project boundaries related to this implementation.]] Project Implementation Requirements Agency’s Specific Implementation Requirements [[Provide information about your Agency’s specific Requirements for this implementation including, but not limited to, applicable directives, referenced documents, standards, specifications that are either mandatory or informational. Requirements should come from the Agency’s Exhibit A Requirements on project management and implementation]] Special Considerations for Implementing Technology at Agency’s Location(s)

Other Project Characteristics to Ensure Success

Required Products (or Solution Components) [[List the products, or if your project is for a Solution, the Solution components, the hardware, software, etc., provided by Supplier that will be used to support your project Requirements. Identify any special configuration Requirements and describe the system infrastructure to be provided. Provide an overview that reflects how the system will be deployed within the Agency’s environment. You are urged to refer to your Agency’s Contract for allowable scope and other guidance in drafting language for this section.]] Required Implementation Services [[List the services (e.g., Requirements development, Solution design, configuration, interface design, data conversion, installation, implementation, testing, training, risk assessment, performance assessment, and support (other than ongoing maintenance services) that will be provided by Supplier in the performance of your project. You are urged to refer to your Agency’s Contract for the definition of Services and for the allowable scope in drafting language for this section. You will notice subsections ”J” and “L” below offer areas for expanded detail on training and support, other than ongoing maintenance services. It is likely some of this detail will be a combination of your known needs and the Supplier’s proposal. In all cases the provisions should include all negotiated commitments by both parties, even if you reference by incorporation the Supplier’s proposal in any subsection.]] Project Specific Performance Requirements Project specific performance Requirements are outlined in Exhibit (X) Service Level Agreement.

Project Specific Deliverable Requirements [[Add info on Deliverable Requirements]] Project Specific Materials, Equipment, Facilities and Property [[In this section, provide details of any materials, equipment, facilities, and property to be provided by your Agency or the Supplier in performance of this implementation project. If none exist, state this in the Requirements so it is clear. If delivery of any of these items is critical to the schedule, you may want to identify such delivery with hard due dates tied to “business days after project start” or “days after event/milestone in Section 8. Be sure to specify the delivery and point of contact information.]]

i. Provided by the Agency

ii. Provided by the Supplier Other Technical/Functional Requirements [[Provide any other unique project technical Requirements, functional Requirements, and expectations related to the implementation in sufficient detail in this section. Several examples are listed.]]

i. Data migration, access, and retrieval requirements

ii. Additional warranties Training Requirements and/or Agency Self-Sufficiency/Knowledge Transfer [[Provide an overview and details of training services to be provided for the project and any special Requirements for specific knowledge transfer to support successful implementation of the Solution. If the intent is for the Agency to become self-sufficient in operating or maintaining the Solution, determine the type of training necessary, and develop a training plan, for such user self-sufficiency. Describe how the Supplier will complete knowledge transfer.]] Agency’s Security Requirements [[Provide, or reference as an attachment, Agency’s security Requirements. Examples are provided below.]]

i. Security procedures for the Agency’s location may include, but are not limited to, background checks, records verification, photographing, and fingerprinting of Supplier’s employees or agents.

ii. Execution of additional forms, such as a non-disclosure agreement (NDA), to be signed by each of the Supplier’s employees or agents acknowledging that all Agency information that Supplier employees or agents may have contact with is confidential and proprietary. Any unauthorized release of proprietary information by the Supplier, or an employee or agent of the Supplier, will constitute a breach of Contract.

Implementation Support Requirements [[NOTE: This subsection is to document required implementation support other than ongoing maintenance services. Document the level of implementation support required by your Agency’s project to operate the Solution. This may include conversion support, legacy system integration, or other specialized consulting to facilitate delivery or use of the Solution. If these Requirements are already addressed in the Contract, then the Agency should insert a reference to where this information is located.]] Personnel Requirements for Implementation [[Provide any supplier personnel qualifications, Requirements, licenses, certifications, or restrictions including project manager, key personnel, subcontractors, etc., but ensure they do not conflict with your Agency’s Contract terms.]] Closeout Requirements for Project Implementation [[Describe any specific closeout Requirements for phasing out the project with the Supplier. This may include Deliverable Acceptance receipts, financial closure, documentation handoff (such as manuals, operating procedures, and warranties), stakeholder surveys, post-project evaluations, and lessons learned reports. Be specific on what project closeout Requirements are needed, the duration/timeline to provide, and any other pertinent details. The Agency will need to ensure they do not conflict with your Contract provision(s) regarding Transition of Services. If these Requirements are already addressed in the Contract, then the Agency should insert a reference to where this information is located.]] Implementation Project Assumptions & Project Roles and Responsibilities [[This section contains areas to address project assumptions by both the Supplier and Agency and to assign project specific roles and responsibilities between the parties. Make sure that all assumptions are included to alleviate surprises during the project. Ensure that all primary and secondary roles and responsibilities are included. You will tailor the Responsibility Matrix table below to fit your project’s needs.]]

0. Project Assumptions The following assumptions are specific to this project:

0. Project Roles and Responsibilities The following roles and responsibilities have been defined for this project:

Responsibility Matrix Legend:

R = Responsible for execution/completion of work A = Final approval authority C = Must be consulted I = Must be informed

(Sample Responsibility Matrix to be customized by the Agency with their project specific responsibilities)

Infrastructure – Preparing the system infrastructure that meets the recommended configuration defined in Section 2B herein

R

Server Hardware

Server Operating

R

Server Network Connectivity

Relational Database Management Software (Installation and Implementation)

R

Cabling, Electric and User Network Connectivity from Access Points

R

Troubleshooting – IT Infrastructure

Milestones, Deliverables, AND Epics (If Applicable) [[List and describe the Supplier’s Deliverable expectations for this project. This table includes recommendations only and must be customized for the Agency’s project This table should include the project’s milestone events, associated deliverables, a detailed description of each deliverable, detailed Acceptance (i.e. “exit”) criteria for each deliverable, and a corresponding due date. NOTE: all payment information, including information on the amount retained per Milestone (the standard retained amount is 20%), must go in your Contract document in the appropriate section of the “Fees, Ordering, and Payments” section.]] NOTE: Deliverables are tangible (i.e., product or service) and are the end products or services that are produced as a result of the project. Deliverables can signal the completion of a project Milestone event or a key activity towards the completion of a project Milestone event. There can be multiple Deliverable expectations under a single Milestone event. Project Milestones signal the reaching of a key event/phase in the project’s lifecycle that indicates progress towards the project’s completion.

Deliverable descriptions should detail the products, solution, services, documentation, etc. that the Agency expects to be provided by the Supplier by the corresponding deliverable due date and should be based on the applicable Agency Requirements in Exhibit A. Deliverable Acceptance criteria are a measurable set of conditions that describe the expected outcome(s) that indicate the Deliverable can be formally Accepted by the Agency, and that the project is ready to move to the next Deliverable or Milestone.]] Supplier shall provide the milestone events and Deliverables identified below by the associated due date identified in the table. The following table identifies milestone events, epics, and Deliverables to be provided by Supplier under this SOW, the Deliverable description, the associated Deliverable Acceptance (“exit”) criteria, and the associated due date for that milestone event, epic, or Deliverable. All pricing information related to this implementation SOW shall be detailed in Exhibit B Pricing and broken out by Milestone/Deliverable.

Execution + 5 days

Project Management and Strategy

Execution+45 days

· Initial Project Schedule is in a format compatible to Agency, as described in Exhibit A Requirements

· Agency receives and reviews the Schedule for its conformance with Exhibit A Requirements

· Agency returns Deliverable Acceptance Receipt Initial plan within 30 days of Execution, then periodic review, then monthly to assess progress and discuss any necessary updates*

*Significant changes must be reviewed and approved by Agency prior to execution of such change

· Initial Project Management Plan is in a format compatible to Agency, as described in Exhibit A Requirements

· Agency receives and reviews the Plan for its conformance with Exhibit A Requirements

· Agency returns Deliverable Acceptance Receipt Initial Plan within 60 days of Execution; then reviewed annually or upon scope change*

*Any changes to the Plan must be reviewed and approved prior to execution of such change

Initial within 30 days of Execution, then monthly until the project is complete, and upon execution of any changes*

*Any changes to the WBS will be subject to Agency review and approval

Initial Document, Execution + 60 days, then quarterly until project is complete, and upon execution of any changes*

*Any changes to the Plan will be subject to Agency review and approval

Execution + 60 days

Initial Plan within 60 days of Execution, then annually until project is complete, and upon execution of any changes*

Initial Plan within 60 days of Execution, then annually until project is complete, and upon execution of process changes*

Initial Plan within 60 days of Execution, then annually until project is complete, and upon execution of updates as stakeholder needs evolve*

*Any changes to the Plan will be subject to Agency review and approval

Initial Document, Execution + 90 days, and upon execution of any changes*

*Any changes to the Matrix will be subject to Agency review and approval

Initial Plan, Execution + 90 days, and upon execution of any changes*

*Any updates to the Plan will be subject to Agency review and approval

Initial Document, Execution + 90 days, and upon execution of any changes*

*Any updates to the Document will be subject to Agency review and approval

Within 30 days of review of the System Architecture Document

Initial Document, Execution + 90 days*

Initial Report, Execution + 90 days, then quarterly until project is complete*

*Any updates to the Report will be subject to Agency review and approval

Initial Plan, Execution + 90 Days, then quarterly until project is complete*

Project Performance and Progress Monitoring

I don’t think agencies know EVM

Monthly, by the Xth day of each month, until the project is completed

Initial Plan, Execution + 90 days, then after every executed change*

*Any updates to the Plan will be subject to Agency review and approval

Initial Plan, Execution + 90 days*

*Any updates to the Plan will be subject to Agency review and approval

Execution + 90 days

Initial Plan, Execution + 120 days, and upon execution of any updates*

*As configurations change, Plan will require updates subject to Agency review and approval

90 days before training commences*\

90 days prior to the start of training*

*Any changes to the Manual will be subject to Agency review and approval

Execution + 160 days, and upon any executed changes*

Execution +175 days

Execution + 175 days

Execution + 175 days

Execution + 175 days

Transition and Project Closeout

Execution + 175 days

Execution + 175 days

[[What other project closeout documentation would be required?]]

Execution + 210 days

Final Acceptance Letter

Execution + 210 days

Acceptance Criteria [[This section should reflect the mutually agreed upon Acceptance Criteria specific to this engagement. Please read your Agency’s Contract definitions for the definition of Requirements and Acceptance. Ensure the language in this section does not conflict with your Agency’s Contract language in the Deliverables Acceptance and Cure Period Section]] The Acceptance process for this Solution is described in the Acceptance and Cure Period Section of the Contract (Section XX) and will be based on the Agency’s determination that the Services, Software, Solution, Application, Products, and/or Deliverables meet the Requirements in accordance with the Contract, this SOW, test plan, or other written agreement between the Parties.

Each Deliverable created under this Statement of Work will be delivered to the Agency Project Manager with a Deliverable Acceptance Receipt. This receipt will describe the Deliverable and provide the Agency’s Project Manager with a space to indicate if the Deliverable is Accepted, rejected, partially Accepted, or conditionally Accepted. Conditionally Accepted Deliverables will contain a list of deficiencies that need to be corrected for the Deliverable to be Accepted by the Agency Project Manager.

Risk Management during Implementation [[The detailed project plan establishes the process and procedures for the identification, analysis, and management of risks and establishes the initial list of risks facing the project. During execution and control, the Risk Manager (or PM if a separate Risk Manager has not been appointed) establishes the risk/issues log, monitors the identified risks/issues, and advises the Project Manager on risk incidence and response. The Risk Manager also surveys the project for new risks; assesses and quantifies newly identified risks as provided in the Risk Management Plan; develops appropriate contingency plans; and removes or downgrades risks whose window of occurrence has passed. The Risk Manager collaborates with the Project Manager to ensure the Risk Management section of the Project Status Report is updated and the Internal Agency Oversight Committee (IAOC) is informed of project risks and their status at each meeting).]]

0. Risk Management Process [[The list below is taken from VITA PMD’s template discussing what should go into a Risk Management Strategy. Don’t forget to consider and plan for any budget contingencies to accommodate potential risks that are identified.]]

1. Risk Identification Process: Describe the process for risk identification.

2. Risk Evaluation and Prioritization: Describe how risks are evaluated and prioritized.

3. Risk Mitigation Options: Describe, in general terms, the risk mitigation options. They must be realistic and available to the project team.

4. Risk Plan Maintenance: Describe the methods for maintaining or updating the risk plan during the project lifecycle.

5. Risk Management Responsibilities: Identify all project team members with risk management responsibilities (e.g., an individual responsible for updating the plan or an individual assigned as a manager).

Risk Management Plan [[Agency should include a description of the frequency and structure of risk reviews, the project team responsibilities, and the steering and oversight committee responsibilities and documentation. Don’t forget to add all Deliverables associated with risk strategizing and planning to the list of Deliverables.]] Reporting during Implementation [[The following are examples of reporting Requirements which may be included in your SOW depending on your project’s need for governance. Agencies should update this section with their project’s reporting Requirements for the Supplier.]]

0. Weekly/Bi-weekly Status Update The weekly/bi-weekly status report, to be submitted by Supplier to the Agency, should include accomplishments to date as compared to the project plan; any changes in tasks, resources or schedule with new target dates; all open issues or questions regarding the project; action plan for addressing open issues, risks, or questions and potential impacts on the project; and risk management reporting.

0. Supplier Performance Self-Assessment.

[[In an effort to help the Agency monitor Supplier performance, it is strongly recommended that the SOW include “Supplier Performance Assessments”. These assessments may be performed at the Project Manager’s discretion and are not mandated by VITA.]] Within 30 calendar days of Contract kickoff, the Supplier and the Agency will agree on Supplier performance self-assessment criteria. Supplier shall prepare a monthly self-assessment to report on such criteria. Supplier shall submit its self-assessment to the Agency who will have five (5) business days to respond to Supplier with any comments. If the Agency agrees with Supplier’s self-assessment, such Agency will sign the self-assessment and upload a copy to the Project documents in Planview, the Commonwealth Technology Portfolio.

Performance Audit/ IV&V Assessment A validation audit of the Supplier’s performance reporting under this Reporting section is required on a periodic basis for category one and two projects and optionally for three and four projects Suggested language is provided below but must be customized for your project.]] Agency (or name of IV&V contractor, if there is one), will audit the results of Supplier’s service level obligations and performance requirements on a monthly/quarterly basis, within ten (10) business days of receipt of Supplier’s self-assessments and service report(s). Any discrepancies will be discussed between the Agency and Supplier and any necessary invoice/payment adjustments will be made. If an agreement cannot be reached, the Agency and Supplier will escalate the matter in accordance with the Escalation provision of the Contract (Add Contract Section #).

For more information on IV&V please visit the Project Management Standard located at: https://www.vita.virginia.gov/policy--governance/policies-standards--guidelines/ Change Request Process [[Changes to the baseline SOW must be documented for proper project oversight. Depending on your project, you may need to manage and capture changes to configuration, incidents, Deliverables, schedule, price or other factors your team designates as critical. Any price changes must be done in compliance with the Code of Virginia, § 2.2-4309. Modification of the Contract, found at this link: http://law.lis.virginia.gov/vacode/title2.2/chapter43/section2.2-4309/. Changes to the scope of this SOW must stay within the boundaries of the scope of the VITA or your Agency’s Contract.

For complex and/or major projects, it is recommended that you use the VITA PMD processes and templates located at:

https://www.vita.virginia.gov/policy--governance/policies-standards--guidelines/ and https://www.vita.virginia.gov/policy--governance/project-management/project-management-templates-tools/.

It is very important that changes do not conflict with, but do comply with, your Agency’s Contract, which takes precedence. The following language may be included in this section, but additional language is needed to list any technical/functional change management areas specific to this SOW (i.e., configuration, incident, workflow, or any others of a technical/functional nature).]] All changes to this SOW must comply with the Contract. Price changes must comply with the Code of Virginia, § 2.2-4309. Modification of the Contract, found at this link: http://law.lis.virginia.gov/vacode/title2.2/chapter43/section2.2-4309/ All changes to this SOW shall be in written form via a modification to the Contract and fully executed between the Agency and the Supplier’s authorized representatives. For administrative changes, the parties agree to use the change template, attached to the Contract. For technical/functional change management Requirements, listed below, the parties agree to follow the processes and use the templates provided at this link: https://www.vita.virginia.gov/it-governance/project-management/project-management-templates-tools/ Point of Contact For the duration of this project, the following project managers shall serve as the points of contact for day-to-day communication:

Agency: __________________________ Supplier: _________________________

SOW TEMPLATE Q01FY2026 Page 2 of 11