Statement of Work: JumpStart

This Statement of Work (this “SOW”) is entered into and governed by the Master Subscription Agreement, Subscription Terms, or other similar written agreement (the “Agreement”) by and between Customer (“Customer”), and Harness Inc. (“Harness”) (Customer and Harness each a “Party”, and collectively, the “Parties”).  This SOW and the Agreement constitute the complete agreement regarding services provided under this SOW.  Except where the contrary is expressly provided, the terms and conditions of the Agreement shall prevail over any conflicting terms or conditions in this SOW.  

Changes to this SOW will be processed in accordance with the procedure described below. The investigation and the implementation of changes may result in modifications to the schedule, resources, charges and/or other terms of this SOW.

Any defined terms not specifically defined herein shall have the meaning given to them in the Agreement. 

1.  DEFINITIONS

“Business Day” means any weekday, Monday through Friday, for 8 hours, generally falling between 9:00 A.M. and 5:00 P.M. in the time zone of the Harness implementation engineering team, excluding holidays and weekends, unless otherwise agreed in writing by the Parties.

“Business Week” means 5 Business Days, Monday through Friday.
“Harness Reference Architecture” means a predefined, example implementation and accompanying documentation that outlines the ideal use of Harness products, as provided and updated by Harness from time to time.

“Project” means a project plan created by Harness after the Design & Discovery Sprint, detailing the architecture and design for the applicable software module, key project details such as milestone dates, timelines, project prerequisites, and any potential issues that may jeopardize the project timeline.  This document will be used to guide the completion of this SOW.

“Project Summary” means a summary of the work completed under this SOW, which will be created by Harness upon completion of the Sprints.

2.  PROJECT OVERVIEW 

This SOW covers services intended to provide engineering expertise to deliver a reference deployment of an applicable Harness Platform software module, based on best practice reference architecture within the bounds of the project timeline Harness Platform (“JumpStart Engagement)”. The Reference JumpStart Timeline is defined below. (the “Original Project Duration”).  Harness may utilize an employee or subcontractor (a “Partner”) to provide the Services under this SOW.  Harness shall remain liable or all acts and omissions of its personnel in their provision of the Services set forth in this SOW.  

Harness will provide a team including a Solution Architect (the “SA”) who will work with the Customer for the Sprints, to implement and deliver the Project as described in this SOW. 

Reference JumpStart projects are delivered as a series of phases: the Reference Alignment Phase, the Platform Fundamentals Phase, and the Reference Implementation Phase as described below.

Prior to beginning the first phase, Harness will schedule a series of working sessions with the Customer. These working sessions are for live collaboration between engineers from the Customer and Harness. Each working session will focus on completing tasks for the current phase and will not exceed four (4) hours in duration per Business Day. A minimum of four (4) working sessions is recommended. The Customer engineer(s) should expect follow-on tasks and actions from the live working sessions that will need to be completed prior to the next live session. 

The timing of each phase will require the Customer to schedule and commit Customer staff to support Harness in its delivery of the project pursuant to the agreed-upon schedule.  The Harness Reference JumpStart project is designed to provide the customer with a high level configuration summary of the Harness Reference Architecture. 

3. STANDARD TIMELINE; SCOPE OF PROJECT; SPRINTS; ACCEPTANCE

Reference JumpStart Project Timeline

Scope of Project 

The procedures set forth below and in the appendices (as referenced) apply to the duration of this JumpStart SOW, for provision and utilization of the Reference JumpStart Project of a single Harness software module (the “Product”). This SOW includes (A) Platform Fundamentals Scope (see Appendix), and (B) Reference Architecture Scope (see Appendix A). 

Reference JumpStart Kickoff

The SOW shall begin with a kickoff meeting, known as the “Reference JumpStart Kickoff”, which will be scheduled by the Harness team taking into account Customer’s preferred schedule. The intent of the Reference JumpStart Kickoff is to introduce and align stakeholders, decision makers, engineers and the Harness team to ensure clear understanding of the process to be followed.  The Reference JumpStart Kickoff is also intended to determine any onsite logistics (if necessary), key technical resources needed from the Customer, and general ways of working during the engagement. The outcome of this call should result in the scheduling of the Project phases.

The Harness project team, Sales Account Executive, and/or Customer Success Manager, will share the Reference JumpStart Project Plan and coordinate scheduling of the kickoff. 

Sprint Details

Discovery & Design Sprint

