Hybrid Cloud Foundation - Statement of Work - Template

UPDATE CUSTOMER NAME IN DOC PROPERTIES

Statement of Work

Prepared for

UPDATE CUSTOMER NAME IN DOC PROPERTIES

19-Nov-18

Version 2.0

Prepared by

UPDATE AUTHOR FIELD IN DOC PROPERTIES

UPDATE AUTHOR POSITION IN DOC PROPERTIES

UPDATE AUTHOR EMAIL IN DOC PROPERTIES

Contributors

Add Contributors to Doc Properties

Prior to the parties indicating final agreement by signing a Work Order, the information contained in this document represents the current view of Microsoft on the issues discussed as of the date of publication and is subject to change. Furthermore, prior to the signing of the Work Order, this document should not be interpreted as an invitation to contract or a commitment on the part of Microsoft. After the Work Order has been signed, changes to this document will be managed through the Change Management Process described in this document.

IF THIS DOCUMENT IS INCORPORATED BY REFERENCE INTO A WORK ORDER, ALL WARRANTIES APPLICABLE TO THE WORK ORDER APPLY TO THIS DOCUMENT. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

The descriptions of other companies’ products in this document, if any, are provided solely as a convenience to aid understanding and should not be considered authoritative or an endorsement by Microsoft. For authoritative descriptions of any non-Microsoft products described herein, please consult the products’ respective manufacturers. © 2016 Microsoft. All rights reserved. Any use or distribution of these materials without the express authorization of Microsoft is strictly prohibited.

Microsoft and Windows are either registered trademarks or trademarks of Microsoft in the United States and/or other countries.

1

UPDATE CUSTOMER NAME IN DOC PROPERTIES

Template Guidance

HYBRID CLOUD FOUNDATION Version 2.0

The purpose of this document is to provide the statement of work for a Hybrid cloud foundation project.There are several options and optional work streams to consider this SOW:

1. Choose either to include or delete the Azure Operations Planning (Optional, four weeks).
2. Choose whether to include Deploy one application workload to Microsoft Azureor delete the section from the SOW
3. The SOW is starting at 9 weeks, you can customize the SOW to as many weeks as required, due size, complexity or other implications. This is done at the Timeline section. Remember to update the WBS accordingly.

When done, remember to:

1. Update all relevant text fields in Document Properties, e.g. <Customer>, etc. and click OK
2. Type CTRL+’a’ to highlight the whole document
3. Press function key ‘F9’ to refresh fields, accepting updates to any ‘Table of Contents’, ‘Table of Figures’ and other auto-text components like cross-references
4. Type CTRL+’s’ to save the document

IMPORTANT – Finalize This Document

REMOVE all pink and yellow text, guidance, comments, changes, and hidden text in this document before submitting it to the customer. You can do this in two ways:

• Save as PDF and send the PDF version to the customer.
  ~ OR ~
• Inspect document and remove comments, revisions, any document properties you do not want included, personal information, and hidden text.

Remember to remove this page before customer handover

Revision and Signoff Sheet

Change Record

Table of Contents

Introduction

1Project Objectives and Scope

1.1Objectives

1.2Areas Within Scope

1.2.1General Project Scope

1.2.2Software Products / Technologies

1.2.3Environments

1.2.4Training and Knowledge Transfer

1.2.5Testing

1.3Areas Out of Scope

2Project Approach, Timeline and Service Deliverables

2.1Approach

2.1.1Envision

2.1.2Plan

2.1.3[OPTIONAL] Azure Operations Planning

2.1.4Build

2.1.5Stabilize

2.1.6Deploy

2.2Timeline

2.3Key Service Deliverables and Acceptance Process

2.3.1Key Project Service Deliverables

2.4Project Governance Approach

2.4.1Part-Time Project Management

2.4.2Communication Plan

2.4.3Issue/Risk Management Procedure

2.4.4Change Management Process

2.4.5Escalation Process

2.5Project Completion

3Project Organization and Staffing

3.1Project Organization Structure

3.2Project Roles and Responsibilities

3.2.1Customer Project Roles and Responsibilities

3.2.2Microsoft Project Roles and Responsibilities

4General Customer Responsibilities and Project Assumptions

4.1General Customer Responsibilities

4.2Project Assumptions

Introduction

