IT Professional Services Master Price and Services Agreement

WORK ORDER CONTRACT EXHIBIT 1

STATEMENT OF WORK FOR QMS

Table of Contents

1. Introduction to Quality Management Services

1.1 PURPOSE

1.2 QUALITY MANAGEMENT APPROACH

1.3 IQMS CONSULTANT’S PERSONNEL ROLES AND RESPONSIBILITIES

1.4 DEFINITIONS

2. Quality Management Services (“QMS”)

2.1 TASK 1: RISK ASSESSMENT

2.2 TASK 2: QUALITY PLANNING

2.3 TASK 3: QUALITY CONTROL (QC)

2.4 TASK 4: QUALITY ASSURANCE (QA)

2.5 TASK 5: INDEPENDENT SOLUTION TESTING

3. Deliverables and Payment Schedule

4. Appendices

APPENDIX A: OREGON QUALITY STANDARDS

APPENDIX B: SWQA PROJECT ASSESSMENT REPORT

S-10700-00015522 Exhibit 1 SOW Base template:IQMS SOW Narrative and Appendices (v2025)

1. Introduction to Quality Management Services

1.1 Purpose

The purpose of the IQMS Consultant’s work is to assure that appropriate levels of Quality Management Services are performed for the Statewide Payroll Transformation Project (“Project”). These Services must provide the Authorized Purchaser with appropriate visibility into the processes being used, and the products being built. They must be sufficient to assure that the Project satisfies the needs for which it was undertaken, and that Project risks are well understood and appropriately mitigated or managed.

1.2 Quality Management Approach