The purpose of the Discovery & Design Sprint is to align a customer’s desired outcomes with a relevant, pre-designed Reference Architecture. During this Sprint, the Parties will also review the product configuration requirements, refining scope and committing to the staffing and dates for the Implementation Sprints. The outcome of this Discovery & Design Sprint is to ensure the Customer and Harness align the Project schedules, goals and scope of the professional services purchased.  The Discovery & Design Sprint must be completed prior to starting the Implementation Sprints. 

This Sprint will cover the following topics: 

• Discovery
  — Understand the Customer environment in which the Product will be utilized
  — Identify Product goals, which can include:
  —— Details about the Customer’s legacy solutions being replaced/enhanced by the Product
  —— Product utilization infrastructure
  —— The Customer’s Pilot use case details
  —— The end-users in the Customer’s Pilot team
  — Identify Harness Platform and Product configuration goals, which can include:
  —— Single Sign On for user management
  —— RBAC Persona requirements
  —— Security Compliance requirements and stakeholders
  — Identify Product adoption goals, which can include:
  —— Mapping of Customer organization structure / business unit hierarchy to Product account hierarchy
  —— End-user experience standards
  ——— UI, CLI, and/or code commit

• Design
  — Review Product implementation designs based on reference architectures and recommended practices
  — Identify prerequisites and/or dependencies to be addressed before Implementation Sprints can begin, this may include factors such as: 
  —— Networking rules for ingress and egress 
  —— Required security exceptions 
  —— Delegate Architecture topology and requirements
  —— Systems in-scope for Product integration
  —— Customer-managed Reference Environments
  — Requirements for Product-specific implementation that will be included in this Reference JumpStart will be outlined in the appendix in this document.
  
  

• Technical Implementation Planning: To be completed during the Discovery & Design Sprint
  — Outline implementation prerequisites
  — Identify Project Team Members by role, organization (Harness, Customer, or Implementation Partner (“Partner”)), and business unit
  — Determine agreed upon dates for the Implementation Sprints 
  — Collect onsite visit logistics (if applicable)
  

Implementation Sprint

The purpose of the Implementation Sprints is to implement the Platform Fundamentals and the identified Reference Architecture.

• Customer Prerequisites 
  — The Customer agrees that any implementation prerequisites will be completed prior to the start of implementation
  
  

• Platform Setup
  — Single Sign-on integration with one (1) supported Identity Provider
  —  Implement the Pilot Account Hierarchy
  — Configure Persona-based RBAC
  — Secret Manager integration with one (1) supported Encrypted Secret Storage Provider
  
  

• Reference Architecture Implementation‍
  — Implementation of the Product based on the architecture and design identified in the Reference Alignment Phase and based on the best practice scope of specific Product outlined in the appendix of this document.
  
  

• Deliverables
  — Product implementation is complete and accessible by the Customer (non-production). 
  — Knowledge transfer of the services rendered as part of the Reference JumpStart project.
  — Post-Engagement Document Updates
  —— Important findings during Implementation Delivery
  —— Additional recommendations the Customer may wish to perform after the engagement (not in scope of this project)
  —— Operational Runbooks for the Reference Architecture
  —— Technical Manuals / Documentation for the Reference Architecture

Acceptance of Completion of Reference JumpStart Project

Acceptance of the Project under this SOW is deemed to occur upon delivery of the tasks and deliverables as defined in each/all Sprint(s). The Customer will provide requested sign off on the completed Project. The Customer will be asked to provide survey feedback on the Project delivery experience. 

4.  RESPONSIBILITIES; ACCEPTANCE; SCHEDULING; OWNERSHIP

Customer Responsibilities:

Customer acknowledges and agrees that Harness’s ability to deliver the Services is dependent upon  Customer’s full and timely cooperation with Harness, which includes the completion of the following tasks, as well as the accuracy and completeness of any information and data Customer provides to Harness. Customer is responsible for delays and any additional costs caused by Customer’s failure to comply with their responsibilities. Harness will not be responsible for any resulting fees or expenses. 

• Customer is responsible for providing all Product implementation prerequisites before Implementation Sprints begin; these prerequisites may include, but are not limited to:
  — Permissions to manage cloud/on-premise infrastructure 
  — DNS entries 
  — TLS Certificate and related keys
  — Cloud/on-prem network and/or proxy configuration, if needed
  — Airgap systems, if needed 