This statement of work (SOW) and any exhibits, appendices, schedules, and attachments to it are made pursuant to the work order (WO) No. [Click here and type WO #], dated [Click here and type WO date], the terms of which are incorporated herein by reference, by and between UPDATE CUSTOMER NAME IN DOC PROPERTIES(“Customer”, “you”, “your”) and [Partner] (“[Partner]”, “us”, “we”, “our) or [Partner]’saffiliate, and sets forth the services to be performed by us related to the UPDATE CUSTOMER NAME IN DOC PROPERTIESHybrid Cloud Foundation project (“project”). This SOW, together with the WO, represents the complete baseline for scope, services, service deliverables, and acceptance applicable to this project. All changes to this document will be managed in accordance with the change management process defined below. Any terms not otherwise defined herein will assume the meanings set forth in the WO.

This SOW and the associated WO expire 30 days after their publication date, unless they have been formally extended in writing by [Partner].

1Project Objectives and Scope

1.1Objectives

In this project, [Partner] will assist UPDATE CUSTOMER NAME IN DOC PROPERTIES with integrating Microsoft Azure Infrastructure-as-a-Service (IaaS) and Platform-as-a-Service (PaaS) capabilities into your environment. This project designed to establish foundational understanding of Microsoft Azure, establish connectivity and configuration of your Microsoft Azure environment to meet your organization’s datacenter needs. We will assist your staff in understanding recommended practices for designing and operating workloads in Microsoft Azure and in developing a broad understanding of Microsoft Azure capabilities that can be used in future projects.

In this project, [Partner]can cover all or some of the aspects needed to consume, operate and manage multiple Azure services. Establishing a Hybrid Cloud Foundation infrastructure in Azure requires the planning, design and implementation of the core areas listed below. Some areas might be covered by the customer (such as on-premises network configuration), whereas others will be performed a part of this engagement. The scope of this engagement is described further in this Statement of Work.

After the initial foundation is established as part of this engagement, additional work streams should be conducted to prepare the organization to operate and manage Azure and lastly start deploying and migratingservices to Azure.

[OPTIONAL] Azure Operations Planning - UPDATE CUSTOMER NAME IN DOC PROPERTIEShas identified their future state for Azure operations and wants to define an operational framework addressing service delivery, service integration, and the Azure brokerage function to manage an Azure-based hybrid cloud IaaS and PaaS service for their customers.

[OPTIONAL] Additionally, this project will enable a proof-of-concept onboarding of a single workload to Microsoft Azure.

When scoping a proof-of-concept onboarding of a workload, ensure that the scope is clearly identified in this statement of work with the following guidance:

1. Time-box the workload onboarding activity. Measure the workload onboarding in weeks, include time for stabilization activities
2. Ensure the activity is clearly outlined and the scope for the workload onboarding is well-defined
3. Do not take on application development, code remediation or migration activities which would be covered in other offerings such as Enterprise Modernization

The engagement will address the following projects and work streams:

Table 1: Project/Work Streams

1.2Areas Within Scope

1.2.1General Project Scope

[Partner] will assist with planning, building, testing, and deploying an agreed upon production-level architecture for an Azure infrastructure capability to host your organization’s applicationworkloads in a standardized manner, enabling capabilities such as large-scale migration or the organization’s future cloud-enabled applications and services.

The following services will be provided:

1.2.2Software Products / Technologies

The customer is responsible for acquiring and providing all software and services used in the project.

Table 2: Solution Software Required

1.2.3Environments

The following environments are included in the scope of this Statement of Work.

Table 3:Required Environments

1.2.4Training and Knowledge Transfer

No formal training is included in the scope of this Statement of Work.

Informal knowledge transfer will be provided throughout the project and during the scope of the project during project collaboration. Informal knowledge transfer is defined as informal activities provided when customer team members, associates, or contractors are working side-by-side with the [Partner] team. This includes whiteboard discussions, email threads, conference calls, and facilitated meetings on technical topics. No deliverables or meeting summaries will be provided for these sessions or activities.

1.2.5Testing

[Partner] will assist with the following testing as part of this Statement of Work.In the planning phase of the project, a workshop will be conducted to plan test cases and exit criteria. Following these decisions, a high-level test plan will be created to guide testing activities related to the ARM templates created as outputs of the design and planning sessions. The test plan is typically comprised of an Excel workbook listing up to five test cases, expected results, and observed results. Testing is focused on customer specific scenarios as opposed to generic testing of Microsoft Azure fundamentals. Testing activities across all test cases are ‘time boxed’ (not to exceed) a total of 40 hours. This means that after 40 hours, if additional effort is determined to be necessary, it is subject to the Change Management process defined later in this document.

As defects are identified during testing, the defect priority will be jointly agreed upon by the UPDATE CUSTOMER NAME IN DOC PROPERTIES and [Partner]. The [Partner] team will triage the defect and fix all in-scope P1 and P2 defects. Defect priorities are shown in the following table.

Table 4: Defect priorities found during testing

Note: P3 and P4 defects will be logged and UPDATE CUSTOMER NAME IN DOC PROPERTIES may choose to schedule their remediation either by change request, through the process described in Section 2.4.4 of this Statement of Work, or during a subsequent release. P3 and P4 defects will not be corrected by default under this Statement of Work.

Note: Product bugs and design change requests (DCR) are not in scope. Product related issues must be addressed separately through Premier support.

1.3Areas Out of Scope

Any area that is not explicitly listed in Section 1.2 as within scope is out of scope for this engagement. The areas that are out of scope for this engagement include, but are not limited to, the following:

▪Creation of more than two supported custom server images for Azure. Existing gallery images available in Azure will be used if an Azure supported custom image cannot be made available to support the timeline of the project.

▪Setup of the on-premises VPN device. [Partner] will provide guidance and support, but UPDATE CUSTOMER NAME IN DOC PROPERTIES networking staff will be responsible for device setup and configuration.

▪Configuration of network border access. [Partner] will provide guidance and support, but customer networking staff will be responsible for allowing any required ports and protocols needed by the Solution.

▪Azure subscriptions. UPDATE CUSTOMER NAME IN DOC PROPERTIES is responsible for acquiring all necessary subscriptions required as a result of Work Order.

▪Configuration of Active Directory, beyond that which is explicitly required to support Azure integration.

▪Source code review. UPDATE CUSTOMER NAME IN DOC PROPERTIESwill not provide [Partner] with access to non-[Partner] source code or source code information. For any non-[Partner] code, [Partner]’s services will be limited to analysis of binary data only, such as a process dump or network monitor trace.