The approach to ensure that the appropriate quality management and risk management activities are conducted must be based, as necessary and appropriate in the context of a particular project, on the Project Management Institute’s (PMI) Standard described in the current edition of the Project Management Body of Knowledge (“PMBOK” https://www.pmi.org/pmbok-guide-standards); and the International Standards Organization standard ISO12207 for software life cycle processes. This includes Quality Management Services that determine the quality policy, objectives, and responsibilities; and implements them by means such as quality planning, quality control, and quality assurance.

Quality Management is a subset of project management that includes the process required to ensure that the Project satisfies the needs for which it was undertaken. Quality Management consists of activities in quality planning, quality assurance, quality control (including independent testing) and risk management. Together, these activities constitute the Authorized Purchaser’s independent verification and validation (IV&V) requirements. They are independent in the sense that they are conducted independently of the development Consultant or systems integrator.

The term “Quality Standards” refers to a project’s “process” and “product” quality standards.

“Process” quality standards cover organizational influences, management support, decision drivers, project management, scheduling, resourcing, experience, and so on. “Product” quality standards cover product content, design, development, deployment, environment, technology, security, maintainability, and so on.

The quality management approach for the Project must adhere to and include, but not be limited to, work activities in support of the following Quality Management Services that constitute the Authorized Purchaser’s IV&V requirements:

1. Task 1 - Risk Assessment

2. Task 2 - Quality Management Planning

3. Task 3 - Quality Control

4. Task 4 - Quality Assurance

5. Task 5 - Independent Solution Testing https://www.pmi.org/pmbok-guide-standards

Base template:IQMS SOW Narrative and Appendices (v2025)

Together, the satisfactory performance of these Tasks by the IQMS Consultant helps ensure the application of best practices in project management, including quality management, and the delivery of technical work products that meet or exceed project requirements for schedule, cost, functionality, reliability, security, and other relevant quality standards.

1.3 IQMS Consultant’s Personnel Roles and Responsibilities

Project Manager. IQMS Consultant shall designate one of the Key Persons for this Contract as Project Manager of the Services. The Project Manager shall be familiar with Authorized Purchaser’s business operations and objectives, shall perform the Services in accordance with the warranties in the MPSA and this Contract. The Project Manager will participate with Authorized Purchaser in periodic review sessions and will provide detailed progress reports that identify completed tasks and the status of the remaining Services to Authorized Purchaser upon request.

1.4 Definitions

“Independence” or “Independent”: The delivery of services by a third party free from real or perceived conflict with the interests of the Authorized Purchaser and its contractors involved in project planning, design, development, implementation, deployment and operational activity, and as otherwise defined in Statewide Policy 107-004-030.

“Independent QA Act”: Chapter 77, A 2014 ACT HB 4122, codified at ORS 276A.223.

“Statewide Quality Assurance (SWQA)”: The Enterprise Information Services (EIS) team that establishes and oversees access to the group of pre-qualified IT Quality Management Services providers under statewide Master Price and Services Agreements for delivery of diverse, Independent Quality Management Services (IQMS). Each IQMS consultant has executed a Master Price and Services Agreement with the State that includes negotiated provisions, such as standard contract terms and conditions, established hourly rate cards, and the SWQA enterprise statement of work (SOW) that identifies, defines, and describes the task areas that comprise the State’s required QMS scope.

“Independent Verification and Validation” or “IV&V”: Interchangeable terms that have the meaning set out in the latest edition of ISO 12207. “Verification” relates to evaluation that establishes the compliance of project work products with approved business requirements, technical requirements, architecture, and design. “Validation” relates to determining that project work products fulfill intended business needs. “Independent” has the meaning set out above in connection with the defined term, “Independence” or “Independent”.

“Information Technology Initiative” or “IT Initiative”: A project to develop or provide, with an Authorized Purchaser’s own personnel and resources, or to obtain by means of a procurement or set of related procurements: (i) New hardware, software or services for data processing, office automation or telecommunications; (ii) An overhaul, upgrade or replacement of a substantial portion of the hardware or software in an existing data processing, office

Base template:IQMS SOW Narrative and Appendices (v2025) automation or telecommunications system; or (iii) A substantial expansion of existing data processing, office automation or telecommunications services.1

“Preliminary Quality Assurance Services” means a set of services in which a Consultant provides an independent and objective review of an Authorized Purchaser’s plans, specifications, estimates, documentation, available resources and overall purpose for an information technology initiative, including services in which the Consultant evaluates a proposed information technology initiative against applicable quality standards and best practices from private industry and other sources.

“Quality Management Services” or “QMS” means a set of services in which a Consultant provides an independent and objective review and evaluation of a state contracting agency’s, a public corporation’s or another Consultant’s performance with respect to an information technology initiative, such as services in which the Consultant: (A) Identifies quality standards that apply or should apply to the information technology initiative; (B) Suggests methods and means by which the state contracting agency, the public corporation or the other Consultant may meet quality standards identified in subparagraph (A) of this paragraph; (C) Reviews and evaluates the state contracting agency’s, the public corporation’s or the other Consultant’s performance regularly as the information technology initiative progresses from start to finish;

(D) Identifies omissions or gaps in the state contracting agency’s, the public corporation’s or the other Consultant’s planning, execution, control, methodology, communication or reporting as the information technology initiative progresses from start to finish; (E) Identifies risks in the state contracting agency’s, the public corporation’s or the other Consultant’s plans or approach to designing, developing or implementing the information technology initiative and suggests methods to reduce, mitigate or eliminate the risks; (F) Assists the state contracting agency or the public corporation in testing or otherwise evaluating the hardware, software or services that are developed, provided or obtained as part of an information technology initiative to determine whether the hardware, software or services conform with the quality standards identified in subparagraph (A) of this paragraph; (G) Advises the State Chief Information Officer, the state contracting agency or the public corporation as to whether the hardware, software or services that are developed, provided or obtained as part of an information technology initiative meet the contracting agency’s or the public corporation’s needs, specifications or expectations and otherwise enable the state contracting agency or the public corporation to achieve the objectives for the information technology initiative; or (H) Identifies unsatisfactory performance and suggests methods the State Chief Information Officer, the state contracting

1 Information Technology Initiative does not include: (i) A procurement for preliminary quality assurance services or quality management services; (ii) A routine update to or purchase of hardware or software within an existing data processing, office automation or telecommunications system; (iii) A renewal of an existing contract for data processing, office automation or telecommunications services under terms and conditions that are substantially the same as in the existing contract; or (iv) A replacement of a component of an existing data processing, office automation or telecommunications system that is not essential for the system to function as designed or that occurs at the end of the component’s anticipated life cycle.

Base template:IQMS SOW Narrative and Appendices (v2025) agency, the public corporation or the other Consultant might use to eliminate the causes of unsatisfactory performance.

2. Quality Management Services (“QMS”)

2.1 Task 1: Risk Assessment

The Risk Assessment Task defines how the IQMS Consultant will support a project’s overall risk management efforts. The IQMS Consultant should refer to the project’s Risk Management Plan, if one exists. Authorized Purchaser’s project team retains the primary responsibility for executing the project’s risk management activities, while the IQMS Consultant provides a supporting role through its independent efforts. Within the IQMS Consultant’s role of completing Task 2 Quality Planning, Task 3 Quality Control (including Task 5 Independent Solution Testing), and Task 4 Quality Assurance; it must identify risks and provide recommendations for risk avoidance and mitigation strategies related to work product, process, and the overall project. Risk management includes the identification of risks, the thorough assessment of the probability and the impact for the occurrence of risks, and the planning of viable responses that include, but are not limited to, mitigation, contingency, and avoidance strategies. Identification of Information Security risks should also be an essential part of the scope of the IQMS Consultant’s initial and on-going risk assessment.

The IQMS Consultant performs Task 1 through the following Deliverables:

1. Deliverable 1.1: Risk Assessment

The IQMS Consultant shall conduct a Risk Assessment of the project to identify the current status of the project, identify risks and their likelihood of occurring, and provide an independent written Risk Assessment Report that evaluates the planned schedule, fiscal and personnel resources, and processes. If IQMS Consultant conducts a Risk Assessment early in the project lifecycle, IQMS Consultant may be requested to refresh the Risk Assessment one or more times throughout the project. At minimum, in developing or refreshing its Risk Assessment Report, the IQMS Consultant must evaluate the project’s Integrated Project Plan for reasonableness, validity, thoroughness and accuracy with emphasis on the following:

1. Project Plan including State Resource Plan;

2. Project Requirements Management Plan;

3. Project Change Management Plan;

4. Project Issue Management Procedure;

5. Communication Plan;

6. Other critical Project processes; and

7. Any authorized Task 3 Quality Control Reviews.

As part of the Risk Assessment of the Project, the IQMS Consultant shall, if the following Plans are applicable and available, perform a risk assessment on the project’s most recent Software

Base template:IQMS SOW Narrative and Appendices (v2025)

Development Plan, Facility Plan, Configuration Management Plan, Data Conversion Strategy, Testing Strategy, Post-Implementation Support Strategy (for on-going operations and maintenance), Training Strategy, and Certification Checklist. For projects that are not for the purpose of traditional software development, the Risk Assessment should include artifacts that are comparable to those listed in this section within the context of the project’s actual purpose.

This Risk Assessment must take into account work product and project-level considerations, including at a minimum:

1. Feasibility of the technical solution;

2. Sufficiency of security controls to safeguard protected or confidential information and to meet security requirements;

3. Sufficiency of project components and processes; and

4. Sufficiency of project budget, schedule and resources.

To satisfactorily produce this Deliverable, the IQMS Consultant must be well versed in all aspects of the project, gaining such basic project knowledge through its review of the project’s available:

1. Business Case, Project Charter;

2. Work Plan and Work Breakdown Structure;

3. Approved (original or current) baseline project budget and schedule;

4. Integrated Project Plan and related supporting plans; and

5. Other major project deliverables produced by the Authorized Purchaser or its other project consultants that relate to the project’s functional, non-functional, and security requirements.

The Deliverable should include:

1. Risk Identification (providing a description, level of impact, probability of occurrence, and measurable threshold to trigger the risk);

2. Risk Avoidance Plan (recommending specific solutions to avoid the triggering of each risk);

3. Risk Mitigation Plan (recommending specific risk mitigation solutions for each identified risk, including a cost-benefit analysis for each mitigation option along with specific recommendations);

4. Risk closeout criteria (measurable criteria for when the risk is considered resolved or no longer active); and

5. For projects under the oversight of EIS, the EIS Project Assessment Report (completing a “forward view” column for all metrics identified therein). (See Appendix B.)

Base template:IQMS SOW Narrative and Appendices (v2025)

2. Deliverable 1.2: Risk Notification

As needed between periodic reports, the IQMS Consultant shall promptly report via email or phone call to the Authorized Purchaser’s authorized representative the discovery of problems, new risks, or previously known risks that have increased in risk probability or potential impact;

and which pose a risk of failure or danger to the success of the project. Within three (3) business days of Authorized Purchaser’s request, if any, the IQMS Consultant shall follow up its initial risk notification with the submission of a written report.

If one is required by the Authorized Purchaser, the written risk notification report, as part of the on-going activities, should follow the same requirements as defined for the initial risk assessment, with an emphasis on managing risks that occur and change during the development and implementation process. The IQMS Consultant should conduct a risk assessment while conducting periodic reporting under Task 3 Quality Control and Task 4 Quality Assurance. At a minimum, the risk assessment should:

1. Monitor the solution’s hardware, software, infrastructure, and data security requirements and risks as they apply to the project’s progress to ensure that the solution meets project requirements;

2. Where applicable, review the Business Continuity Plan, the Disaster Recovery Plan and audit controls to ensure the security of any Authorized Purchaser protected or confidential information at risk in the project; and

3. Review implementation tasks and activities to ensure that the confidentiality, integrity and availability of the solution are not compromised.

FOR THE TASK 1 DELIVERABLES RELEASED UNDER THE CONTRACT, REFER TO SECTION 3 OF

THE STATEMENT OF WORK: DELIVERABLES AND PAYMENT SCHEDULE.

2.2 Task 2: Quality Planning

The IQMS Consultant may be required to establish a quality management system for the Project. The typical system is comprised of a quality management plan that includes all requisite quality standards, quality checklists for quality control reviews, quality control and quality assurance report templates, and quality control and quality assurance processes. The established quality management system should define the Project work tasks and resourcing that will add value and reduce risk subject to the constraints of available Project resources and applicable organizational policies, Oregon Revised Statutes, Oregon Administrative Rules, and statewide policies and standards.

The IQMS Consultant’s work should adhere to generally accepted industry practices for project management and system life cycle management. In addition, the IQMS Consultant should

Base template:IQMS SOW Narrative and Appendices (v2025) consider the Project’s quality management guide or plan as a reference2. QMS Deliverables, should conform to the Project Management Institute’s (PMI) Standard as described in the current edition of the Project Management Body of Knowledge (PMBOK) and International Standards Organization standard ISO12207 for software development life cycle processes.

Through its established quality management system, the IQMS Consultant should ensure that the Project plans, standards, processes and work tasks fit the Project’s needs, and verify that they will be usable for performing quality control reviews, inspections, and uncovering quality risks throughout the life cycle of the Project. The emphasis of this task is to confirm that quality is planned into the Project versus a reactive quality approach that measures quality through audits completed after the work is done.

A quality management system usually includes the following Deliverables:

1. Deliverable 2.1: Quality Standards - Operational Definitions

This Deliverable sets out the written operational definitions for the identified Quality Standards applicable to the Project products and processes. The Deliverable describes in very specific terms, what the standards are, and how each will be measured by the quality control process.

The IQMS Consultant must consider the Oregon Quality Standards set out in Appendix A in developing Deliverable 2.1. The IQMS Consultant must apply to the Project those Oregon Quality Standards denoted with an asterisk. For the other Oregon Quality Standards, the IQMS Consultant may apply, supplement, modify, or omit them from application to the Project as appropriate by performing the following services:

1. Identify from the template the relevant process and product quality standards, risk cues or measurements that are appropriate for the Project based on the Project’s current business and technical complexity assessment.

2. Recommend additional quality standards based on the type of project, current phase of the project, or expert opinion where the absence of a quality standard would present high risk to the project.

3. Recommend elimination of unnecessary quality standards based on the Project’s business and technical complexity assessment or current phase of the Project.

Appendix A incorporated into this Contract by reference in Section 4 of the Statement of Work, sets out the Oregon Quality Standards that may apply to Major IT Initiatives and other IT projects under EIS oversight. Some of these may be modified or omitted depending upon the nature and scope of the project, but the following Appendix A standards are required on Major IT Initiatives and other IT projects under EIS oversight:

2 The Authorized Purchaser is ultimately responsible for the delivery of project work products with good quality; and its integrated project plan should comply with industry standards and include a quality management guide or plan.

Base template:IQMS SOW Narrative and Appendices (v2025)

Required Process Quality Standards:

1. Project alignment with strategy and business needs; solution sourcing (standards #1, 8)

2. Definition of the project scope; project objectives; leadership; project management approach; project management authority; project governance and decision making;

budget and resource size; cost controls; project schedule(standards #12, 13, 14, 15, 19, 21, 26, 28, 29)

3. Team member availability; team productivity; organization stability; executive support;

user involvement; user acceptance (standards #31, 35, 37, 41, 48, 49)

Required Product Quality Standards:

1. Clear and complete requirements; testability; implementation difficulty (standards #55, 57, 58)

2. Change control process; development or configuration documentation; solution development / engineering; testing strategy and plan; testing traceability (standards 63, 65, 66, 69, 70)

3. Availability of technology expertise; IT support services impact; deployment approach (standards 74, 83, 86)

4. Design complexity; transition to operations and maintenance; compliance with applicable security standards (standards 88, 92, 94)

2. Deliverable 2.2: Quality Checklists

For each Authorized Purchaser or other consultant deliverable identified for quality control review under Deliverable 3.1, the IQMS Consultant shall determine, and document in quality checklists, how to monitor and measure the applicable Quality Standards identified in Deliverable 2.1. These checklists should have the following attributes:

1. Indicate the schedule for reviews, including the deliverable(s) under review, the person(s) responsible for the deliverable(s), and the person(s) responsible for conducting the reviews.

2. Indicate a specific review procedure to follow, e.g. a procedure for schedule analysis, code walk-through, peer review, interviews, lessons learned, test methodology, or if the review will be performed informally.

3. If appropriate, verify and record that a set of required inspections have been performed.

4. Indicate that the minimum quality standard(s) has been met.

5. Record the measurements.

6. Identify the expected risk cue or measurement.

7. Indicate the expected acceptability or tolerance.

8. Indicate the risk rating for each reviewed quality standard.

9. Indicate a reference that will describe what was reviewed, who was interviewed, and the information or reasoning that justifies a conclusion that non-adherence to a specific quality standard causes risk.

Base template:IQMS SOW Narrative and Appendices (v2025)

The process of measurement, setting tolerance, and risk ranking may be based on the IQMS Consultant’s subject matter knowledge, domain experience, and expert opinions.

The quality checklists should conform to the specific choice of system life cycle model applicable to the Project, especially concerning detailed requirements definition, general and detailed system design, test design, test planning and execution, and system implementation.

3. Deliverable 2.3: Quality Management Plan (QMP)

The Quality Management Plan (QMP) defines how the IQMS Consultant will conduct Quality Assurance (QA), Quality Control (QC), Independent solution or system testing, and Risk Assessment on the Project. The IQMS Consultant must adhere to generally accepted industry practices for project quality management and solution development quality management; and should review and use as key input all available Project planning artifacts, including any guidance provided by the Authorized Purchaser in writing or orally; the current version of the PMBOK; and ISO 12207. At a minimum, the QMP should include the following:

1. Identification and definition of IQMS Consultant, other consultant, EIS and Authorized Purchaser staff roles and responsibilities; and the procedures and resources needed from such personnel to implement the Quality Management Plan.

2. Identification of all the work tasks to be performed by the IQMS Consultant, and the activities required of the Authorized Purchaser and EIS needed to facilitate the IQMS Consultant’s assessment of the specified and relevant process and product quality standards. The following items should be considered for inclusion in the QMP:

a. A detailed plan for Quality Assurance Review, including scope, criteria, and the methodology to be employed;

b. A detailed plan for Quality Control, including scope, criteria, methodology, and, if applicable, Independent solution testing;

c. The quality management tools to be used (may reference applicable, currently approved documents):

i. Quality standards;

ii. Quality checklists;

iii. Templates for all reporting types required during the lifecycle of the Project; e.g. Quarterly QA Status & Improvement Report, QC Review Reports, Monthly Status Report, On-Going Risk Notification Report, and so on;

iv. Additional quality tools and methods as needed; and

d. Risk Assessment Methodology

4. Deliverable 2.4: Baseline QMS Work Plan

This Deliverable specifies the IQMS Consultant’s manner and means for developing and submitting, for the Authorized Purchaser’s review and acceptance, the required QMS

Base template:IQMS SOW Narrative and Appendices (v2025)

Deliverables. The IQMS Consultant must update this plan as needed. The plan should describe the following elements:

1. The general approach to achieve QMS Contract requirements;

2. Schedule;

3. A detailed work breakdown structure, with key milestones, critical path elements, and

QMS Deliverables identified;

4. The estimated resource requirements to complete the required work;

5. A staffing plan with the Consultant’s key persons identified;

6. An assessment of all levels of assistance needed from the Authorized Purchaser, its staff, and the other Project consultants, including but not limited to hands-on participation, facilities, and infrastructure; and

7. A clear link to the overarching Project plan and schedule, including the solution contractor’s plans and schedule.

Depending upon the nature and timing of the IQMS Consultant’s involvement in the Project, to develop and complete the Baseline QMS Work Plan, the IQMS Consultant shall complete some, most, or all of the following activities:

1. Conduct an initial risk assessment in compliance with Task 1;

2. For projects under EIS oversight, review the approved business case on file with EIS;

3. Review all available planning artifacts from the Authorized Purchaser, e.g. Integrated

Project Plan, supporting plans, and quality management guidance;

4. Review applicable standards, including technology and security standards;

5. Review the Project’s documented requirements, including functional, non-functional, and security requirements;

6. Review the solution contractor’s statement of work and related documentation, especially its plan, solution development methodology, data conversion and interface plans, and training plan as applicable.

5. Deliverable 2.5: Special Requests

At the Authorized Purchaser’s request, and if not already required in connection with another QMS Deliverable, the IQMS Consultant may be required to appear before various committees or individuals to discuss the overall strategic direction and progress of the Project, or complete other “special” work. Special work includes independent analysis, recommendations on unforeseen problems, opportunities for improvement, research and recommendations on alternative courses of action, and additional risk management activities. In the instances requiring internal/external presentations, the IQMS Consultant may be required to accompany the Authorized Purchaser’s staff to make presentations, help answer questions, and provide the Consultant’s assessment of confidence on the Project’s ability to satisfy its declared goals and objectives.

Base template:IQMS SOW Narrative and Appendices (v2025)

In response to a Deliverable 2.5 request, and within the time prescribed in the request, the IQMS Consultant shall provide the Authorized Purchaser with a written fixed cost proposal and schedule.

6. Deliverable 2.6: Project Evaluation/Lessons Learned Report

The Authorized Purchaser may require the IQMS Consultant to facilitate a “Project Evaluation/Lessons Learned” process at the end of each Project phase or at the close of the Project, and create a report of the findings. Deliverable 2.6 may become a periodic Deliverable or the final Deliverable under the QMS Contract. At a minimum, this Deliverable should reflect review and analysis of the Project’s quarterly Quality Assurance Status and Improvement Reports. Its minimum content should reflect:

1. Independent evaluation of Project performance, to include:

a. Degree of attainment of business objectives. Document how Project performed against each objective established in Project planning documentation.

b. Degree of realization of anticipated benefits: Document the primary benefits the agency projected would be realized/attained (benefits or ROI targets). Document whether those benefits were obtained (or are expected to be obtained) by Project.

c. Degree of attainment of budget objectives. Document the planned cost and funding for Project, as approved in Project documentation. Document the actual cost and funding at the end of Project phase (if applicable) or at completion.

Document and explain all cost and funding variances, including approved changes to the cost baseline.

d. Degree of adherence to schedule: Compare the approved schedule baseline against the actual completion dates. Document and explain any schedule variances, including approved changes to the schedule baseline.

e. Degree of satisfaction of user requirements: Document any changes to the requirements and their impact on performance, cost, or schedule baselines.

f. Progress made: List the major Project deliverables and the date each was accepted by project. Identify any contingencies or conditions related to the acceptance. Document any planned tasks or deliverables that remain to be completed before Project can close.

2. Lessons Learned

a. Risks, problems, and delays encountered in the Project;

b. Mitigation actions taken or not taken, and why;

c. Successes and mistakes made;

d. Project specific insights; and

e. Actionable recommendations for future phases, similar projects, and/or future enhancements.

3. Description of the inputs and methods used to create the Project Evaluation / Lessons

Learned Report, including meetings attended, artifacts reviewed, interviews conducted, and approach to eliciting lessons learned (e.g., workshops, surveys, etc.).

FOR THE TASK 2 DELIVERABLES RELEASED UNDER THE CONTRACT, REFER TO SECTION 3 OF

2.3 Task 3: Quality Control (QC)

This task monitors Project results to determine if they comply with stated Project requirements.

Project results include both work product results, notably deliverables, and project management results, notably schedule and cost performance. In general, this Task includes the:

1. Review of Project activities and inspection of Authorized Purchaser and contractor work product deliverables throughout the life of the Project in terms of their ability to meet the performance requirements for scope, schedule, and cost. This evaluation should be done at the level of a specific work product deliverable in the context of its impact on subsequent deliverables to verify compliance and provide the Authorized Purchaser with visibility into the Project’s adherence to its established plans, process and product standards, and work tasks;

2. Review of work product compliance with Authorized Purchaser security standards, especially in relation to system access.

3. Review of the solution contractor’s deliverables for completeness and accuracy, as well as identifying and assessing issues and risks at the work product level. In ascertaining whether the solution contractor’s work products meet Authorized Purchaser requirements, the IQMS Consultant shall pay particular attention to the scope, execution, and results of the solution contractor’s test plans.

4. Review of other consultant’s (e.g., IT Professional Services consultant) deliverables for completeness and accuracy, as well as identifying and assessing issues and risks at the work product level.

5. Identify and discuss issues within the Project for resolution, if possible. Address the escalation of issues not resolvable within the Project to the Project’s Steering Committee or otherwise in accordance with the Project’s governance processes.

1. Deliverable 3.1: Quality Control Reviews (of foundational project management documentation and solution contractor deliverables)

Authorized Purchaser may require detailed Quality Control reviews and reports for foundational project management documents and major consultant deliverables, including the solutions consultant’s Project Plan. Each Quality Control report shall be treated as a separate Deliverable with all applicable Deliverable 2.2 Quality Checklists completed and attached.

Quality Control reviews and reports shall comply with the Deliverable 2.3 Quality Management Plan, the approved Deliverable 2.1 Quality Standards, and Deliverable 2.2 Quality Checklists.

The Quality Management Plan, Quality Standards, and Quality Checklists should indicate the

Base template:IQMS SOW Narrative and Appendices (v2025) type of review expected, e.g. data analysis, schedule analysis, standards or process conformance analysis, and additional analysis based on subject matter expertise. For projects under EIS oversight, the completed Quality Control reviews and reports, including their related Quality Checklists, are inputs to the Deliverable 4.1, Quarterly Quality Assurance Status and Improvement Reports and related EIS Project Assessment Report (Appendix B to the Scope of Services).

The precise nature of Quality Control reviews for particular solutions contractor deliverables may need adjustment to accommodate the specific choice of the applicable solution development life cycle model.

2. Deliverable 3.2: Security Review

The Authorized Purchaser reserves the right to require the IQMS Consultant to conduct additional reviews regarding details of system design, development, and implementation as they relate to security standards compliance and meeting security related functional and non-functional requirements. In carrying out this work, the Authorized Purchaser may require the IQMS Consultant to participate in major reviews of the modules or the subsystems that are developed or customized specifically for the Project’s solution. The type of reviews may include architecture, design, system integration, and code level reviews as they relate to information security. The areas for review and examination may include:

1. User Authentication

2. Role Based Security

3. Database Connectivity

4. Password Validation

5. Encryption

The IQMS Consultant should determine the appropriate modules and subsystems for review and the nature of the review. Input from state personnel, e.g., EIS Cyber Security Services (CSS), or the state’s contractors may be sought but cannot substitute for industry standards, best practices, and applicable knowledge and judgement that the IQMS Consultant must apply independently. Also, the IQMS Consultant should schedule and conduct these reviews, in consultation with the Authorized Purchaser, EIS CSS (if applicable), and the solutions consultant, within the context of the Project’s overall plan and schedule.

Base template:IQMS SOW Narrative and Appendices (v2025)

3. Deliverable 3.3: Quality Status Reporting

The Authorized Purchaser may require the IQMS Consultant to provide periodic reporting to monitor project results related to quality and risk management activities. IQMS Consultant must regularly engage with the project in order to prepare a Quality Status Report that documents Project status in the following areas:

1. Project Quality Status

a. For the overall Project;

b. For each element on the work breakdown structure in the Baseline QMS Work

Plan being executed; and

c. Tracking of recommendations made through Deliverable 4.1 Quality Assurance

Status and Improvements Report or other channels designated by the Authorized Purchaser and, as appropriate, EIS. This tracking should include reporting on progress made by the Project in addressing previously-identified risks, issues, and recommendations.

2. Risk Notification Report per Deliverable 1.2.

The report should include a description of inputs used in creating the report, including meetings attended, artifacts reviewed, and interviews conducted.

FOR THE TASK 3 DELIVERABLES RELEASED UNDER THE CONTRACT, REFER TO SECTION 3 OF

2.4 Task 4: Quality Assurance (QA)

In general, the Quality Assurance Task focuses on the quality management of the Project’s processes. Through such Task the IQMS Consultant should provide overall Project quality review; periodically examine Quality Control review results, Quality Checklists, change requests and tracking; and summarize the results of such review and analysis for executive review and oversight throughout the life of the Project. For this purpose, EIS will obligate Authorized Purchasers to require the IQMS Consultant to create and deliver quarterly Quality Assurance Status and Improvements Reports and Presentations summarizing the overall Project status, performance, risks and recommendations for process improvement.

Base template:IQMS SOW Narrative and Appendices (v2025)

1. Deliverable 4.1: Quarterly QA Status and Improvement Reports / Presentations3

The Deliverable - QA Status and Improvement Report should include the following items:

1. Overall risk rank for the Project;

2. An Executive Summary for the entire report, which includes information such as:

a. A summary of Project progress and accomplishments since the last report;

b. A summary of expenditures to date compared to budgeted Project dollars;

c. Identification and resolution of all problems encountered;

d. Plans, milestones and deliverables for the coming period;

e. A 3-month rolling risk matrix by assessment area;

f. Assessment of overall risk to the Project;

g. Evaluation of the overall Project status, budget and schedule variance, schedule and stage of completion, indicating the causal factors, mitigation efforts and recommendations; and

h. For projects under EIS oversight, evaluation of the Project’s ability to deliver the benefits and results stated in the approved business case on file with EIS;

3. Summary of the current progress followed by major Project milestones. At a minimum the report must contain a progress, status and risk analysis for the following assessment areas, in addition to other areas determined by the Authorized Purchaser to be critical for monitoring purposes:

a. Project Management;

b. Organizational Change Management;

c. Budget: Actual expenditures compared to original (or current baseline) Project budget;

d. Schedule: Project schedule performance compared to original (or current baseline) schedule;

e. Project scope;

f. Resources and staff;

g. Deliverable quality;

h. Business impact;

i. Technology;

j. Funding;

k. Development and Implementation;

l. Facilities and Support; and

m. Security.

3 The exact dates of the End of Quarter will be specified in the Baseline QMS Work Plan. These dates will take into account and include but not be limited to, Consultant start date, and Oregon’s Joint Legislative Committee on Information Management Technology hearing dates.

Base template:IQMS SOW Narrative and Appendices (v2025)

4. Brief Project effectiveness statements on all the high-level categories from the approved Quality Standards:

a. Categories where no risks were identified should simply be indicated in one line, for example: Decision Drivers – no risks currently identified, or not evaluated at this time;

b. Categories that contained a significant risk shall describe the risk, describe the factors used to determine the risk, estimate probability of occurrence, describe the potential impact, indicate the risk severity rating, and provide a recommended resolution strategy. At a minimum the resolution strategy should include:

i. Status of risks that must be monitored, identifying probability of occurrence and potential impacts;

ii. Identification of trigger points for intervention for each risk;

iii. Recommended and alternative correction actions plans, with options identified, presented for each identified risk to prevent and/or reduce potential for the risk occurring or the danger escalating;

iv. Intervention strategies to address any risk(s) that exceed a trigger point, to include a definition of options available to address the risk, the potential affects and costs of implementing the strategy, a comparative summary of the alternative strategies and identification of a recommended strategy;

v. Updates on progress made by the Project in addressing previously-identified risks and recommended response strategies; and

vi. Implications for the solution contractor’s Project Plan;

5. Risks resolved since last period. Provide the previous risk rank, and brief status or the actions taken on risks and results; and

6. For projects under EIS oversight, completed EIS Project Assessment Report. (See

Appendix B.)

7. Description of inputs for the QA Status and Improvement Report, including meetings attended, artifacts reviewed, and interviews conducted.

FOR THE TASK 4 DELIVERABLES RELEASED UNDER THE CONTRACT, REFER TO SECTION 3 OF

Base template:IQMS SOW Narrative and Appendices (v2025)

2.5 Task 5: Independent Solution Testing

The purpose of this IQMS Consultant Task is to ensure that the solution and its components, as delivered by the solutions consultant, are functional, stable, and secured as defined by approved Project requirements.

1. Deliverable 5.1: Independent Master Test Plan (IMTP)

As appropriate under the circumstances, the IQMS Consultant’s IMTP should include relevant plans, methodologies, development procedures, and bug tracking for Independent Testing on a sampling basis. Because the solutions consultant’s deliverables may contain software elements that have been previously deployed and proven stable, the IQMS Consultant’s Independent Testing shall focus on the testing of high risk and new code areas, especially security access and control. High risk areas include critical items such as sub-system integration, interfaces to other data systems, and other data processing systems. At a minimum, the IMTP should include the following elements:

1. Identification of potential high risk or new code areas;

2. Test Definition and Test Matrix;

3. Detailed Test Script Development Procedure;

4. Detailed Configuration and Build Control Procedure;

5. Testing Procedure;

6. Testing Environment;

7. Test Scripts; and

8. Testing Metrics and Reporting.

The nature of Independent Testing may vary greatly depending on the solution and solutions consultant selected by the Authorized Purchaser.

2. Deliverable 5.2: Independent Test Execution and Status Reports

The IQMS Consultant should prepare for and conduct Independent Testing, and provide Test Execution and Status Reports periodically according to the schedule established in the IMTP.

These reports should include items such as:

1. Number of total tests to be conducted for the Project;

2. Number of tests per high risk or new code areas of the solution;

3. Number of tests conducted, completed, and awaiting retest;

4. Types of bugs correlated to the areas of test; and

5. Summary of the results of each security test.

Base template:IQMS SOW Narrative and Appendices (v2025)

Deliverable 5.3: Independent Security-Related Testing

The IQMS Consultant should prepare for and conduct Independent Security-Related Testing, and provide Test Execution and Status Reports periodically according to the schedule established in the IMTP.

FOR THE TASK 5 DELIVERABLES RELEASED UNDER THE CONTRACT, REFER TO SECTION 3 OF

THE STATEMENT OF WORK: DELIVERABLES AND PAYMENT SCHEDULE.

3. Deliverables and Payment Schedule Deliverable Review and Acceptance. IQMS consultant shall provide written notice to Authorized Purchaser upon delivery of a completed Deliverable to Authorized Purchaser. By no later than (i) fifteen (15) business days after receipt of such notice, or (ii) the date set forth for Authorized Purchaser’s review in the current accepted Baseline QMS Work Plan, Authorized Purchaser will determine whether the Deliverable meets acceptance criteria set forth in the contract. Acceptance criteria include all requirements for a Deliverable and associated Services described in the Statement of Work, and the Performance Warranties in the IQMS Consultant’s MPSA and its amendments. If Authorized Purchaser determines that the Deliverable meets, in all material respects, acceptance criteria, Authorized Purchaser will notify IQMS Consultant of Authorized Purchaser’s acceptance in writing.

If the Authorized Purchaser determines that a Deliverable does not meet the acceptance criteria in all material respects, Authorized Purchaser will notify IQMS Consultant in writing of Authorized Purchaser’s rejection of the Deliverable, and describe in reasonable detail in such notice the Authorized Purchaser’s basis for rejection of the Deliverable. Upon receipt of notice of non-acceptance, IQMS Consultant shall, within a fifteen (15) business day period, modify or improve the Deliverable at IQMS Consultant’s sole expense so that the Deliverable meets, in all material respects, the acceptance criteria, and notify the Authorized Purchaser in writing that it has completed such modifications or improvements and re-tender the Deliverable to Authorized Purchaser. Authorized Purchaser will thereafter review the modified or improved Deliverable within fifteen (15) business days of receipt of the IQMS Consultant's delivery of the Deliverable.

The Authorized Purchaser shall make payments to IQMS Consultant based on successful delivery of completed Deliverables and accepted in writing by Authorized Purchaser. IQMS Consultant shall cooperate with this process regarding Deliverables review and acceptance.

Maximum Not-to-Exceed Payment. For each Accepted Deliverable, IQMS Consultant shall invoice for cost of actual effort; compensation for which may be less than or equal to, but shall not exceed, the listed maximum not-to-exceed (NTE) cost for the subject Deliverable.

Base template:IQMS SOW Narrative and Appendices (v2025)

Change Control. The Parties may use the Contract’s Change Control procedures under Section

7.2 of the Contract to document certain changes to the Deliverables and Payment Schedule, such as:

1. Authorized Purchaser’s release to IQMS Consultant of Tasks previously reserved to Authorized Purchaser for such release; provided the Parties previously negotiated the cost for such Tasks and included such costs in Section 6.1 of the Contract, Maximum Payment Amount; the

2. Parties’ agreement to adjust Deliverable costs by moving money between Deliverables;

provided such adjustments do not increase the current Maximum Payment Amount under the Contract; and the

3. Parties’ agreement to adjust Deliverable Due Dates or to completely cancel one or more current Deliverables.

Courtesy DED Submission. For each required Deliverable category (and by particular Deliverable instance within a category according to mutual agreement between Authorized Purchaser and IQMS Consultant), IQMS Consultant shall provide a courtesy Deliverable Expectation Document (“DED”) at least ten (10) Business Days before required submission of the subject Deliverable(s). A DED must include pertinent information specifying the expectations of the subject Deliverable (for example, Deliverable format and summary description of each Deliverable component in the context of such format).

Unless otherwise noted elsewhere in the Contract, such DEDs are not payment Deliverables and should not be subject to the Contract Deliverable Review and Acceptance provisions regarding required resubmission of a corrected Deliverable. Any corrective action regarding any such DED must be manifested in the initial submission of the actual Deliverable previewed in the

DED.

Hourly Rate Card. The Hourly Rate Card set forth as part of the Deliverables and Payment Schedule reflects the hourly rates that IQMS Consultant will use in determining proposed prices for additional Deliverables released through Contract amendment or change order as appropriate. Hourly rates may be less than or equal to, but not exceed, hourly rates established in the IQMS Consultant’s MPSA.

Base template:IQMS SOW Narrative and Appendices (v2025)

Pricing Sheet. For each Deliverable below listed in Pricing Sheet as an “OPTION RESERVED TO AUTHORIZED PURCHASER” with a designated NTE Deliverable Cost, Authorized Purchaser may elect to select that option by issuing a notice to proceed to IQMS Consultant. For Deliverables listed as an “OPTION RESERVED TO AUTHORIZED PURCHASER” without a designated NTE Deliverable Cost, the parties will need to amend this SOW or issue a change order to establish the pricing of such deliverables prior to work on such deliverables.

Pricing Sheet and Rate Card - Statewide Payroll Transformation Project

Refer to RFQ Exhibit 2 – IQMS SOW Deliverables Pricing Sheet.

4. Appendices The Authorized Purchaser and IQMS…