• Customer will provide all requested contact information for the Customer’s key business leaders and stakeholders required for Harness to provide the Services
• Customer will coordinate communications with, and provide contacts for, all third Parties necessary for the completion of the Project
• Customer will deliver timely responses to requests for information, technical questions and requested decisions pertaining to the Project and this SOW. Harness shall not be responsible for any delays in the provision of Services due to Customer’s non-compliance with this requirement
• Customer will diligently manage and supervise Customer’s other contractors and service providers as necessary to support the Services
• Customer will coordinate Service implementation on third-Party-maintained hardware/software (if applicable) with Harness
• Customer will assign a designated Subject Matter Expert coordinator (SME) from Customer’s staff who, on its behalf, will grant all approvals, provide information, make decisions, attend meetings, and otherwise be available to assist Harness in facilitating the delivery of the Services
• Customer will assign a designated engineer and appropriate supporting staff to implement the Project
• Customer will assign a designated Project manager to facilitate on time delivery of Project
• Customer will ensure the availability of all hardware, firmware, and software required by the SA/SEN to deliver the Services and provide network access to integrate required tooling and systems with the Product including (but not limited to) Artifact Repositories, Version Control Systems, Identity Providers, Log Aggregators, Security Scanning Tools, Monitoring Systems, and Developer Tool platforms
• Customer will provide reasonable access and working space at the site as Harness may request

‍

Harness Responsibilities: Harness is responsible for providing the Services outlined in Section 3 above. Where Harness is performing Services on-site for a Customer, Harness shall ensure that its personnel conduct themselves in accordance with the standard health, safety, and security policies of Customer applicable to its staff and or visitors generally, as long as such policies are provided to Harness in writing, in advance. Customer agrees to provide written notice to Harness of any applicable non-standard policies (for example, the requirement of security clearance) prior to executing an Order Form for the Services.

‍

Limitations/Exclusions: Customer acknowledges and agrees that following limitations apply to this SOW:

• The Product implementation will be completed using only approved methods by Harness for generally available versions of the Product
  — Terraform will be used for automated deployment of the Product when deploying to the commercial offerings of Azure, AWS, or GCP, and manual otherwise
  — The Product implementation will be modeled after Harness Reference Architecture and Harness best-practices

• The Module Accelerator Scope will be scoped to a single Pilot Use Case
• The single module Product implementation will be limited to one (1) Pilot Team
• Single Sign On configuration leveraging a non-tested Identity Management Platform that supports the SAML 2.0 standard can only be accommodated on a “best effort” basis and is not guaranteed
• Customer must make available its Identity Management Platform administrator to make necessary changes outside the Product when configuring Single Sign On
• The Product implementation in scope for this engagement will be “production-grade” and maintain a sightline to a Production implementation, BUT it is the Customer's responsibility and prerogative to promote the Pilot Use Case from a non-production environment to the Customer’s production environment.
• Governance Policies delivered as part of this engagement will be sourced from out-of-the-box examples, and any needed modifications can be accommodated on a best effort basis only and are not guaranteed.
• Customer is responsible for any system integrations that are not supported by out-of-the-box integrations.  
• Knowledge transfer sessions will be limited to no more than two (2) sessions, totaling no more than four (4) hours in the aggregate, over the entire term of this SOW.
• The Services will be delivered as a single, continuous workstream.  Environments requiring multiple engagements, phases, or timelines that exceed the standard timelines are excluded from the scope of this SOW.  If Customer requires additional scope, the Parties must execute a Change Order or enter into a separate Order Form and Statement of Work.
• Recording of Meetings and Working Sprints is not allowed unless agreed and documented in the Project delivery document.
• All services are provided remotely unless pre-approved travel arrangements are made with the Customer, subject to the expense reimbursement guidelines set forth in Section  5 below.
• Any implementation of recommendations provided by Harness, such as system configuration, performance tuning, or database design improvements, which are not recommendations for the Product itself, are excluded.
• Once the Implementation Sprint is completed, Customer is responsible for maintaining any changes or improvements to any and all code artifacts, automation work, and/or documentation delivered under this SOW, including the continued support and maintenance of the foregoing.
• The following are expressly excluded from the scope of Services provided under this SOW: (i) hardware maintenance and repair; (ii) software maintenance and upgrades, (iii) instructor led training, (iv) operational runbooks or execution plans.
• Harness standard maintenance and support services are provided in accordance with Harness’ maintenance and support policy, and such services are not part of this SOW. 
• The Services provided under this SOW are specific to the designated Product licensed by Customer only, and do not include any consultation, guidance, or support for any other software, solutions or materials.

