1723-669 attachment 01 - sow slr pricing bhd · (iso) 20000 practices for service management and...

SOW, SLR, Pricing, BHD Attachment 01

Washington State Department of Social and Health Services 1

Contents

1. General Information ............................................................................................................. 3

1.1. Legal Introduction ................................................................................................................ 3

2. Statement of Work ............................................................................................................... 4

2.1. Background .......................................................................................................................... 4

2.2. Statement of Work Objectives ............................................................................................. 5

2.3. Statement of Work ............................................................................................................... 9

2.4. Non-Formalized Services Inclusion ................................................................................... 31

2.5. Retained Responsibilities .................................................................................................. 31

2.6. Outsourced Responsibilities .............................................................................................. 32

3. Service Environment ......................................................................................................... 34

3.1. Applications and Licenses ................................................................................................. 34

3.2. Applications Technical Architecture .................................................................................. 36

3.3. Applications Workload ....................................................................................................... 36

3.4. Service Delivery Facilities — Generic ............................................................................... 37

3.5. Service Delivery Compliance ............................................................................................. 37

4. Application Services .......................................................................................................... 39

4.1. Application Development Services .................................................................................... 39

4.2. Application Warranty Services ........................................................................................... 44

4.3. Application Maintenance Services .................................................................................... 45

4.4. Release Packaging ............................................................................................................ 48

4.5. Technical and End-User Support ...................................................................................... 48

4.6. Monitoring, Reporting and Review .................................................................................... 48

5. Roles and Responsibilities ................................................................................................ 48

6. Service Levels and Reporting ............................................................................................ 48

6.1. Service-Level Requirements ............................................................................................. 48

6.2. Reports .............................................................................................................................. 49

7. Pricing Model ..................................................................................................................... 50

8. Behavior Drivers ................................................................................................................ 52

8.1. Definition ............................................................................................................................ 52

8.2. Commitment to Comply with All SLRs. .............................................................................. 52

8.3. Root-Cause Analysis and Resolution. ............................................................................... 52

8.4. Relief from SLRs. .............................................................................................................. 53



8.5. Review of SLRs. ................................................................................................................ 53

8.6. Benchmarking. ................................................................................................................... 54

8.7. Characterization Period. .................................................................................................... 54

8.8. Service Credits. ................................................................................................................. 54

8.9. Earn-Back .......................................................................................................................... 55

8.10. Failure ................................................................................................................................ 55

8.11. Credits Returned 1st .......................................................................................................... 55

8.12. Measurement Period 7 ...................................................................................................... 55

8.13. Measurement Period 8 ...................................................................................................... 56

8.14. Credits Returned 2nd ........................................................................................................ 56

8.15. Measurement Period 10 .................................................................................................... 56

8.16. Measurement Period 11 .................................................................................................... 56

8.17. Review of Service Levels and KPIS .................................................................................. 56

8.18. Startup Timing ................................................................................................................... 56

9. Referenced SOW Appendices, MSA Articles and Attachments ........................................ 57

10. Revision History ................................................................................................................. 57

11. SOW Acceptance .............................................................................................................. 58

12. Appendix [AS.1] Applications and Licenses ...................................................................... 59

13. Appendix [AS.1 sub A] Application Architecture ................................................................ 59

14. Appendix [AS.1 sub B] Application Workload .................................................................... 59

15. Appendix [AS.3] Facility Security Requirements ............................................................... 59

16. Appendix [AS.4] Application Services Policies Procedures .............................................. 60

17. Appendix [AS.5] Regulatory Compliance Requirements ................................................... 60

18. Appendix [AS.9] Application Architecture Guidelines ........................................................ 60

19. Appendix [AS.10] Service Level Requirements ................................................................. 61

19.1. SLR Tower – Quality ......................................................................................................... 62

19.2. SLR Tower – Efficiency ..................................................................................................... 64

19.3. SLR Tower – Availability .................................................................................................... 66

19.4. SLR Tower – Security ........................................................................................................ 68

19.5. SLR Tower – Application Development ............................................................................. 69

19.6. SLR Tower – Computing Services .................................................................................... 71

19.7. SLR Tower – Staffing/Resources ...................................................................................... 73



1. General Information

This section introduces the outsourcing application services statement of work (SOW), organization-retained responsibilities, provides an overview of the services to be performed, and identifies the objectives that the organization seeks from the application services outsourcing relationship.

1.1. Legal Introduction 1.1.1. This Statement of Work (SOW), including its Appendices, is part of the

Agreement between DSHS and the Provider, and should be read and understood in the context of that Agreement. The Agreement is governed by the Master Service Agreement (MSA) document to which this SOW is an Attachment. In the event of a conflict between this SOW and the MSA, the MSA will prevail unless specifically stated otherwise. This SOW can only be altered in accordance with the Contract Change Control procedure as set out in Attachment 3, Contract Management to this Agreement.

1.1.2. Definitions used in this SOW have the meaning as set out in the MSA. Where additional terms and/or a glossary is included in this Attachment, such additional terms and/or glossary only apply to this Attachment.

1.1.3. The Provider must provide the Services as described in this SOW to DSHS, including any additional services that the Provider has committed to provide during the contract term. The Services include all functions, tasks and responsibilities as accepted by the Provider.

1.1.4. The Provider must manage and perform the Services, and must do so using DSHS Policies and Procedures, including Information Technology Infrastructure Library (ITIL) practices to set the nomenclature, Capability Maturity Model Integration for services (CMMi-SVC) to set application development practices, International Organization for Standardization (ISO) 20000 practices for service management and Six Sigma as the foundation for continuous improvement processes.

1.1.5. The Services described in this SOW cover all aspects of application development, maintenance and support for packaged and custom build or customized applications.

1.1.6. The Services described in this SOW are intended to be comprehensive, but are not all-inclusive in describing the particular activities, resources or other details necessary for the proper performance of the Services.

1.1.7. The Provider must provide the Services described in this SOW as they evolve and change during the contract term, through the change control process. This may include modifying, changing, replacing, supplementing and enhancing the included Services over time.

1.1.8. Throughout this document, where references are made to equipment/hardware and applications supported, this is subject to DSHS's approval and compliance with DSHS's policies.



2. Statement of Work

2.1. Background

The Department of Social and Health Services (DSHS) administers federal and state policies and procedures for delivering Health and Human Services (HHS) benefits to clients across the state of Washington using the Automated Client Eligibility System (ACES). ACES is the eligibility determination and case maintenance system for public assistance programs such as Temporary Assistance for Needy Family (TANF), and Basic Food, that supports state and federal medical programs for the State of Washington. The ACES Complex of Applications is a large, and comprehensive system, supporting up to 6,000 users in over 90 locations throughout the state and controlling over $2 billion in annual client benefits.

The ACES Complex of Applications (both mainframe and web environments) is made up of ACES, the Eligibility Service, Washington Connection, Enterprise Data Warehouse, and other application systems and sub-systems as defined in Section 5 of ACES Technical Information document. The Eligibility Service was developed to support the Affordable Care Act (ACA) and the Washington Health Benefit Exchange (HBE) Healthplanfinder application. Washington Connection is a public facing web application supporting client application for public assistance benefits, eligibility reviews, and reporting changes in circumstances. The application is used by the public as well as Community Based Organizations, and includes a Client Benefit Account to provide personalized benefit information. DSHS owns the intellectual property and reserves all rights to the ACES Complex of Applications systems and sub-systems.

The ACES Complex of Applications is the Washington state public assistance system that supports a variety of statewide functions and payment processes including:

• Client intake and screening, including face-to-face and via telephone

• Application processing, including “online” applications

• Scheduling for eligibility determination and review

• Multi-program eligibility determination

• Automated benefit calculation and benefit issuance (Electronic Benefit Transfer (EBT) and Electronic Funds Transfer (EFT))

• Client notifications including eligibility and benefit changes

• Eligibility screening for the HBE Healthplanfinder

• More than 70 state and federal system interfaces

• Reports and inquiries needed for routine operation, as well as those required for primary research functions, forecasting, and budgeting

The online environment is supported by both mainframe Customer Information Control System (CICS) and JAVA/.Net applications. In addition to the online



environment, ACES has a large daily and nightly batch component which supports the day-to-day updates of applicable eligibility files and sharing of information to DSHS’ interface partners.

ACES was implemented in 1996 and originally developed as a mainframe system using COmmon Business-Oriented Language (COBOL) and IBM Information Management System Database (IMS DB). Over the years, some portions of the system have moved to a web platform and DB2 database, but the majority of the system still resides in COBOL and IMS non-relational database programs. ACES maintains a data warehouse component that integrates both Windows and Linux environments. The Eligibility Service and Washington Connection were developed using the Java Spring Framework, DB/2 and Operational Decision Manager (ODM) for business rules development.

IMS DB is the primary database used by ACES to manage and store its application data and is the State of Washington’s eligibility system of record. Data residing in the IMS DB is replicated to DB2 in near real time daily for use by other sub-systems within the ACES complex. The DB2 data store is available for use by DSHS’ modern applications.

2.2. Statement of Work Objectives The following are the key high-level Service objectives that DSHS expects to achieve through this SOW:

2.2.1. In-Scope Services

The Contractor shall meet the major objectives identified for each phase of the project:

2.2.1.1. Assessment Phase (consisting of the Initiation Phase and Analysis and Detailed Systems Review/Inventory Phase: The Contractor will review and analyze the systems and sub-systems contained within ACES Complex of Applications including the interfaces to any internal and external systems that may be affected by re-hosting. The inventory (in the ACES Technical Information attachment) identifies the list of systems, applications and interfaces that are impacted by the re-hosting effort.

DSHS requires the selected vendor to accomplish the following as part of the Assessment Phase:

Identify existing architectures to include inventory, analysis and measurement of all software and database components, and source platform architecture

Identify application dependencies

Detail the applications identified within the ACES Complex of Applications, that use DB2, IMS, or both IMS and DB2

Finalize the scope of impacted applications



Identify the tasks, activities, and timelines necessary to successfully complete all phases of the project from initial assessment through implementation

Develop the plans and schedules necessary to perform and track progress of the project tasks, activities, milestones, and resources

Develop a plan for re-hosting identified systems, applications and interfaces

Document project quality objectives and phase readiness criteria

Identify re-hosting issues and risks

Identify essential software and hardware

2.2.1.2. Implementation Phase (consisting of the Platform Specification and Design Phase, Platform and Application Migration Phase and Deployment Phase): The Contractor will provide and install all software and hardware for all required environments and re-host the ACES Complex of Applications and interfaces to the new platform according to the plan developed (in the Initiation Phase) and agreed to by DSHS and the Contractor.

The goals and objectives of Implementation Phase is to:

Prepare design specifications and documentation that reflect the composition and architecture of the proposed system

Identify and describe the detailed processes necessary to prepare, configure, migrate, operate, secure and maintain the new environment

Reduce total operational expenses

Eliminate IMS data replication

Maintain compliance with Federal (CMS,IRS, FNS, etc,.) and DSHS data security standards and protection of ACES data, including transit, storage, backup and recovery

Optimize overall operational performance

Work with DSHS to revise the Disaster Recovery strategy for ACES Complex of Applications under the new platform

Provide maintenance and operations services for the re-hosted environment not including the application development

Meet or exceed current Service Level Agreements (SLAs)

Modernize existing legacy architecture



2.2.1.3. Continuing Modernization Recommendations: DSHS envisions there will be a need to determine next steps to fully modernize the legacy system after re-hosting is completed. The Contractor shall provide a Continuing Modernization Recommendations Report which shall include an assessment of risks and issues related to the legacy system and recommendations for modernization covering the following areas:

Database modeling and redesign

Infrastructure and systems reengineering

Utilization of a modern rules engine

Security monitoring, compliance, and enhancements

Batch processing

Resources, skills and experience needs

Options for re-architecting and modernizing the application code base

The Contractor shall provide the following kinds of services and activities as appropriate to meet the goals and objectives listed. These services, not in any specific order, include but are not limited to:

Project Management for Contractor activities under this contract

Technical Architecture and Infrastructure Design

State security design review, where applicable

System Analysis

Provision, installation, and configuration of the necessary hardware and software needed to implement Contractor solution

Migration of all components related to ACES (i.e., COBOL programs, copybooks, subroutines and databases) from z/OS and z/Linux

Migration of existing Java applications that are operating in z/VM SUSE Linux environment

Customization where approved

Complete Data Migration/Conversion from IMS-DB and DB2 to a target RDBMS, as defined by the vendor. DSHS requires the Contractor to propose target database software that is best suited for the re-hosting environment with minimal changes to the application code.



Testing (i.e., unit, integration, system, regression, performance (stress and load), security, and acceptance (by DSHS)). All testing must be done at a DSHS location.

Note: DSHS does not have a tool to mask data for testing purposes; however, it is a requirement that any test data that begins with production data thoroughly obfuscate confidential information (e.g., names, social security numbers, addresses).

Training, including Manuals and Materials

Knowledge Transfer

Documentation

Change Management

Deployment (Go Live) Support

Post Implementation Support for Maintenance and Operations of hardware and software implemented for the re-hosting solution

Continuing Modernization Recommendations

Recommend Disaster Recovery solutions. The disaster recovery report should contain a recommended DR solution based on the re-hosting environment.

2.2.2. Technical Requirements

This section describes the DSHS target environment requirements.

2.2.2.1. Products Contractor must provide all equipment and associated hardware and software components as defined by the requirements of this RFP and proposed in the contractor’s response. All Products supplied by Contractor for delivery must be of new and original manufacture.

2.2.2.2. Software Ownership Contractor’s Response must include a statement indicating whether the software is owned by Contractor or a third party. If the Contractor is not the owner of the software, Contractor and the Software Owner must agree to the following:

Contractor must identify the software owner and provide contact information; and

Contractor must provide the software owner’s licensing terms; and

Contractor must provide DSHS’ terms and conditions to software owner; and



Software owner must agree to participate in contract negotiations with DSHS.

2.2.2.3. Software Maintenance Contractor shall keep all provided software and software components, up-to-date and functional. The Contractor shall supply current, updated versions of all software and software components provided in accordance with the requirements of this RFP and the Contractor’s proposal, for the duration of the contract. This includes but is not limited to patches, fixes, maintenance releases, libraries, frameworks and utilities necessary to successfully operate and maintain the proposed software in current, secure and functional condition.

2.2.2.4. Hardware and Equipment Maintenance Contractor shall maintain all provided equipment and hardware in complete working order. The Contractor shall promptly troubleshoot, diagnose and resolve hardware and equipment issues and replace any defective or non-functioning hardware or equipment provided in accordance with the requirements of this RFP and the Contractor’s proposal, for the duration of the contract. The Contractor shall apply current, updated versions of all the software, firmware, BIOS, drivers, utilities and related components necessary to operate and maintain the proposed hardware and equipment in current, secure and functional condition.

2.2.2.5. Documentation Contractor shall provide documentation of all product components and features implemented as part of this RFP. Documentation shall include the following:

Operations and User Manuals, and Configuration Planning Documentation for each software component, licensed feature and hardware subsystem provided in accordance with the requirements of this RFP and the Contractor’s proposal.

Links to a product support website containing these documents are acceptable in lieu of physical documents.

DSHS must have the right to make derivative works, update, modify, copy or otherwise reproduce the documentation furnished pursuant to this section at no additional charge.

2.3. Statement of Work DSHS has proposed a set of services and deliverables that it believes to be essential for successful project management and implementation of the Contractor’s proposed solution. This Section has been organized to relate the required services to the phases and deliverables necessary to measure progress toward a successful implementation. Unless



specifically identified as a task to be led or “owned” by DSHS, the Contractor shall assume that its staff will lead the delivery of that service, and completion of related deliverables, with the assigned DSHS staff participating in a supporting and/or subject matter expert role.

It is imperative that DSHS preserve the working relationships with all the integrated teams, vendors, and partners. For a successful engagement, in a highly integrated environment, it is critical that the Contractor exhibit the following throughout all phases of the work:

The ability to integrate successfully with and collaborate/partner well with existing vendors and staff.

Teamwork and cohesive team approach to problem solving.

The ability to independently manage relationships without reliance upon the State.

The ability to successfully integrate existing human resources into a technical project.

All Phases (i.e., Assessment Phase, Implementation Phase) and deliverables identified in the Statement of Work must be documented in the Project Work Plan. Initial work products or changes to work products within Section 6 Statement of Work, must be approved by DSHS prior to commencing work.

2.3.1. Initiation Phase

The Contractor shall provide the following deliverables and associated services to ensure proper project planning, execution, and monitoring and controlling of project work.

2.3.1.1. Project Work Plan

The Project Work Plan must include tasks to be performed by both DSHS and Contractor Personnel for all phases of the project. The following elements must be included in the Work Plan:

Tasks, activities and descriptions for the entire project

Dependencies, critical path, and resources (both Successful Contractor and State staff) assigned to each task

Project deliverables

Estimated work efforts

Milestones and events

Review and approval points

2.3.1.2. Communications Plan

The Contractor shall outline the processes and means by which various aspects of project status will be communicated to DSHS stakeholders. The Communication plan will detail the purpose of



the communication, the audience, method, frequency and the person or role responsible for preparation and delivery. Requirements for Status Reporting and Executive Summary reporting are included below.

2.3.1.3. Status Reports

The Contractor’s Project Manager shall be responsible for providing written weekly status reports, in an agreed upon format, and shall participate in weekly status meetings with DSHS. The Contractor’s Project Manager in conjunction with DSHS will use the status reports to monitor project progress, issues and risks to detect potential problems or delays.

The Contractor’s Status Reports shall include, but not be limited to:

Planned progress vs actual progress for major tasks

Significant variations from the Project Work Plan with explanations of causes, effects on other areas, and strategies to achieve realignment

Tasks completed since the last report, for the current reporting period

Planned tasks that were not completed, the reasons for delay, a description of constraints on completing the tasks, and an expected completion date

Planned tasks and activities for the next scheduled reporting period

Key decisions made and who made the decision

New and existing risks that pose a threat to schedule, cost or scope of the project with a description of the affects, probability and mitigation(s)

New and existing issues that negatively impact schedule, cost or scope of the project with a description of the issue resolution and status

Any other topics and risk items that require attention

2.3.1.4. Executive Summary Report

In addition to the weekly status reports, the Contractor shall provide a monthly executive summary report that includes:

Top 5 Risks and issues, their mitigations and resolutions

Any matters requiring management attention, assistance, or escalation



The status of all work items including contract deliverables, scheduled to be completed during that reporting period, according to the project schedule. Each item scheduled to be complete must be designated either as incomplete or certified by the Contractor to be complete.

Metrics on test and production defects, as applicable, their status, length in status, and resolutions (code fix, updated requirements, and updated processes).

Final format for the Executive Summary Report will be negotiated.

2.3.1.5. Risk Management Plan

In collaboration with DSHS, the Contractor’s plan shall include identifying and assessing potential risks to the project, as well as identifying and managing the impact and probability, as well as the actions to avoid, transfer, mitigate, or manage those risks throughout the life of the project.

2.3.1.6. Issues Management Plan

The Contractor’s plan shall include identifying, characterizing, tracking and satisfactorily addressing project issues as they occur, either as transition from risk to issue, or as discovered during execution of the project. Issues must be characterized in terms of their impact to project outcomes and success, and actively tracked and managed to successful resolution or acceptance by DSHS. Issue status shall be a component of Phase Exit Criteria in determining phase completion and acceptance.

2.3.1.7. Configuration Management Plan

The Contractor shall be responsible for configuring all software to meet the requirements of the State. State personnel must be included in the configuration process to facilitate effective knowledge transfer.

To facilitate this activity, the Contractor shall be responsible for developing and maintaining a configuration management plan to ensure the integrity of change control of all project documents, software, tools, and technical environments commonly provided in a project life cycle process.

The Configuration Management Plan shall include, but is not limited to:

Methods used to manage the configuration process

Sources of information

The progression of configuration values from initial prototyping through testing to production



Configuring required third-party applications acquired by DSHS

Applying all upgrades and patches released by the software providers

Managing changes to configuration throughout the project lifecycle

Ensuring project deliverables, documents, and other documentation subject to change throughout the engineering lifecycle are updated to reflect configuration changes

Ensuring that work is not performed on out-of-scope features, functions, or tasks until DSHS grants authorization in writing

Change control and source code management plan including procedures, source code management system, automated builds and releases using industry accepted process and tools to ensure the integrity of programs process’ and configuration settings developed to support the systems (Note: While not necessarily preferred, DSHS currently uses SCLM on the mainframe and ClearCase for web applications as a source code management tools.)

Migration plan for incorporating software updates, source and configurations, to production version of code including all implemented change requests (CRs) and problem reports (PRs).

2.3.1.8. System Security Plan

The Contractor, in collaboration with DSHS, shall develop a comprehensive System Security Plan for meeting security standards and following procedures at the hardware, application, database, network and user levels in accordance with the State’s Enterprise Security Policy, OCIO security policies 141.10, DSHS Security Standards, and any Federal security policies (e.g., IRS Publication 1075, Exhibit 7) that may apply.

2.3.1.9. Change Management Plan

The Contractor shall provide change management leadership throughout all phases of the project. The change management approach shall be documented in a comprehensive Change Management Plan to be developed by both Parties in compliance with DSHS’ Change Order Process (see Attachment 03 - Contract Management Plan). The Change Management Plan must document the approach and methodology for planning and performing change management activities, including change control processes with standards and procedures for handling and



processing Change Requests (CRs) and Problem Reports (PRs) that may occur during the course of the implementation project.

2.3.1.10. Requirements Management Plan

The Contractor shall use the organizations requirement management tool called Rational DOORS Next Generation (RDNG). The Contractor shall develop a comprehensive Requirements Management Plan for managing all project requirements (functional and non-functional). This Requirements Management Plan must include:

The process and procedures that will be followed for any requirements that are added, modified or removed from scope.

Requirements Traceability Matrix (RTM) that is maintained and accessible to the project team at all times. The RTM must include complete traceability through requirements, analysis, design, development, integration, testing and implementation. RDNG does not currently support testing traceability, however RDNG can be used for all other traceability.

Additionally, the Requirements Management Plan must describe the escalation process that will be followed during go/no-go decisions for each phase of the project should there be differences of opinion in the interpretation and completion of each requirement.

The Contractor shall provide, based on their experience, what resources from DSHS will be needed to complement the Successful Contractor’s requirements development.

2.3.1.11. Project Quality Plan

In coordination with the DSHS QA vendor, the Contractor shall define the strategy and approach to be used to attain the product quality level specified in the Requirements Plan. Quality includes both satisfactory completion of the SOW and correct execution of the re-hosted system.

The Project Quality Plan ensures that the required level of quality is fully defined and that corresponding plans exist to achieve it. These plans enable efficient use and availability of development and test resources to detect and correct defects.

Contents should include:

Defect detection. This includes strategies for using inspections and testing. The testing strategy should answer such questions as: How will the system be tested? What kinds of testing will be done? What are the criteria to know if testing is passed?



Defect management. This identifies how defect tracking and defect resolution will be done, and what approach will be used for defect prevention.

Usability goals, plans to achieve them, and verification methods. This includes customer use for requirements elicitation, design, and validation.

Performance goals. This includes:

o performance criteria such as response time, utilization, and throughput

2.3.1.12. Phase Exit Criteria

The Contractor shall describe the method and criteria used to determine project readiness to transition from one phase of the project to the next. This involves characterizing the state of progress for each phase in terms of accomplishment of planned outcomes. A readiness assessment is to be conducted near the planned conclusion of each phase to determine that the Project Quality criteria are met, and that the project stakeholders approve exiting one phase and transitioning to the next phase of the project. Examples of Phase Exit Criteria include:

All planned deliverables have been completed per plan or accepted for use by DSHS

All planned tasks for the current phase have been completed

All current issues and risks are satisfactorily dispositioned, or are actively tracked and on schedule for resolution or mitigation

All known testing defects have been satisfactorily addressed

2.3.1.13. Disentanglement and Exit Plan

The Contractor shall document its disentanglement and exit planning approach including identification of transition responsibilities, descriptions and schedule for required tasks to ensure an efficient and effective transition from the Contractor with minimal disruption to operations pursuant to Sample Contract Section K – Disentanglement and Attachment 09 - Exit Plan. During execution of the approved Disentanglement and Exit Plan, the Exit Team (comprised of State staff, the Contractor, and other affected service providers) shall meet regularly to review and update the Disentanglement and Exit Plans to reflect revisions to schedules, resource requirements, dependencies, priorities and all other obligations under Sample Contract Section K – Disentanglement and Attachment 09 - Exit Plan.

Without limiting the Contractor’s obligations under its Agreement with DSHS, the Contractor will meet its obligations pursuant to



Sample Contract Section K – Disentanglement and Attachment 09 - Exit Plan including, but not limited to:

Cooperate with DSHS, its Affiliates and/or the Replacement Contractor by promptly taking all steps required to assist DSHS in completing the Disentanglement related to the Services it had previously performed.

Provide DSHS, its Affiliates and/or the Replacement Contractor with all nonproprietary information regarding the Services that these parties will need to perform the Disentanglement. This information includes, without limitation, data conversions, interface specifications and data about related professional services.

Promptly and orderly conclude all work that DSHS may direct the Contractor to do. This may include the documentation of work in progress and other measures to provide an orderly transition to DSHS, its Affiliates and/or the Replacement Contractor.

Accomplish the other specific obligations described in Sample Section K – Disentanglement and Attachment 09 - Exit Plan.

The Contractor shall maintain an updated Disentanglement and Exit Plan throughout the project with formal presentation and approval occurring at the end of the Analysis and Detailed Systems Review/Inventory Phase, at the end of the Deployment Phase, and at the end of the Close-Out/ Maintenance and Operations Phase pursuant to the Cost Proposal outline in Sample Contract Section C – Fees, Compensation, and Payment.

2.3.2. Analysis and Detailed Systems Review/Inventory Phase

The Contractor shall conduct a thorough analysis using an automated tool of the existing ACES components and applications, identify orphaned code modules and data, trace execution paths and describe the control flow and structure of our application system and assessing other potentially impacted applications, evaluating impacts and benefits associated with findings, evaluating quality and suitability of current and new data sources, and any recommendations for improvement.

The Contractor shall perform an analysis and inventory of existing ACES components and applications, including but not limited to, ACES, ACES Online, Washington Connection, Eligibility Service and Data Warehouse, utilizing an automated analysis tool.

2.3.2.1. Systems Inventory

The Contractor shall provide a detailed Systems Inventory of all systems required to be migrated as well as third party services used by the applications that must be tested on the new platform.



This inventory will include all application components inclusive of programs, Job Control Language (JCL), documents, reports, and third party interfaces to be migrated including middleware connectivity components to the existing document management system.

The Contractor shall provide installation and configuration for all products identified in the systems inventory that are to be installed or migrated during the Re-hosting Phase.

2.3.2.2. Interfaces Replication Plan

The Contractor shall be responsible for validating current interfaces to all mainframe applications in the scope of the project. The Successful Contractor shall replicate all existing interface functionality. The systems in scope of this RFP support 34 interface partners with the following interfaces (includes internal):

89 batch

36 web

10 CICS

20 MQ (are part of the CICS and batch interfaces)

DSHS Business analysts are subject matter experts for these interfaces and will provide the support necessary to assist the selected Contractor in addition to coordinating any communication with external partners.

2.3.2.3. Technical Environment Assessment Report

The Contractor shall recommend a hardware sizing and architecture based on the ACES applications to be migrated and to accommodate anticipated future growth. In this report, the Successful Contractor shall:

Provide a list of required software, hardware and support for each option

Perform capacity planning with an overall assessment of the sizing of production infrastructure hardware, systems software, and data storage to support the various environments

Identify a standard technical infrastructure configuration for the various environments

Recommend the software installation to support the Successful Contractor’s environments for design, configuration, and testing using the certified software installed

Provide complete hardware sizing and architecture to address environments for release updates, training, development, testing, and production with the test and production



environments being equivalent or practically equivalent for testing purposes

Document how the proposed technical architecture design fits within the current network security architecture, composed of unique logical areas separating development/test environments from production environments

As part of the Technical Environment Assessment Report the Contractor shall describe the needed:

Hardware for configuration, design, and development

Hardware for testing in a production equivalent environment

Structure and maintenance of planned database instances/environments

Tools necessary for managing and monitoring the hardware/software environments

Methodology and potential toolset for encryption of data at rest and in transit

Methodology and potential toolset for log management

Disaster recovery recommendations

Backup and recovery, and business continuity plan (including hardware and software components)

Set-up and administration of environments that support iterative, adhoc and waterfall development approaches. Must be able to support multiple code promotion paths, e.g., feature development, hot-fix development, platform software updates:

o Development and unit testing environment

o Integration testing environment, also the environment where static code analysis and secure code analysis will be conducted

o System test environment used by DSHS Testers for both manual and automated testing

o User Acceptance Test environment or pre-production (This environment must be a functional approximation of the production environment.)

o User Acceptance environment exclusively for coordinated testing of MAGI, Eligibility Service and the Healthplanfinder

o Training environment

o Production environment

2.3.2.4. Assessment Presentation



Upon completion of the Initiation and Analysis and Detailed Systems Review/Inventory Phases, the Contractor shall present a summary of their findings including identification and assessment of potential risks and issues of the project and recommended actions to avoid, transfer, mitigate, or manage those risks and issues throughout the life of the project.

2.3.3. Platform Specification and Design Phase

This phase will detail the design of the platform and infrastructure components of the Contractor solution. The design will include detailed models of the proposed solution that captures the system structure from end-to-end and top-to-bottom. Including all of the various pieces of the system and how they relate to one another.

The Contractor shall obtain written acceptance of all Initiation Phase and Analysis and Detailed Systems Review/Inventory Phase Deliverables, written agreement on the chosen architecture platform, and confirmation that DSHS is ready to proceed with the Specification and Design Phase before proceeding with any of the deliverables and activities listed below.

During the design phase, the Contractor shall work closely with DSHS’ Project Team and review design specifications in order to meet all of DSHS’ requirements. These design specifications shall encompass all components of work to be performed and include hardware, hardware configuration, software, software configuration, customizations, interfaces, data warehouse design, queries and reports, workflow, security, and data conversion as stipulated below.

2.3.3.1. Security Design Document

The Contractor shall complete a security design that includes definition of application security roles, profiles and permissions. In addition the document will include how the state security standards are being met in the proposed design.

2.3.3.2. Identity Management Document

The Contractor shall document its plan for integrating its solution with the current identity management methodology. The Contractor shall outline for each layer (network, servers, applications, etc.) of access what software, methodologies, and procedures will be used to provide identity management.

2.3.3.3. Interfaces Design Document

The Contractor shall design, document and deploy a set of standard inbound and outbound interfaces for processing transactions that will be replaced by the new system. There shall be minimal changes made to existing external interfaces to/from the legacy systems without impacting our interface partners. The Successful Contractor shall be responsible for documenting



existing and potential interfaces required between the system and other agency-specific legacy administrative systems that will remain in production use as well as interfaces to other external entity systems. The Successful Contractor shall also describe the necessary integration points for third-party software with the system.

The documentation shall detail the functional behavior of each interface, including parameters used, parameter sources, expected results, error conditions, error handling and messages.

2.3.3.4. Data Conversion/Migration Design Document

The Successful Contractor shall produce a comprehensive data conversion design that details all aspects of creating the conversion routines and database environments necessary to deploy the fully functional system into the production environment. The Successful Contractor shall clearly identify any data tasks for which DSHS is responsible. The Successful Contractor’s Data Conversion/Migration Design Document shall include, but not be limited to:

Detailed processes and procedures for all migration activities

All data to be converted, migrated, loaded, or entered in the new system

Data sources

Expected data volumes

Anticipated end-customer outage impacts and tolerances

Conversions where automated programming can be used to significantly reduce data conversion labor

Roles, responsibilities and timing requirements for the conversion effort

Extract, transformation and load methods and procedures to be used

Detailed specifications required to develop the data conversion programs for converting data from the legacy system to the new system

Any required data conversion procedures for entering manually converted data into the new system

Data cleansing edits and quality assurance validation steps that need to be performed before and/or during the conversion process

2.3.4. Platform and Application Migration Phase



During the platform and application migration, the Successful Contractor shall be responsible for configuring, customizing and enhancing all application software as needed in accordance with approved design specifications.

During this phase of work, the Successful Contractor shall be responsible for the unit, integration, regression and performance testing of all application software, acceptance test planning, and disaster recovery planning and provide the following deliverables and associated services.

2.3.4.1. Test Plan

The Contractor shall develop a comprehensive Test Plan deliverable inclusive of test scripts/use cases, test traceability plan, and data for each activity of testing. All proposed test plans shall be reviewed and approved by DSHS prior to the initiation of that testing activity. This plan should include online, web and batch testing. Batch testing include daily, weekly, monthly, month begin, month end, quarterly, yearly and any other special processes identified during the assessment phase.

The Successful Contractor may use existing DSHS test plans / cases, however, they are only related to the change requests and problem reports implemented from ACES releases and are written in a format understandable by an end user with significant business knowledge.

Automated test scripts are not in use at this time at DSHS.

Test data is available, however it doesn’t represent all the production scenarios. Under certain circumstances the Vendor may be allowed to create test data from production data if no HIPAA, federal or state policies are violated.

DSHS data is not allowed on non-DSHS servers or vendor test environments/test labs/data centers.

The Successful Contractor’s Test Plan shall include testing for, but not be limited to:

Systems/Integration

Data Conversion

User Acceptance

Performance (load/stress)

Security (Automated scanning of web pages for vulnerabilites)

Regression/Parallel Testing

Interfaces

Batch Processing



Reporting

The Successful Contractor shall be responsible for the testing and activities to be undertaken, and the tools and techniques to be used. The Successful Contractor shall document all required environments, platforms, and procedures necessary for establishing the testing environment for all activities of testing including deadlines and identifying associated responsibilities of DSHS. DSHS tests all functional code in mainframe environments that are not production level. The Test Plan shall include training to DSHS on the testing tools used to facilitate the testing process.

The Successful Contractor shall be responsible for all aspects of verifying and documenting interfaces, real-time and batch.

Primary responsibility for UAT shall be with DSHS. The Independent Verification and Validation (IV&V) vendor will also be responsible for conducting independent acceptance testing. Both of these will be conducted with the assistance of the Contractor.

All the other testing will be completed by the Contractor, with assistance from DSHS. To assist in testing, the Contractor shall provide, in detail, the DSHS resource needs required.

This project is funded with CMS enhanced Federal Funding Participation (FFP) which requires IV&V. The Project’s current IV&V vendor Public Consulting Group (PCG) will review deliverables, work products, schedule, processes, and monitor overall project progress. PCG will report status, risks and issues directly to CMS on a regular basis. PCG will also perform independent testing as applicable of any code changes made by the vendor. Regular communication between the re-hosting vendor and the IV&V vendor will be expected for coordinating vendor reviews as mentioned above. The re-hosting vendor should make a point of including the IV&V vendor in applicable project meetings (e.g., status, schedule, risk and issue), walkthroughs, and any deliverable acceptance type of meetings.

2.3.4.2. Knowledge Transfer and Training Plan

The Contractor shall develop a comprehensive Knowledge Transfer Plan that delineates knowledge transfer goals and objectives for State and contracted personnel at all levels. The knowledge transfer plan shall be based on a comprehensive needs and competencies assessment conducted by the Contractor and shall describe the types of training to be provided to meet the identified needs.

The Contractor shall plan and execute a comprehensive training program for DSHS encompassing a diverse array of training options during this phase of work. While formal training will form part of the overall mix of training services required to train State



and contracted personnel, a more complete knowledge transfer approach that supplements training with carefully selected hands-on experience during the Deployment is also required. The Contractor shall provide a knowledge transfer approach that will ensure DSHS and contracted resources have a “critical mass” of knowledgeable personnel (user experts such as business analysts and customer support staff, system administrators, programmers and other technical personnel) sufficient to operate and maintain the system independently of the Contractor. A key requirement for success in this area will be the acquisition of skills via DSHS’ participation in producing key functional and technical deliverables, including software modifications and configuration changes, under the supervision and instruction of experienced Contractor personnel.

The Contractor shall ensure that, as a part of the knowledge transfer strategy, an effective mentoring program is developed for key DSHS personnel. The Contractor’s knowledge transfer strategy shall actively involve the mentoring of DSHS personnel throughout the project life cycle to ensure that DSHS’ personnel are prepared to operate and maintain the system at go-live.

Specifically, it is expected that Contractor staffing skill and expertise will be used to ensure proper configuration and setup of the Contractor solution and associated hardware and software but ESA ITS staff will be the ones who actually perform the work. Contractor staff must be on-site and working side-by-side with ESA ITS staff as the solution is implemented.

DSHS anticipates the need to train and provide knowledge transfer to 30 to 40 user experts from different teams.

2.3.4.3. Disaster Recovery Plan

The Successful Contractor shall develop and document Disaster Recovery Plan options, including estimated costs, for the production environment that meet the recovery time objectives defined by the Administration

2.3.4.4. Configuration Management Document

The Successful Contractor shall configure and document the software configurations, as described in the Configuration Management Plan, by performing all activities necessary to meet DSHS’ requirements and documenting post-implementation configuration.

2.3.4.5. Security Configuration Document

The Successful Contractor shall be responsible for configuring, documenting, and maintaining the application security roles,



profiles, and permissions. The Successful Contractor shall document all post-implementation security configuration.

2.3.4.6. Interfaces Document

The Successful Contractor shall complete all work outlined in the Interfaces Design Document and document all post-implementation interfaces.

The Successful Contractor shall migrate all on-line and batch interfaces to the new platform and document all post-implementation on-line and batch interfaces and related processes.

2.3.4.7. Data Conversion

Based on DSHS’ approved Data Conversion Plan, the Successful Contractor shall create, test, and document automated conversion programs to support the commencement of live operations. The Successful Contractor shall provide quality assurance during the conversion and archiving processes to ensure data quality and preserve performance optimization.

The Successful Contractor shall run the conversion programs and assisting DSHS with the verification of the converted data in the required environments including the enterprise Data Warehouse (eDW). DSHS shall assist with loading data that is not converted or loaded automatically and for certifying the production database as being accurate. The Successful Contractor shall adapt and re-run conversion programs as necessary to properly convert and load the data and to maintain a conversion log to track the accuracy of all conversion efforts.

Data conversion activities shall be determined by using the approach that is provided by the Successful Contractor as approved by DSHS.

DSHS shall be responsible for performing all manual conversion processes, with the guidance of the Successful Contractor. Manual conversions will be utilized when the Successful Contractor and State agree that the volume is too low to justify the cost of developing an automated conversion program.

2.3.4.8. Readiness Assessment Report

The Successful Contractor shall track activities, issues, and status to ensure that User Acceptance Testing can begin. This readiness assessment shall include, but not be limited to, staff readiness, the migration and control of all software components, completion of prerequisite training, completion of test scripts and data validation, documentation of roles and responsibilities, validation of the appropriate version of the applications, and identification of acceptance testing criteria.



DSHS shall be a primary participant in the acceptance testing process with assistance from IV&V and the Successful Contractor. Prior to State approval of the software for production use, both user and system acceptance tests shall be successfully completed. State representatives shall function as system users during system testing and shall evaluate all test outcomes.

2.3.5. Deployment Phase

DSHS requires an extensive and carefully structured approach to the deployment (“go-live”) of the ACES complex applications. This includes the planning, organization and execution of cutover activities necessary to transition operations to the new platform.

Testing is a critical component of the Deployment activities. All required testing shall be conducted in accordance with DSHS’ accepted and IV&V approved unit, integration, regression and performance test plans developed by the Successful Contractor. The Successful Contractor shall document all test results, analyze exceptions and correct any software defects. All system components will be subjected to testing performed by a Test Team composed of both the Successful Contractor and DSHS staff.

The Successful Contractor shall provide on-site support throughout the entire Deployment period.

2.3.5.1. Deployment Plan

The Successful Contractor shall document and update the Deployment Plan to reflect all project tasks, activities, roles, responsibilities, dependencies, and milestone events for completing the testing and deployment process that enables DSHS to begin effective use and maintenance of the applications.

The Deployment Plan must include, but not be limited to:

Technical preparation and system changeover activities

Development of a migration activities check list, including updating of the code conversion for all changes made since the most recent release

Staffing requirements, by role and responsibilities, for both the Successful Contractor and DSHS personnel for all migration activities

Migration schedule

Activities required to effectively operate and maintain the applications and all hardware and software

Assumptions for any code freeze and the expected duration and timing of the freeze



A critical component of the Deployment Plan is the inclusion of a Contingency Plan component for mitigating and resolving risks that are identified as potentially impacting deployment. The Contingency Plan component will address the strategies for business and system continuity planning as a result of migration issues. For each risk identified, the Contingency Plan shall include one or more alternate solutions that are acceptable to DSHS. The Successful Contractor shall be responsible for executing the Contingency Plan as issues arise during migration, upon approval of DSHS.

2.3.5.2. Implementation Support Plan

The Successful Contractor shall develop and document an Implementation Support Plan describing plans, processes, forums, activities, and procedures for providing user support from the outset of the deployment activities through the end of the post-implementation period.

2.3.5.3. Technical Documentation

The Successful Contractor shall provide comprehensive technical documentation that describes, but is not limited to, the application software, middleware, any third-party application software and its architecture (e.g., implementation view of the application architecture). This documentation will include but not be limited to a guide to all software source code, programs, and executables, as well as a comprehensive physical/functional data model. Where customizations have been made, the technical documentation must include, but not be limited to, a detailed data dictionary, entity-relationship diagrams, and a tool for keeping the data dictionary current. The Successful Contractor shall maintain this documentation to reflect changes made throughout the project.

Technical documentation shall also include, but not be limited to all customization/configuration parameters used at DSHS as well as the full range of alternative values possible (and the effect of each value). The documentation shall reference all parameters and note and explain where dependencies occur and where environmental conditions dictate specific usage and settings.

2.3.5.4. Operations Documentation

The Successful Contractor, in collaboration with DSHS’ Production Control Team, shall provide operations documentation that includes, but is not limited to, overviews of the application, system structure, major processing, required interfaces, performance monitoring, processes to support as-needed load and stress testing, report documentation, maintenance tasks, correspondence documentation and Process and Procedures



Manual. The operations documentation shall also describe the overall batch or background process schedule, including dependencies, sequencing, and timing. If there are any workstation-based components to any of the proposed software products and solutions, the Successful Contractor shall provide the State with a set of documented procedures and automated deployment/installation scripts for use with DSHS’ software distribution tools. These scripts and procedures will enable DSHS staff to independently install and connect additional workstations.

2.3.5.5. Knowledge Transfer, Training Schedule, Curriculum and Materials

The Successful Contractor shall develop, disseminate, and maintain on-going training schedules, curriculum, and materials post-implementation for State employees and contracted resources.

2.3.5.6. Data Conversion Report

The Successful Contractor shall document that all data conversion activities have been successfully completed and all migrated data conforms to the original source data. The report should also identify any conversion activities that were not completed, or any anomalies that were discovered, and recommendations for resolution.

2.3.5.7. Knowledge Transfer and Training Report

The Successful Contractor shall document the verification of successful knowledge transfer and training outcomes.

2.3.5.8. User and System Acceptance Test Report

The Successful Contractor shall describe the results of the User and System Acceptance Testing activity to validate that all deficiencies have been corrected and the testing is successful.

2.3.5.9. System Performance and Tuning Report

The Successful Contractor shall document all system performance changes made to the system by all means, including but not limited to tuning databases, application servers, web servers, and other software and devices deployed as part of the solution. The Successful Contractor shall validate that the migrated application maintains or improves upon pre-migration transaction response times. Current system performance metrics are available in the Section 16 of ACES Technical Information document.

2.3.5.10. Production Deployment Readiness Certification

The Successful Contractor shall provide a Certification letter to confirm:



All applicable DSHS personnel have completed training

All data has been converted, cleaned and accepted by DSHS

All site preparation requirements have been met

All user support is established

All user and system supports are in place

Once DSHS has provided written approval for the system’s production deployment readiness, the Successful Contractor shall work with DSHS to establish a production cutover procedure.

2.3.5.11. Production Cut-Over Procedure

This procedure requires that the Successful Contractor move all system components in a systematic fashion into the production environment. The Successful Contractor shall ensure that the source code, compiled modules (where required), job streams, other components of the production environment, and all documentation are ready and organized for the production cutover. The Successful Contractor shall ensure that all compiled extension programs have corresponding source code and ensure that all programs are present.

DSHS shall ensure that all components and modules of the production environment can be operated on-line to completion as appropriate, and that all modules, job streams (or scripts) are documented in detail according to the agreed upon standards.

2.3.5.12. Continuing Modernization Recommendations

Upon successful completion of the Re-hosting Phase, the Successful Contractor shall provide recommendations for the continued modernization of the legacy system.

2.3.5.13. Continuing Modernization Recommendations Report

The Successful Contractor shall perform an assessment of the risks and issues related to the legacy system and document recommendations for modernization covering, but not limited to, the following areas:

Database modeling and redesign

Infrastructure/systems reengineering

Utilization of a modern rules engine

Security monitoring/compliance/enhancements

Batch processing

Resources, skills and experience – current and future needs

2.3.6. Close-Out Phase



The Successful Contractor shall provide on-site post-implementation support for a period of six (6) months following Steady State with one (1), (2) two-year optional extension. In its Post-Implementation Maintenance and Support Plan, the Successful Contractor shall specify the number of full time equivalent (FTEs) Successful Contractor staff that will need to be dedicated to the maintenance and support activities. The on-site presence is needed to maintain a stable production environment and to provide for a smooth turnover of system responsibility to DSHS. The post-implementation support shall consist of technical, end-user, and operational support. Post-implementation support shall be provided by Successful Contractor Personnel who have the requisite qualifications to provide the necessary support and have experience with the project throughout the course of the implementation effort. DSHS personnel shall assist during this period in providing ongoing user support to address operational problems and answer questions (e.g., system access, security profiles, program bugs, instruction in the use of the system).

2.3.6.1. Post-Implementation Maintenance and Support Plan

The Successful Contractor shall provide a plan that documents the process, procedures, and governance organization to identify, evaluate, prioritize, and document recommended system defect fixes, software maintenance patches, minor enhancements, and table changes.

The post-implementation support includes testing to the extent necessary to resolve incidents/problems related to the re-hosting environment. Testing is also required for any changes/upgrades/fixes/patches prior to deployment to the re-hosted environment.

The Post-Implementation Maintenance and Support Plan shall include, but not be limited to:

Providing user support during the post-implementation maintenance and support period

Staffing and organization

Problem report tracking software

Staff training requirements

User support incident tracking procedures and tools

Evaluation of, response to, and escalation of reported incidents

Assumption of partial user support responsibility by DSHS personnel by the end of the post-implementation maintenance and support period

2.3.6.2. Process and Procedures Manual



The Successful Contractor shall develop and continuously update a detailed, DSHS-specific Process and Procedures Manual. The Process and Procedures Manual shall include, but not be limited to, operations manuals, user guides, quick reference, specifications, and end-user support information that provide the details of such activities so that a similarly skilled resource can repeatedly and reliably produce the same result. The Process and Procedures Manual shall also describe the activities necessary to comply with all applicable laws and regulations including, without limitation, those relating to the privacy and security of DSHS Data, including Sarbanes-Oxley Act (SOX), Health Insurance Portability and Accountability Act (HIPAA), Gramm-Leach-Bliley Act (GLB) and any other laws and regulations applicable to DSHS Data and/or identified by DSHS. The Process and Procedures Manual shall describe how the Services will be performed and act as a guide to End-Users seeking assistance with respect to the Services offered hereunder. The Process and Procedures Manual shall in no event be interpreted as relieving the Successful Contractor of any of its performance obligations under the Services to be performed.

The Successful Contractor shall deliver the first draft of the Process and Procedures Manual to DSHS for its review, comments and approval within the time frame set forth in the Exit Plan and shall, with respect to each draft of the Process and Procedures Manual, incorporate all of DSHS’ comments and suggestions. Not later than thirty (30) calendar days following completion of all activities under the Exit Plan, the Successful Contractor shall deliver an updated draft of the Process and Procedures Manual to DSHS for its review, comments and approval and thereafter shall periodically update the Process and Procedures Manual to reflect changes in the operations or procedures described therein. All such updates to the Process and Procedures Manual shall be provided to DSHS for its prior review, comments and approval.

2.3.6.3. Exit Plan Progress Report

The Exit Team shall summarize the progress on the Exit Plan to date. The Successful Contractor shall be required to work cooperatively and expeditiously to transfer the existing responsibilities to DSHS or another service provider. The Exit Plan Progress Report shall document the conditions existing at the date of formal hand-off between Successful Contractor and DSHS personnel, including any identified issues that may require contingent follow-up by the Successful Contractor.

2.3.6.4. Project Lessons Learned and Final Report



The Successful Contractor shall identify and document lessons learned from the project to assist DSHS in continuing to support the implemented system, and to undertake similar projects in the future.

2.4. Non-Formalized Services Inclusion

The Provider understands and accepts that all activities that affect the Service Environment as defined in Section 3 including its subsections and referred Appendices, will be in scope of the Services and the responsibility of the Provider, except when explicitly assigned to DSHS or another third party in this SOW or another SOW under this Agreement, or defined as being out of scope of this SOW as set out in Section 2.3 above.

Where such activities are not formalized in this SOW, the Provider will perform these activities as if they were included in this SOW and initiate the required actions to update this SOW in accordance with Attachment 03 - Contract Management.

2.5. Retained Responsibilities

The establishment of DSHS's application strategy, architecture, policies, procedures and standards will be retained responsibilities by DSHS in accordance with Section H, Retained Authorities to this Agreement, and they are outside the scope of this SOW. These retained responsibilities include:

Application strategy design

Application risk management

Application security requirements management

Business process design

Business functional demand analysis

Application functional architecture

Application technical architecture validation and verification

User acceptance testing execution

Application Level 0 — super user support

Services performance management

DSHS will ensure that all retained responsibilities will be fulfilled by certified DSHS or Subcontractor personnel.



2.6. Outsourced Responsibilities

The execution of DSHS's application strategy, architecture, policies, procedures and standards will be outsourced to and controlled by the Provider, and they are inside the scope of this SOW. The outsourced responsibilities include, but are not limited to:

Application strategy execution

Application technical architecture

Application development planning

Application development programming/coding/configuring

Application testing planning, design, execution

Application implementation

Application development implementation

Application data/code migration

Application training

Application documentation maintenance

Application corrective maintenance

Application adaptive maintenance

Application perfective maintenance

Application preventive maintenance

Application level 1, level 2, and level 3 support

The Provider will ensure that all outsourced responsibilities will be fulfilled by certified Provider or Subcontractor personnel in accordance with Section B, Personnel, Section F, Use of Subcontractors and Attachment 05 - Personnel to this Agreement.

The Provider will ensure that all outsourced responsibilities are fulfilled according to industry best practices, which include but are not limited to CMMi-SVC at level 3 minimum, ITIL v3, ISO20000, Prince2 or Project Management Body of Knowledge (PMBOK).

The Provider will ensure that all outsourced functions are governed by an industry best practice control framework, which can be Control Objectives for IT (COBIT) or Committee of Sponsoring Organizations of the Treadway Commission (COSO).

If the Provider applies different standards than the listed standards, the Provider will ensure and provide proof — which DSHS can accept or reject at its sole discretion — of such standards. In case DSHS rejects the proof, it will do so within 5 (five) business days with the reasons for



rejection and required improvements. The Provider will have 10 (ten) business days to provide a plan of how to comply and 90 (ninety) business days to implement the plan to comply with the required improvements from the date of notification.

DSHS is entitled to audit the Provider on the previous in accordance with Section E, Record-Keeping Audit Rights and Attachment 02 - Measurement Charter to this Agreement.



3. Service Environment

The Service Environment data and Appendices are to be maintained by the Provider and made available to DSHS on a quarterly basis.

The Provider will maintain all Service Environment data in the Configuration Management Database (CMDB) in line with the process as described in Attachment 04 - Demand Management Plan.

3.1. Applications and Licenses 3.1.1. Application Name (as registered in the CMDB or License Agreement)

3.1.2. Version (list different versions as separate applications)

3.1.3. Version Date

3.1.4. Business Processes Supported (identifying the business process or processes that are supported by this application. Organizations should include direct supported processes only, not processes that are supported through linked applications)

3.1.5. Business Process Performance Measures (when known, fill in the measures that identify proper performance of the process, which can be used as a reference in the service level requirements section)

3.1.6. Inbound Interfaces (referring to interfaces that write to the application or external data that is read by the application through a function call. When the application is an interface, this would be empty)

3.1.7. Outbound Interfaces (referring to interfaces that originate from the application, whereby it either writes data to an external file or directly to another application. When the application is an interface, this would be empty)

3.1.8. Application Services and License Agreement Reference (for licensed applications this should be the unique reference to the agreement that governs the use of the application)

3.1.9. License Keys for the application plus version (it can also be a separate list and maintained separately and should then refer to the license agreement)

3.1.10. Related Databases (if any)

3.1.11. Related Database Versions (database details are to be listed as part of the Datacenter SOW where the Database Administration services are defined; here only the databases need to be uniquely related to the applications)

3.1.12. Application Platform (if the application is an implementation based on a commercial off the shelf [COTS] software package [e.g., SAP, Oracle], name it here)



3.1.13. Application Framework (frameworks are reusable software components that provide bundled functionality upon which applications can be built. These can be provided by independent software vendors [ISVs] or created and owned by the organization as platforms on which applications are built. When DSHS-owned frameworks are included in the services — to update and maintain — these should also be listed separately)

3.1.14. Functional Application Owner (normally a business process owner or business unit manager)

3.1.15. Technical Application Owner (normally a retained IT function).

Applications and Licenses

3.1.16. The Provider will apply the Services as defined in this SOW to the applications as listed in Appendix [AS.1] Applications and Licenses to this SOW.

3.1.17. For the sake of simplicity, interfaces in all forms will be defined as "applications" and included in Appendix [AS.1] Applications and Licenses to this SOW.

3.1.18. The ownership and usage of application frameworks is governed by Section I, Proprietary Rights to this Agreement.

3.1.19. The Provider will maintain the licenses for the listed applications where applicable. This will be under the condition that these licenses are for the sole use of DSHS and legally allowed.

3.1.20. The Provider will ensure reports of licenses used per application in accordance with Attachment 04 - Demand Management Plan, but at minimum every month on the 5th (fifth) working day in regard to the usage of the previous month and expected usage of the current month.

3.1.21. In case of expected license shortages within the next reporting period for listed applications, initiate relevant actions according to the respective Application Services and License Agreement.

3.1.22. Production licenses for the applications as listed in Appendix [AS.1] Applications and Licenses to this SOW will remain in ownership of DSHS.

3.1.23. When DSHS requests and where legally allowed, the Provider will take over the License Agreement including underlying or attached License Maintenance Agreement from DSHS for non-production licenses for named applications included in the application list in Appendix [AS.1] Applications and Licenses to this SOW.

3.1.24. When DSHS requests and where legally allowed, DSHS will take over the License Agreement including underlying or attached License Maintenance Agreement for software deployed by the Provider to support the provisioning of the Services.



3.1.25. Alterations in any form — add, change, delete — of the applications as listed in Appendix [AS.1] Applications and Licenses to this SOW will be executed in accordance with the Demand Request procedure as described in Attachment 04 - Demand Management Plan.

3.1.26. When alterations affect any of the Application Characteristics as listed in Appendix [AS.1] Applications and Licenses to this SOW, the Provider will initiate the relevant actions to update Appendix [AS.1] Applications and Licenses to this SOW in accordance with Attachment 03 - Contract Management to this Agreement.

3.1.27. When an Organization wishes the Provider to use and maintain its IT Operations Management software (e.g., HP OpenView, BMC Patrol or IBM Tivoli Enterprise Manager), this software should be listed as well. The list should only include software where DSHS is license owner.

3.1.28. The Provider will deploy and maintain the IT Operations Management software as listed in Appendix [AS.1] Applications and Licenses to this SOW to support the Services as defined in this SOW.

3.2. Applications Technical Architecture 3.2.1. The Provider understands and accepts that the applications as listed in

Appendix [AS.1] Applications and Licenses to this SOW are represented by the logical and technical application architecture representations as provided in Appendix [AS.1 sub A] Application Architecture to this SOW.

3.2.2. The Provider will maintain the application architecture representations.

3.2.3. Alterations in any form — add, change, delete — of the application architecture characteristics as listed in Appendix [AS.1 sub A] Application Architecture to this SOW will be executed in accordance with the Demand Request procedure as described in Attachment 04 - Demand Management Plan.

3.2.4. When alterations affect any of the application characteristics as listed in Appendix [AS.1] Applications and Licenses to this SOW, the Provider will initiate the relevant actions to update Appendix [AS.1] Applications and Licenses to this SOW in accordance with Attachment 03 - Contract Management to this Agreement.

3.3. Applications Workload 3.3.1. The Provider understands and accepts that the development and

maintenance workload for the applications as listed in Appendix [AS.1] Applications and Licenses to this SOW are provided in Appendix [AS.1 sub B] Application Workload to this SOW. The workload will be represented by the total amount of work hours required to perform the Application Development Services as defined in Section 4.1 in this SOW and the Application Maintenance Services as defined in Section 4.3 in this SOW. Workload will be split between the Provider, DSHS and Third-Party effort.



3.3.2. The Provider will maintain the development and maintenance workload and ensure the actual development and maintenance workload is represented in Appendix [AS.1 sub B] Application Workload to this SOW.

3.3.3. Alterations in any form — add, change, delete — of the application workload characteristics as listed in Appendix [AS.1 sub B] Application Workload to this SOW will be executed in accordance with the Demand Request procedure as described in Attachment 04 - Demand Management Plan.

3.3.4. The Provider will report on the actual workload as part of the monthly reports.

3.3.5. When alterations affect any of the application characteristics as listed in Appendix [AS.1] Applications and Licenses to this SOW, the Provider will initiate the relevant actions to update Appendix [AS.1] Applications and Licenses to this SOW in accordance with Attachment 03 - Contract Management to this Agreement.

3.4. Service Delivery Facilities — Generic 3.4.1. Facilities are defined as the combined Provider or DSHS assets that are

required to perform the Services as defined in this SOW.

3.4.2. Where DSHS assets are required to perform the Services as defined in the SOW, the Provider will perform all required activities to ensure DSHS assets are included in the service delivery by the Provider to ensure the Services as defined in this SOW are delivered against the defined Service Levels.

3.4.3. Facilities can either be physical or virtual and will be physically or logically separated, secured and protected from access by any and all individuals not directly working on the Services to DSHS, inclusive of other customers, other partners of the Provider or subsidiaries or subcontractors of the Provider.

3.4.4. Facilities will include but are not limited to hardware and software operating and application platform infrastructure, application development tools, testing tools, change and configuration management tools, project management and reporting tools, and other hardware and software required to establish and support the Services as defined in this SOW.

3.4.5. The Provider will ensure contingency of service provisioning in accordance with the Service Levels as defined in Appendix [AS.X] Application Services Service Levels to this SOW.

3.5. Service Delivery Compliance 3.5.1. The Provider understands and accepts that the delivery of the Services

as defined in this SOW will need to adhere to legal and regulatory guidelines and principles that apply to DSHS and the derivative DSHS guidelines and principles to implement these legal and regulatory guidelines.



3.5.2. The Provider therefore understands and ensures that the delivery of the Services including all facilities must comply with at minimum Section L, Security and Safety, Section N, DSHS Security Requirements, Section O, Federal Tax Information Security Requirements, Legal Compliance and Section D, Insurance to this Agreement and the leading principles as defined in Attachment 04 - Demand Management Plan to this Agreement.

3.5.3. The Provider, in addition, will comply with DSHS Security Requirements as defined in Appendix [AS.3] Facility Security Requirements to this SOW, DSHS-specific application services policies and procedures as defined in Appendix [AS.4] Application Services Policies Procedures to this SOW, and DSHS policies that govern regulatory compliancy as defined in Appendix [AS.5] Regulatory Compliance Requirements to this SOW.



4. Application Services

Application Services comprise core services and supporting services. The core application services are: Application Development Services; Application Warranty Services; and Application Maintenance Services. In addition, it comprises supporting services: Release Packaging; Technical and End-User Support; and Monitoring, Reporting and Review Services. The main and supporting services are addressed in the following sections.

4.1. Application Development Services

The following sections describe the specific activities that are to be executed as part of the Application Development Services by the Provider.

The Provider understands and accepts the assigned responsibilities for the Application Development Services activities that are grouped according to the following Application Development Services components:

Application Strategy, Architecture and Planning

Planning and Analysis

Requirements Definition

Design Specifications

Programming/Development

Integration and Testing

Implementation and Migration

Code Migration

Software Configuration Management

Application Change Tracking

Training and Knowledge Transfer

Documentation

The Provider understands and accepts that the following services can be combined with any of the above Application Development services:

Release Packaging

Technical and End-User Support

Monitoring, Reporting and Review

4.1.1. Application Strategy

4.1.1.1. DSHS will produce and maintain and the Provider will implement the Application Strategy for as far as it relates to the applications



as listed in Appendix [AS.1] Applications and Licenses to this SOW.

4.1.1.2. Alterations in any form — add, change, delete — of the application strategy as listed in Appendix [AS.1 sub A] Application Architecture to this SOW will be executed in accordance with the Demand Request procedure as described in Attachment 04 - Demand Management Plan.

4.1.1.3. When alterations affect any of the application characteristics as listed in Appendix [AS.1] Applications and Licenses to this SOW, the Provider will initiate the relevant actions to update Appendix [AS.1] Applications and Licenses to this SOW in accordance with Attachment 03 - Contract Management to this Agreement.

4.1.2. Planning and Analysis

4.1.2.1. The Provider will present and initiate and DSHS will decide on and prioritize improvement initiatives. Such initiatives will at minimum comprise Preventive and Perfective Maintenance as defined in Section 4.3 in this SOW to maximize success of new developed or programmed solutions for the applications as listed in Appendix [AS.1] Applications and Licenses to this SOW.

4.1.2.2. The Provider will create and DSHS will approve the required development plan documentation as set out in the Demand Request that initiated the Application Development Services, in accordance with Attachment 04 - Demand Management Plan.

4.1.2.3. The Provider will define a specific test plan and process for each Demand Request that requires Application Development Services. This plan will include the definition of a specific test model, specific test techniques, specific test data and data management, specific test types, and test result verification and validation activities to perform to ensure the Demand Request has been realized in accordance with its objectives in accordance with Attachment 04 - Demand Management Plan.

4.1.3. Requirements Definition

4.1.3.1. DSHS will produce and the Provider will ensure that requirements are part of a Demand Request and will relate to the respective Demand Request objectives in accordance with the Demand Request templates as defined in Attachment 04 - Demand Management Plan.

4.1.3.2. Requirements will be defined in SMART way: that is, they are specific (unambiguous), measurable (by the Provider and or DSHS and or assigned third-party auditors), agreed (between DSHS and the Provider through the respective functional and technical application owners of DSHS and the assigned



application development owner at the Provider side), realistic (as indicated by the Provider and agreed by DSHS) and time bound (to be realized within a defined time frame to enable the accomplishment of the objectives of the respective Demand Request).

4.1.3.3. The Provider will document requirements as required in Rational Doors and ensure such documents refer to the specific Demand Request they represent.

4.1.4. Design Specifications

4.1.4.1. The Provider will create and DSHS will verify and validate design specifications that represent the solution to implement the defined requirements and realize the set Demand Request objectives.

4.1.4.2. The Provider will ensure its application design process and specifications:

Incorporate DSHS's architectural guidelines as defined in Appendix [AS.9] Application Architecture Guidelines to this SOW, into the design, including application extensibility, maintainability, scalability, robustness and reliability.

Obtain DSHS's approval for each functional and technical design through coordination with the appropriate respective functional technical application owner as listed for the involved applications in Appendix [AS.1] Applications and Licenses to this SOW.

4.1.5. Programming

4.1.5.1. The Provider will perform the required programming activities that are defined by the design specifications.

4.1.5.2. The Provider will maximize the reusability of (blocks of) code and report to DSHS per Demand Request the percentage of reusable code deployed and created. The Provider will ensure this percentage increases on a quarterly basis.

4.1.5.3. The Provider will ensure all programming effort is documented per Demand Request to minimize the maintenance effort of the implemented request and report to DSHS per Demand Request the percentage effort involved to describe the functionality programmed. The Provider will ensure this percentage decreases on a quarterly basis without any negative impact to the maintenance effort of the implemented request.

4.1.6. Integration and Testing

4.1.6.1. The Provider will execute the specific test plan it defined for the respective Demand Request or Demand Requests that initiated the Application Development Services.



4.1.6.2. The Provider will perform the following types of testing unless explicitly excluded to verify and validate the programmed solution:

Unit testing — the programmed solution modules

System testing

Integration testing

Regression testing

Load testing

Stress testing

Security testing

Compliance testing

User acceptance testing (UAT)

Usability testing

4.1.6.3. DSHS will execute the User Acceptance Tests as defined by the Provider as part of the test plan and where such plan has been agreed by DSHS.

4.1.7. Implementation and Data Migration

4.1.7.1. After all required tests have been executed and the programmed solution is verified and validated to be fit for purpose, the Provider will implement the programmed solution. Fit for purpose is defined as the ability to realize the objectives as defined in the Demand Request or Demand Requests that are implemented through the specific programmed solution.

4.1.7.2. The Provider will perform the implementation and data migration activities required to move the programmed solution to the production environment of the involved application, in accordance with the design specifications.

4.1.8. Code Migration

4.1.8.1. The Provider will perform all code migration activities that are required to ensure the programmed solution can move from development through test and acceptance into production.

4.1.9. Software Configuration Management

4.1.9.1. The Provider will perform all software configuration activities that are required as part of the programming and implementation of the programmed solution. Such activities include:

Automatic capture and storage of application-to-component and component-to-component relationships.



Maintenance of the history of those relationships and transformations required to appropriately manage and document (e.g., source control, version control, profiles, security plans) configuration changes affecting the application and its processing environment using appropriate source management tools and industry accepted practices.

4.1.10. Application Change Tracking

4.1.10.1. The Provider will perform all activities that are required and provide all technology that is required to track all changes — to applications, application components or application frameworks — that result from the development or programming effort throughout the complete Application Development Services stack of services as defined in this SOW using appropriate source management tools and industry accepted practices.

These include the following:

4.1.10.2. Library Management — the classification, control and storage of the physical components of an application.

4.1.10.3. Version Control — the maintenance, tracking and auditing of modifications to an application's components over time, facilitating the restoration of an application to prior development stages.

4.1.10.4. Turnover Management — the automated promotion of software changes across different phases of the life cycle (e.g., development, unit test, systems test and production), including management of the approval process, production turnover and software migration control.

4.1.10.5. Documentation — the developing, revising, maintaining, reproducing and distributing information in hard copy and electronic form that enable the support of the developed or programmed solution (e.g., system specifications and documentation, end-user documentation, site and system security plans, updates and release notes).

The Provider will initiate changes to plans or committed dates in relation to the Demand Request or Demand Requests that initiated the Application Development Services in accordance with the procedure as defined in Attachment 04 - Demand Management Plan.

4.1.11. Training and Knowledge Transfer

4.1.11.1. The Provider will perform all activities and provide all materials and technology that is required for the successful use and operation of the developed or programmed solution by the users and support staff that will deploy or support the programmed solution.



4.2. Application Warranty Services 4.2.1. The Provider understands and accepts that every programmed solution is

implemented with a warranty period. The warranty period is set to 90 (ninety) business days after the acceptance by DSHS of the programmed solution and measured from the date the programmed solution was moved into production.

4.2.2. The Provider will perform any activities necessary to repair errors/defects to enable applications and solutions that are programmed and implemented to enhance the application, to perform in accordance with the documented specifications (reflecting the respective Demand Request or Demand Requests the solution was programmed and implemented for) and the documented operational functionality of the affected application.

4.2.3. The Provider will repair code developed by the Provider during the warranty period, at no charge to DSHS, provided that:

4.2.3.1. The problem encountered occurs within 90 (ninety) days of the implementation of such developed code

4.2.3.2. The root cause analysis indicates the problem was introduced solely by code or configuration created by Provider, and 4.2.3.2.1 or 4.2.3.2.2.

4.2.3.2.1. The problem is in an application program where the responsibility is transferred from DSHS to Provider, and the problem is the result of the Provider not following the policies and procedures set forth in Appendix [AS.4] to this Agreement; or

4.2.3.2.2. The problem is in an application program where the responsibility was the Provider's and the problem is the result of the Provider not following the policies and procedures set forth in Appendix [AS.4] to this Agreement.

4.2.4. The Provider will complete full correction of the application(s) defect unless otherwise approved by DSHS, and the corrected code will be appropriately tested to verify that no regression errors are introduced.

4.2.5. DSHS can, at its sole discretion, decide to accept or reject the provided correction. In case of rejection, DSHS will notify the Provider within 5 (five) business days with the reasons for rejection and the expected activities and deliverables to realize acceptance.

4.2.6. The Provider will update all appropriate documentation.

4.2.7. The Provider will provide monthly reports showing the amount of warranty work (number of defects and hours to correct).



4.3. Application Maintenance Services

The Provider understands and accepts that Application Maintenance Services apply to every application as listed in Appendix [AS.1] Applications and Licenses to this SOW, hereafter referred to as "supported applications."

The Provider understands and accepts the assigned responsibilities for the Application Maintenance Services activities that are grouped according to the following Application Maintenance Services components:

Corrective Maintenance

Adaptive Maintenance

Preventive Maintenance

Perfective Maintenance

The Provider understands and accepts that the following services can be combined with any of the above Application Maintenance Services:

Release Packaging

Technical and End-User Support

Monitoring, Reporting and Review

4.3.1. Corrective Maintenance

4.3.1.1. In case of a defect or error in the functionality of technology of supported applications, the Provider will perform all activities required to ensure full recovery of the supported application(s) functionality within agreed Service Levels as set out in Appendix [AS.X] Application Services Service Levels to this SOW.

4.3.1.2. Where the resolution of a defect or error requires changes to the application functionality or technology, the Provider will initiate and fulfill a Demand Request in accordance with Attachment 04 - Demand Management Plan indicating the urgency. The following, non-exhaustive, list of changes are included in the Corrective Maintenance Services as part of defect or error resolution:

User interface changes

Changes to system interfaces

Application module changes

Database changes

Modification to standard query structure

Report changes.



4.3.1.3. When the resolution requires the execution of a Pre-Approved Demand Request as defined in Attachment 04 - Demand Management Plan, the Provider will initiate and fulfill the respective Pre-Approved Demand Request(s).

4.3.1.4. When such changes are estimated by the Provider to exceed 5 (five) person-days effort, the Provider will initiate and fulfill a Project Demand Request in accordance with Attachment 04 - Demand Management Plan indicating the urgency.

4.3.2. Adaptive Maintenance

4.3.2.1. The Provider understands and accepts that development initiatives of any kind can affect supported applications interfacing in any kind with such initiative. DSHS and Provider therefore agree to inform each other of any initiative that might impact supported applications.

4.3.2.2. On notice of such impact, the Provider will analyze the impact of the initiative on supported applications and propose a solution to be included as a Demand Request to the Demand Request document of the initiative that impacts supported applications (hereafter named "Adaptive Demand Request"). Acceptance and fulfillment of such Adaptive Demand Request will be in accordance with the procedure as set out in Attachment 04 - Demand Management Plan to this Agreement.

4.3.2.3. DSHS and the Provider further agree that there are standardized demand requests with known effort and lead time that can be requested by DSHS as part of Adaptive Maintenance activities. The Provider will respond to such Pre-Approved Demand Requests by DSHS as defined in Attachment 04 - Demand Management Plan within the agreed lead time as set out for each Pre-Approved Demand Request.

4.3.3. Preventive Maintenance

4.3.3.1. DSHS and the Provider share the responsibility to minimize the potential impact of future events on the supported applications. DSHS and the Provider therefore agree to exchange any information — business, functional and technical — of expected events that might require preventive actions in regard to the supported applications. The following, non-exhaustive, list of events will trigger preventive maintenance activities:

Changing business volumes

Application packages releases by the Independent Software Vendor

Application packages patches and fixes



Special events, such as public holidays, marketing initiatives, fiscal year end

4.3.3.2. On notice of such event, the Provider will analyze the impact of the event on supported applications and propose a solution as a Demand Request (hereafter named "Preventive Demand Request"). Acceptance and fulfillment of such Preventive Demand Request will be in accordance with the procedure as set out in Attachment 04 - Demand Management Plan to this Agreement. The following, non-exhaustive, list of preventive maintenance activities can occur:

Application release upgrade

Application of system patches

Archiving to free up storage for expected data volume increase

Pre-production execution simulation

Testing for special events

4.3.3.3. The Provider also understands and accepts that it bears the responsibility to improve the stability of the supported applications. The Provider will therefore perform all required activities to minimize the amount of reported incidents for the supported applications in production.

4.3.4. Perfective Maintenance

4.3.4.1. The Provider understands and accepts that it bears the responsibility to continuously aim for improving the performance and efficiency of the supported applications. The Provider therefore consistently analyzes the potential improvement areas to maximize the transaction processing capabilities of the supported applications and shorten the effort required to manage the supported applications. The following, non-exhaustive, list of perfective maintenance activities can occur:

General performance tuning

Improve incident and change response and resolution processes

Increase automation to shorten Demand Request implementations

Archiving to increase application performance

Database performance tuning



4.4. Release Packaging 4.4.1. The Provider will develop an ongoing process for the implementation of a

12 (twelve)-month rolling application release timetable (with associated variation mechanism). The ongoing process and the initial 12-month rolling timetable for each application are to be approved by DSHS.

4.4.2. Release Packaging can be initiated through Application Development Services activities to consolidate Project Demand Requests with bundled Demand Requests that impact the same supported application(s).

4.4.3. Release Packaging can be initiated through Application Maintenance Services activities to consolidate Demand Request deliverables.

4.5. Technical and End-User Support

The Provider understands and accepts the limitations of the skills and competencies of DSHS in the supported applications and will provide all level 2 (two) and level 3 (three) knowledge and skills required for the supported applications at functional and technical levels.

4.6. Monitoring, Reporting and Review

The Provider understands and accepts the limitations of the skills and competencies of DSHS in the supported applications and will perform all monitoring, reporting and review activities for the supported applications at functional and technical levels.

On request of DSHS, the Provider will provide technology solutions to support the monitoring, reporting and review services in accordance with the procedures set out in Attachment 04 - Demand Management Plan and Attachment 03 - Contract Management to this Agreement.

5. Roles and Responsibilities

The section identifies the roles and responsibilities associated with the Application Services defined in this SOW in Section 2. It includes the roles and responsibilities for the listed services for the Provider and DSHS.

The Roles and Responsibility matrices are provided in Attachment 05 - Personnel.

6. Service Levels and Reporting

This section describes the service-level requirements (SLRs) and reporting requirements that apply to the Application Services.

6.1. Service-Level Requirements

The Contractor shall measure its performance against the SLRs in accordance with the methodologies agreed to by DSHS and shall provide a detailed, comprehensive report of its performance against the SLRs during each applicable reporting period ("SLR Reports") by the tenth



(10th) Business Day following the end of the applicable reporting period. For continuing failures that occur in consecutive Measurement Intervals within a month, the Contractor shall report such failures in the month such failures commence. The Contractor shall meet with DSHS at least monthly, or more frequently if requested by DSHS, to review the Contractor's actual performance against the SLRs and shall recommend remedial actions to resolve any performance deficiencies. Notwithstanding the foregoing, all reporting on SLRs shall cover the results of SLR performance during the applicable Measurement Interval, regardless of the Reporting Period, and shall not be construed to limit the Contractor's obligations to comply with all SLRs as per the applicable Measurement Interval. DSHS’ failure to analyze and enforce SLRs shall not be deemed a waiver of such performance standards. In the case where one or more SLRs are not able to be validated as contemplated by this Section, the Parties will negotiate in good faith to establish meaningful SLR(s) to replace such SLR(s).

6.1.1. The Provider must consistently meet or exceed the SLRs as defined in Appendix [AS.10] Service Level Requirements to this SOW. Failure to meet SLRs will be addressed in accordance with Article 6, Fees and Payment Terms to this Agreement. Continued failure in meeting SLRs can lead to termination of this SOW in accordance with Section J, Term and Termination to this Agreement.

6.1.2. The Provider shall provide written reports to DSHS regarding the Provider's compliance with the SLRs specified in Appendix [AS.10] Service Level Requirements to this SOW in accordance with the following section and Attachment 04 - Demand Management Plan.

6.2. Reports 6.2.1. The Provider shall provide written reports to DSHS regarding the

Provider's compliance with the SLRs specified in Appendix [AS.10] Service Level Requirements to this SOW. In addition, the reports listed in Table 1 are required.

Table 1. Reports

Description Frequency



7. Pricing Model

Cost

Services and Deliverables $

Maintenance and Operations $

Software, Hardware and Equipment $

Total Not‐to‐Exceed Cost $

Hourly Rates

Project Role Description Maximum Hourly Rate

Delivery Manager $

Project Manager $

Project Coordinator $

Requirements Lead $

Requirements Analyst $

Technical Lead $

Technical Analyst $

Technician $

Solution Architect $

Technical Architect $

Security Manager $

Security Analyst $

Database Architect $

Database Analyst $

Database Administrator $

Development Lead $

Developer $

Test Manager $

Test Lead $

Tester $



Specialists $

Third Party $

Operations Manager $

Operations Lead $

Operations Technician $

Support Manager $

Support Lead $

$

$



8. Behavior Drivers

8.1. Definition

If the Provider fails to perform the support and maintenance services in accordance with the service levels, DSHS, in its sole discretion, will be entitled to recover the service credits from the Provider either as (i) a sum of money equal to 20% of the fee charged for the Support and Maintenance Services payable by the Provider on demand to DSHS; or (ii) as a credit against the support and maintenance charges equal to 20% of the fee charged for the support and maintenance services provider. Service credits shall be DSHS's remedy for the period of delay to which the service credits relate save where such monetary damages are not an appropriate remedy, in which case such service credits shall be without prejudice to DSHS's right to seek remedies other than monetary damages. DSHS will be entitled to exercise all of its rights under the agreement or otherwise in respect of any failure, other than delay, by the Provider to perform the support and maintenance services in accordance with the agreement.

8.2. Commitment to Comply with All SLRs.

Beginning on the applicable Handover Date and continuing through the Steady State Date, the Contractor shall use commercially reasonable best efforts to perform all Services in accordance with, and in such a manner as to meet or exceed, the SLRs; provided, however, that in any event, the Contractor shall perform the Services during such period in a manner that is at least as good as such services were being performed as of the Effective Date. Beginning on the Steady State Date, the Contractor shall perform all Services in accordance with, and in such a manner as to meet or exceed, the SLRs. Any Services developed by the Contractor pursuant to the terms of this Agreement shall incorporate methods permitting measurement of performance-related SLRs. The Contractor shall comply with all SLRs set forth in this Exhibit or elsewhere in this Agreement, including, without limitation, all SLRs for which no reduction in fees has been assigned.

8.3. Root-Cause Analysis and Resolution.

Promptly, but in no event later than five (5) calendar days after the Contractor's discovery of, or if earlier, the Contractor's receipt of a notice from DSHS regarding the Contractor's failure to provide any of the Services in accordance with the SLRs, or for the existence of an Issue, the Contractor shall, as applicable under the circumstances: (i) perform a root-cause analysis to identify the cause of such failure/Issue; (ii) provide DSHS with a written report detailing the cause of, and procedure for correcting those failures/Issues that are under the Contractor's control; and (iii) provide DSHS with satisfactory evidence that the Contractor has taken or will take commercially reasonable remedial steps to ensure that such failure/Issue will not recur to the extent under the Contractor's control. To the extent the cause of failures/Issues are not under the Contractor's control, then the Contractor will suggest appropriate corrective measures to the extent commercially reasonable. The correction of any such failures/Issues shall be performed entirely at the Contractor's expense unless it has been determined, by mutual agreement of the Parties that DSHS (or one of its subcontractors, agents or Third Parties provided by DSHS) was a direct contributing cause of the failure/Issue (but excluding contributing causes of Third Parties provided by



DSHS that are managed by the Contractor to the extent such causes arise out of the Contractor's failure to properly manage such Third Parties) and the Contractor could not have worked around the failure/Issue without expending more than commercially reasonable efforts. In such event: (i) the Contractor shall be entitled to temporary relief from its obligation to comply with the affected SLR in a timely fashion, but only to the extent and for the duration so affected; and (ii) DSHS shall reimburse the Contractor for the Contractor's expenses to correct such failure/Issue, but only to the extent DSHS caused such failure/Issue, unless the Parties otherwise mutually agree. For purposes hereof, except as otherwise agreed by the Parties in writing, the pre-existing condition of DSHS’ properties and systems shall not be deemed a contributing cause of any failure if the Contractor knew or reasonably should have known of such condition and has had a reasonable period of time to implement corrective measures; provided, however, that, except as otherwise agreed by the Parties in writing, and subject to DSHS’ approval, to the extent that the Contractor first became aware of such a pre-existing condition subsequent to the Effective Date, DSHS shall be financially responsible for all corrective measures that are necessary to correct such condition through the Change Control Process.

8.4. Relief from SLRs.

If and to the extent that: (i) the failure to provide any of the Services in accordance with the SLRs is directly caused by a Force Majeure Event; (ii) the Contractor did not have an affirmative duty under the Agreement to prevent such a failure; and (iii) with respect to Services at issue, the Contractor used all commercially reasonable efforts to promptly implement disaster recovery and/or business continuity plans, as appropriate, the Contractor shall be entitled to temporary relief from its obligation to comply with the affected SLR in a timely fashion, but only to the extent and for the duration so affected. Additionally, if and to the extent that there are (i) pre-existing conditions of DSHS Sites and systems which were unknown to the Contractor on the Effective Date; (ii) the pre-existing conditions could not be discovered upon reasonable due diligence prior to the Effective Date; and (iii) such pre-existing condition is the cause of such failure/Issue, the Contractor will be temporarily excused from a particular SLR (to the extent attributable to the pre-existing condition) and DSHS shall be financially responsible for corrective measures that are necessary to correct such pre-existing condition through the Change Control Process. However, unless otherwise agreed by the Parties, if the Contractor (i) knew as of the Effective Date of such pre-existing condition and has had a reasonable period of time to implement corrective measures; or (ii) reasonably should have known of the Effective Date of such pre-existing condition and is granted a reasonable period of time to implement corrective measures, no SLR relief will be granted.

8.5. Review of SLRs.

The Parties agree that the SLRs will improve over time and that new SLRs may be added to reflect improvements in technology, DSHS’ changing and/or new business requirements. Accordingly, at least once annually, the Parties expect to review and reach agreement on, among other things: (i) adjustments to the SLRs to reflect such anticipated continuous improvements in the SLRs; and/or (ii) the addition of new SLRs. In the event the Parties are not able to reach agreement on a proposed SLR modification within 60 days of a Party raising a request, the Parties will obtain the recommendation of a third party to provide market



information regarding the reasonableness of the proposed modification. The Contractor agrees to maintain and improve SLRs from time to time in accordance with the remainder of this Section. Unless requested by DSHS, in no event will the SLRs be made less favorable to DSHS as a result of such reviews.

8.6. Benchmarking.

DSHS shall have the ongoing right to initiate the benchmarking process meaning to evaluate or check by comparison with a standard, as agreed upon in the final contract, in order to evaluate: (i) the SLRs set forth in this Agreement; and (ii) the Fees set forth in this Agreement. The terms, conditions and procedures to be used during the benchmarking process will be those agreed upon in the final contract.

8.7. Characterization Period.

The Characterization Period is a period of 120 days beginning on the Steady State Date during which reduction in fees will not apply, and during which the Parties will take the actions set forth in this Section to validate and, if appropriate, adjust the SLRs. In the event that the Contractor misses one or more SLRs during the period from Steady State Date to 120 days after Steady State Date the Contractor shall provide a root-cause analysis (no later than 130 days after Steady State Date. If the primary cause of the failure is based on insufficiency of DSHS’ Owned Assets, DSHS Leased Assets, or an architectural configuration under DSHS’ control, DSHS shall: (i) negotiate with the Contractor a reasonable adjustment to SLR targets (up or down) to more accurately reflect performance achievable in DSHS environment; or (ii) work with the Contractor on developing and executing a remediation plan to achieve the target SLRs. If DSHS elects to work with the Contractor in developing and executing a remediation plan, the Contractor shall continue to report the performance related to affected SLRs during the remediation period. Additionally, during the remediation period, if the primary cause of the failure is based on insufficiency of DSHS’ Owned Assets, DSHS Leased Assets, or an architectural configuration under DSHS’ control, reductions in fees will not apply to the SLR, which is the subject of the remediation plan. Failure by the Parties to agree upon adjustments and or a remediation plan will be resolved in accordance with the dispute resolution procedure. Except as set forth above, other adjustments to the SLRs may require an equitable adjustment to the applicable Services Fees.

8.8. Service Credits.

If the Contractor fails to meet the service levels requirements described in this Exhibit, DSHS, in its sole discretion, will be entitled to recover the service credits from the Contractor either as (i) a sum of money equal to 20% of the fee charged for the Support and Maintenance Services payable by the Contractor on demand to DSHS; or (ii) as a credit against the support and maintenance charges equal to 20% of the fee charged for the support and maintenance services Contractor. Service credits shall be DSHS’ remedy for the period of delay to which the service credits relate save where such monetary damages are not an appropriate remedy, in which case such service credits shall be without prejudice to DSHS’ right to seek remedies other than monetary damages. DSHS will be entitled to exercise all of its rights under the agreement or otherwise in respect of any



failure, other than delay, by the Contractor to perform the support and maintenance services in accordance with the agreement.

8.9. Earn-Back

Following any service-level failure, DSHS may allow the Provider the opportunity to earn back the service credits charged in one or more measurement period. If all the service levels for the relevant service and any others agreed to be associated with that service are met, or exceeded, during each of the three measurement periods following the service-level failure, DSHS may, at its sole discretion, return half of the service credits paid to the Provider. If all the service levels for the relevant service and any others agreed to be associated with that service are met, or exceeded, during each of the six measurement periods following the service-level failure, DSHS may, at its sole discretion, return the remaining half of the service credits paid to the Provider. The Provider may, where the requisite levels of performance are achieved, make representations to DSHS in this regard.

8.10. Failure

Following any service-level failure, DSHS may allow the Supplier the opportunity to earn back the service credits charged in one or more measurement period. If all the service levels for the relevant service and any others agreed to be associated with that service are met, or exceeded, during each of the three measurement periods following the service-level failure, DSHS may, at its sole discretion, return half of the service credits paid to the Supplier. If all the service levels for the relevant service and any others agreed to be associated with that service are met, or exceeded, during each of the six measurement periods following the service-level failure, DSHS may, at its sole discretion, return the remaining half of the service credits paid to the Supplier. The Supplier may, where the requisite levels of performance are achieved, make representations to DSHS in this regard.

8.11. Credits Returned 1st

Where service credits are to be returned pursuant to Section 3.3, DSHS shall pay back half of the value of the service credits charged in a single failing measurement period, at the end of each measurement period where performance meets service levels, after the qualifying three, smallest first, until half of all have been repaid, or another service-level failure occurs. So, for example, if in Measurement Periods 1 and 3 there are service-level failures such that service credits of $1,400 and $900 are payable (and paid) by the Provider, DSHS may notify the Provider that it may repay these sums if there are improvements in the services. If, in Measurement Periods 4, 5 and 6, service levels were met or exceeded, then, provided they continued to be met or exceeded thereafter:

8.12. Measurement Period 7

In Measurement Period 7, $450 or half of the $900 paid for service-level failure in Measurement Period 3 would be repaid.




In Measurement Period 8, $700 or half of the $1,400 paid for service-level failure in Measurement Period 1 would be repaid.

8.14. Credits Returned 2nd

Where service credits are to be returned pursuant to Section 3.3, DSHS shall pay back the remaining half of the value of the service credits charged in a single failing measurement period, at the end of each measurement period where performance meets service levels, after the qualifying six, smallest first, until half of all have been repaid, or another service-level failure occurs. So, for example as above, if in Measurement Periods 1 and 3 there are service-level failures such that service credits of $1,400 and $900 are payable (and paid) by the Provider, DSHS may notify the Provider that it may repay these sums if there are improvements in the services. If, in Measurement Periods 7, 8 and 9, service levels were met or exceeded, then, provided they continued to be met or exceeded thereafter:


In Measurement Period 10, a further $450, or the remaining half of the $900 paid for service-level failure in Measurement Period 3, would be repaid.


In Measurement Period 11, a further $700, or the remaining half of the $1,400 paid for service-level failure in Measurement Period 1, would be repaid.

8.17. Review of Service Levels and KPIS

On an as-needed basis after the initial start-up service levels have been established, Company can request a change to any service level by providing notice to the Provider that a service level needs to be changed. This change can take effect only after the Provider has had sufficient time to review the requested change and determine if any modifications are required to the delivery of the support and maintenance services. Should changes be required by the Provider, then Company must allow Provider reasonable time to make such changes before the service-level change takes place.

8.18. Startup Timing

On a quarterly basis beginning six months after the date of signing the agreement, DSHS and the Provider shall review the service levels and KPIs and agree to adjustments to them or new requirements as appropriate.



9. Referenced SOW Appendices, MSA Articles and Attachments Table 1. SOW Appendices

Appendix Name

[AS.1] Applications and Licenses

[AS.1 sub A] Application Architecture

[AS.1 sub B] Application Workload

[AS.3] Facility Security Requirements

[AS.4] Application Services Policies Procedures

[AS.5] Regulatory Compliance Requirements

[AS.9] Application Architecture Guidelines

10. Revision History

Revision History

This section is for the sole purpose of recording all changes made to the Application Services SOW (see Table 2). This is done to ensure a historical view of changes that might relate to any issues or challenges that are identified during the outsourcing engagement.

Table 2. Revision History

Date (MM/DD/YYYY)

Author Version Reason for Change



11. SOW Acceptance

SOW Acceptance

By signing below, DSHS and the Provider accept this SOW.

SOW effective date: ___________________

ACCEPTED BY:

DSHS

ACCEPTED BY:

Provider

Name: Name:

(Please print) (Please print)

Title: Title:

(Please print) (Please print)

Signature: Signature:

Date: Date:



12. Appendix [AS.1] Applications and Licenses

This appendix will hold the list of applications to be supported through the Services.

Example

Name

(unique)

Version Version Date

Business Processes Supported

Business Processes

Perform Measure

Inbound Interfaces

Outbound Interfaces

Agreement Reference

License Keys

Related DBs

Related DBs

Versions

Platform Framework Functional App Owner

Techapp Owner

13. Appendix [AS.1 sub A] Application Architecture

This appendix will hold the logical and technical application architecture representations for the supported applications.

14. Appendix [AS.1 sub B] Application Workload

This appendix will hold the workload per supported application or at minimum the total development and maintenance workload, where the workload represents the services as included in this SOW.

When not all development and or maintenance work is outsourced and part of the total workload is retained, create separate DSHS and Provider tables OR only list the outsourced hours.

Example

Application

Name

(Unique)

Development hrs/yr

Minor Enhancement

hrs/yr

Corrective Maintenance

hrs/yr

Adaptive Maintenance

hrs/yr

Preventive Maintenance

hrs/yr

Perfective Maintenance

hrs/yr

15. Appendix [AS.3] Facility Security Requirements

This appendix will hold the relevant DSHS Security Requirements that apply to service delivery facilities.



16. Appendix [AS.4] Application Services Policies Procedures

This appendix will hold the relevant DSHS policies and procedures that apply to the outsourced Application Services and that the Provider has to adhere to. This will also include standard operating procedures and standard development procedures that might be included in an Operational Services Manual or Development Manual.

17. Appendix [AS.5] Regulatory Compliance Requirements

This appendix will hold the relevant DSHS policies that govern regulatory compliance.

18. Appendix [AS.9] Application Architecture Guidelines

This appendix will hold DSHS application functional and technical architecture guidelines to which the Provider needs to adhere. Such guidelines can be based on The Open Group Architecture Framework (TOGAF), Service Oriented Development of Applications (SODA), Rational Unified Process (RUP) or Architected Rapid Application Development (ARAD), or any other applicable and relevant standard, and then applied to DSHS-specific situation.

Service Level Requirements Appendix [AS.10]


19. Appendix [AS.10] Service Level Requirements

Service-Level Requirements – a Service Level Requirement (SLR) is a broad statement from a customer to a service provider describing their service expectations. A service provider prepares a service level agreement (SLA) based on the requirements from the customer.

Service Level Requirement Towers

Q Quality

E Efficiency

A Availability

S Security

D Application Development

C Computing Services

R Staffing/Resources



Home

19.1. SLR Tower – Quality If any one performance target is missed the whole tower is considered to fail for that performance period. Tower Weight 3%

Include: accepted code, defects, defect leakage to production, cost to resolve defects, etc.

Area System/Type Service Measure

Performance Target SLR Performance % Formula Intervals Tool

Q1

Response Time of the Application

Intent:

To ensure that ACES and ACES.Online users receive timely responses to transactions. To ensure the application is designed, coded and operating efficiently.

This SLR is not intended to hold the Bidder accountable for response delays resulting from DSHS infrastructure issues.

1 (CICS): 0.15 seconds5

2 (WEB): 0.17 seconds5

WEB CICS transactions associated with printing letters locally are excluded from calculating average response time.

1 (CICS): 0.25 seconds

2 (WEB): 0.3 seconds

WEB CICS transactions associated with printing from calculating average response time.

Minimum performance is calculated by averaging all Production CICS transactions over the measurement period. Web transaction averages do not include response time for the letter print job (WE99).

Both Mainframe and Web averages must meet the minimum target or else the service level is considered unmet.

Measure during peak daily hours Report Monthly

Q2

Q3

Q4

* Definitions:

1 Total Software Defects Total software defects are count from Requirements Definition through two months after release or until next release (whichever occurs first)

2 Requirements Specification Miss Code does not match the requirements and/or design specification documentation

3 Defects Fixed Fixes made to defects found during testing



4 Release An agreed upon body of work scheduled for requirements definition through deployment to production environments. Can include problem resolution requests and well as change requests.

5 Measurement of CICS Time 1 All internal CICS Production transactions. CICS internal response time is measured by using PERFORMANCE REPORTER software reporting against CICS transaction logs. Batch jobs are run each night to generate hourly, daily and monthly monitoring reports.



Home

19.2. SLR Tower – Efficiency If any one performance target is missed the whole tower is considered to fail for that performance period. Tower Weight 3%

Include: Items like automating business processes (automating scripts, etc.)

Area System/Type Service Measure Performance Target SLR Performance

%

Formula Intervals Tool

E1

Batch Performance / Batch Turnaround

Intent:

To ensure that all batch-processing jobs determined by DSHS to be run within the allotted batch window are completed within the allotted batch window. To ensure the application is designed, coded and operating efficiently.

100%1 100 % (same as target).

Minimum performance is calculated by number of approved batch jobs that completed within the approved batch window divided by the number of approved batch jobs.

Measure daily and report daily

and monthly.

E2

E3

E4

E5

E6

E7

E8

E9



* Definitions:

1 Measurement of Batch Performance

All approved production batch-processing jobs must complete within the batch window approved by DSHS. Batch processing that exceeds the batch window must complete within the batch window or at a pre-determined time approved by DSHS. Batch turn-around shall be measured by the Bidder’s adherence to DSHS approved production schedule for batch processing.

2

3

4

5



Home

19.3. SLR Tower – Availability If any one performance target is missed the whole tower is considered to fail for that performance period. Tower Weight 3%

Include: Items like Application availability (includes usability by the end users), etc.


%


A1

Intent:

To ensure that ACES and ACES.Online are available and operational during designated hours of operation.

This SLR is not intended to hold the Bidder accountable for outages or lack of availability resulting from DSHS planned outages or DSHS infrastructure failure.

1 (CICS): 100%4 2 (WEB): 100%5

1 (CICS): 99% 2 (WEB): 99%

Minimum performance is measured by dividing the total number of minutes the system was available (calculated by subtracting the above unavailable measurements from the scheduled available time) by the total number of minutes the system is scheduled to be available during the measurement period as shown in the ACES Production Schedule.

Measure Daily, Report Monthly

A2

A3

A4

A5

A6

A7



* Definitions:

1 Availability The availability of the in-scope infrastructure components required to conduct the normal business operation of Client application systems, including processors (e.g., mainframe CPU, memory, and storage), external storage, system Software and Network connection. Excludes scheduled maintenance.

2 Pre-Scheduled Downtime Requirements

All pre scheduled system downtime, unless otherwise agreed on in advance by the Client, will occur:

1. For the systems with 24/7 requirements — all pre scheduled maintenance shall be performed based on the Client's Change Management policy 2. For systems having non 24/7 requirements — pre scheduled maintenance shall be performed outside of the normal System Availability time frame

3 Unavailability (∑ Outage Duration × 100%) ÷ (Schedule Time — Planned Outage)

4 Measurement of CICS Time 1:

All CICS Production Regions.

Measured by the number of minutes (duration) any production CICS region is either down (not running) or not responding to transaction requests. If one or multiple regions are down or not responding, the duration of the outage starts from the time the earliest region is down or not responding to the time the latest region is back running and/or responding to transaction requests.

5 Measurement of WEB Time 2:

ACES.Online Application Servers.

Measured by the number of minutes (duration) the ACES.OnLine Application Server is causing client outages or not responding to client requests. The duration of the outage starts from the time that the application is not responding to client requests to the time the servers are back running and/or responding to client requests.



Home

19.4. SLR Tower – Security If any one performance target is missed the whole tower is considered to fail for that performance period. Tower Weight 3%

Include:

Area System/Type Service Measure Performance Target SLR Performance % Formula Intervals Tool

S1

S2

S3

* Definitions:

1 OWASP Top 10 Vulnerabilities

Current top 10 vulnerabilities as published by the Open Web Application Security Project.

2

3

4

5



Home

19.5. SLR Tower – Application Development If any one performance target is missed the whole tower is considered to fail for that performance period. Tower Weight 3%

Include: Things like Response time per incident type (critical, major or minor) , Resolution time per incident type (critical, major or minor), Completion time per request type (simple, medium or complex) — average in rolling 12 months, average improvement in the rolling quarter, average improvement in past 12 months vs. previous 12 months, within one standard deviation

Area System/Type Service Measure Performance Target SLR Performance % Formula Intervals Tool

D1

Problem Reports Intent:

To ensure that all critical system issues (SEV1) are acknowledged by the Contractor in a timely manner and that appropriate resources are assigned to investigate and resolve those issues in a timely manner.

1 (notify): 100%5

2 (attend): 100%6

1 (notify): 95%

2 (attend): 95%

Calculation of Minimum Performance 1:

Minimum performance for response is measured by the total number of responses within 30 minutes of DSHS notification divided by the total number of SEV1 notifications within that calendar month.

Minimum performance for response is measured by the total number of responses within 30 minutes of DSHS notification divided by the total number of SEV1 notifications within that calendar month.

Calculation of Minimum Performance 2:

Minimum performance for attendance at SEV1 meetings is calculated by dividing the number of SEV1 meetings within a calendar month that Bidder staff attended by the number of SEV1 meetings held within that calendar month.

Measure Daily, Report Monthly

D2

D3

D4

D5



* Definitions:

1 Release/Project Estimate Hours Development hours estimated to perform development tasks per release work package

2 Actual Hours Hours burned to perform development tasks per release work package

3 Milestone Requirements, Design, Code Complete, Unit & Integration Testing

4 SEV 1

Incident occurs in the production environment that meets the following criteria: System outage (ACES Systems, WaCon) Instability exists in critical functions causing a significant impact to the field and/or stakeholders. Current security vulnerability includes an active data or Federal Tax Information (FTI) breach. Incorrect calculations affecting a significant population causing HBE to take HPF off-line.

5 Measurement of Problem Reports 1 (Notify):

Upon notification by DSHS in writing (e-mail acceptable) of a SEV1, the Bidder will respond within 30 minutes in writing (e-mail acceptable) notifying DSHS of receipt. (Automated e-mail responses are not considered notification for the purpose of this SLR).

6 Measurement of Problem Reports 2 (Attend):

At least one Bidder staff will attend any SEV1 meeting scheduled by DSHS. Attending Bidder staff will report on investigation, resolution and resources applied to resolution.



Home

19.6. SLR Tower – Computing Services If any one performance target is missed the whole tower is considered to fail for that performance period. Tower Weight 3%

Include: Items like Average response time, Response time per incident type (critical, major or minor) , Resolution time per incident type (critical, major or minor), Completion time per request type (simple, medium or complex) — average in rolling 12 months, average improvement in the rolling quarter, average improvement in past 12 months vs. previous 12 months, within one standard deviation. Business continuity and DR?

Area System/Type Service Measure Performance Target SLR

Performance %


C1

C2

C3

C4

C5

C6

C7

C8

C9

C10

C11

C12

C13

C14

C15



C16

C17

C18

C19

C20

* Definitions:

1 Application Platform Response

Online response time for critical online applications including ERP, data warehouse, financial, HTTP, etc.

2 Completion Time to Request

3 Database Administration

4 System Software Refresh

5 System Administration



Home

19.7. SLR Tower – Staffing/Resources If any one performance target is missed the whole tower is considered to fail for that performance period. Tower Weight 3%

Include: Items like Quality, retention, attrition, (use Reduced Resource Credits - an adjustment to a service contract based on the decreased volume of services performed by the vendor. A RRC is applied to reduce the base charge for each unit that is used below the volume baseline. If volume usage is greater than the volume baseline then one or more additional resource charges will apply.)


%


R1

R2

R3

R4

R5

R6

* Definitions:

1

2

3

4

5

1723-669 attachment 01 - sow slr pricing bhd · (iso) 20000 practices for service management and...

Documents