‍

Scheduling/Governance of Sprints:

• A Sprint duration is defined as a minimum of one (1) Business Week, and a maximum of two (2) consecutive Business Weeks
• Each Sprint will align with a Business calendar week
• Time between Sprints cannot exceed more than two (2) Business Weeks
• Once a Sprint has started, the Customer is committed to the scope, deliverables and timeline, and the Sprint may not be suspended or delayed.
• If a Sprint is suspended or delayed due to the acts or omissions of Customer or its personnel, then the remaining work for that Sprint will be canceled, if it is the final Sprint that is being suspended. If desired, Customer can request a Change Order for the outstanding work.
  — If the canceled Sprint is not the final Sprint, the remaining scope of work under that Sprint will be moved to the next scheduled Sprint as the first and priority tasks. 
  — The remaining Sprint scope will be worked on a best effort basis, keeping the originally scheduled Sprint dates. 
  — If the requested suspension or delay impacts the timeline of the remainder of the Project, Customer may re-engage and reschedule the Sprint scope for the next available Sprint, working with the Harness project manager or CSM to determine the appropriate timeline given the availability of Harness resources. If there are no remaining Sprints under this SOW, Customer must request a Change Order for the additional work requested.

• If Customer needs to delay a future Sprint and deviate from the Project, Customer shall notify their project manager or CSM in writing at least five (5) business days prior to the agreed upon start date of the Sprint.  If Customer does not provide such notice, the Sprint will automatically be canceled and all services thereunder will be forfeited by the Customer.
  —After the delay of a Sprint, Customer must make a written request to Harness to re-engage.  Such request must be made at least fifteen (15) Business Days prior to the new requested Start Date.  Harness will work with Customer to determine the new Start Date, based on Harness resource availability. The new agreed upon Start Date and any other appropriate updates will be made to the Project. The updated Project must be approved by Customer in accordance with the approval process outlined above.  Once the Project has been approved, the Sprint will officially be rescheduled.

‍

Ownership: 

As between Customer and Harness, Harness retains all right, title and interest in the services provided and any results of thereof including the deliverables specified in this SOW (collectively, “Deliverables”).  Subject to Customer’s payment in full of all fees due under this SOW, Harness grants Customer a limited, non-exclusive, non-transferable and non-sublicensable right and license to use the Deliverables during the applicable Subscription Term in connection with Customer’s use of the applicable Products in accordance with the Agreement.  For the avoidance of doubt, Deliverables do not include any  Customer Confidential Information, and any Customer Confidential Information contained in the Deliverables shall remain the sole and exclusive property of Customer. 

5. FEES AND EXPENSES

Customer shall pay to Harness the fees set forth in the applicable Order Form for the services.  All fees are due up front, in full, and must be paid within 30 days of the invoice date.  The payment of all fees is subject to the terms and conditions set forth in the Agreement.

If the work under this SOW exceeds the Standard Project Duration, or if Customer requests or requires additional hours beyond the scope of this SOW, the Parties shall execute a Change Order to this SOW as described in the Change Management section below. 

Any Services performed outside of the Standard Project Duration or any additional hours of work will be provided by Harness on a time-and-materials (T&M) basis only, at an hourly rate of $325 per hour, unless otherwise set forth in the Change Order. Customer must order a minimum of 10 hours per Business Week under such Change Order, and all additional hours purchased must be utilized within 6 months of the date of the Change Order, or else they will be forfeited. Any work provided on a T&M basis will be invoiced by Harness monthly in arrears. Once the Parties execute a Change Order for additional hours, the fees for such hours are non-cancellable and non-refundable.  At the end of the six (6) month period, Harness shall invoice Customer for any remaining hours purchased.

Furthermore, if Customer changes any requirements, additional hours may be required to complete the Services, and the Parties will execute a Change Order to facilitate the change in scope. Such a Change Order may increase the Price of the Services. No additional Services shall be provided unless the Change Order is agreed to in writing by the Parties.  

Expenses are not included in the fee set forth above.  All expenses incurred shall be in accordance with the Customer’s T&E corporate policy if provided to Harness in writing in advanced, otherwise such expenses shall be incurred in accordance with Harness’s T&E policy. If travel expenses are incurred with respect to this Professional Services program, Harness will invoice for travel expenses as incurred and monthly in arrears and Customer shall pay such invoices in accordance with the terms and conditions set forth in the Agreement. For the avoidance of doubt, all travel expenses must be pre-approved by the customer prior to any trips as part of this SOW. The duration of visits requested by the Customer cannot exceed two (2) business days unless mutually agreed in writing. 

6.  TERM AND TERMINATION

This SOW shall terminate upon the earlier of (i) six (6) months from the date of the last signature, below, or (ii) completion of the Services described above. Customer may request to extend the termination date of this SOW by submitting a Change Request as described in the Change Management section below.  If the Change Request is accepted, a reinstatement fee of up to 10% may apply.

Upon the expiration or termination of the Agreement or this SOW pursuant to the Agreement, all amounts (including expenses) owed to Harness for Services under this SOW (whether completed or not), will be immediately due and payable in full. Upon termination of the Agreement or a SOW by Customer for any reason pursuant to the Agreement, Customer shall be responsible for payment of all fees for Services rendered and expenses incurred prior to the date of termination. In addition, upon any termination or expiration of the Agreement or this SOW, Harness’s obligation to provide Services shall immediately terminate. 

7.  CHANGE ORDERS

Unless otherwise mutually agreed by the Parties, any change or modification of  this SOW or the Engagement Plan will be coordinated by the Parties in accordance with this Section 6. Either Party may initiate such requests for a change or modification (each, a "Change Request"). The Party requesting a Change Request will submit a written Change Request to the other Party in a clear and concise manner using a form substantially similar to the sample document attached hereto as Annex 1 (a “Change Order”).  Upon the execution of a mutually agreed upon Change Order by both Parties, the obligations of the Parties with respect to such Change Request will be incorporated under the SOW.   If a Change Order reinstates an expired SOW, a reinstatement fee of up to 10% may apply.

‍

Appendix A

Platform Fundamentals

Product Scope

• Single-sign On
• Role Based Access Control
• Harness Account Hierarchy
• Secret Manager

Implementation Scope

Reference Architecture

Continuous Delivery

CD Product Scope

• Rolling | Canary | Blue/Green Deployments
• Deployment Rollback
• Deployment Approvals
• Service manifest / configuration files
• Service artifacts and repositories / registries
• Deployment Environments and Infrastructure
• Change management integration
• Governance policies
• Software delivery metrics dashboard
• Step, Stage and Pipeline Templates
• Delegate dependencies

Continuous Integration

CI Product Scope

• CI Build Farm Architecture
• Codebase
• Code Builds
• Build Cache
• Build Test
• Change Management Integration
• Governance Policies
• Software Build Transparency Dashboard
• Step, Stage and Pipeline Templates
• Delegate dependencies

Cloud Cost Management

CCM Product Scope

• Cloud Billing Ingestion
• Cloud Provider IAM
• Cluster Metric Ingestion
• Delegate Architecture
• Perspectives, Budgets and Anomalies
• Recommendations
• Asset Governance
• Auto-stopping
• Cloud Transparency Dashboard

Feature Flags

FF Product Scope

• SDK Installation and Configuration
• Feature Flags (Boolean and Multivariate)
• Targets and Target Groups
• Environments
• Step, Stage and Pipeline Templates
• Governance Policies
• Feature Flag Transparency Dashboard

Security Test Orchestration

STO Product Scope

• Security Scan Infrastructure
• Integrated Security Scans
• Change Management Integration
• Governance Policies
• Step, Stage and Pipeline Templates
• Delegate Architecture

Service Reliability Management

SRM Product Scope

• Monitoring Integration Infrastructure
• Integrated Health Sources
• Integrated Change Sources
• Service Level Agreements, Objectives and Indicators
• Error Budgets
• Monitored Services
• Governance Policies
• Change Impact Analysis
• Continuous Verification Step Templates
• Delegate Architecture

Chaos Engineering

CE Product Scope

• Chaos Environments and Infrastructure
• Chaos Experiments
• ChaosHubs
• GameDays

Software Engineering Insights

SEI Product Scope

• Tenant Provisioning and Setup
• SSO Configuration
• Issue Management Integration
• SCM Integration
• CICD Integration
• SEI Dashboards
• Sprint Insights
• Asset-based and People-based Teams
• Trellis, Dora, and Business Alignment Profiles